Javier Gomez wrote:
>
> The two devices having issues are /dev/etherd/e5.1p1 and
> /dev/etherd/e4.1p1
>
> You make a very valid point. Notice the main device shows the full
> size (one has 12.6 TB and the other is 9.5 TB). Each of these two
> devices contain a single complete partition on it taking up the full
> size of the device. It looks like both of these are short on the size
> for the actual partition "1p1".
Yep....
> Note that for device /dev/etherd/e3.1
> and /dev/etherd/e7.1 and /dev/etherd/e7.2 we formated the xfs
> filesystem directly on the device. The groups on the net had noted that
> it could be done either way, but it might be a little safer to do it
> with the xfs formated directly on the device (not sure if this is
> valid).
From the xfs perspective, it does not really matter.
> In this case /dev/etherd/e3 and /dev/etherd/e7 both came up
> just fine after the hard shutdown while the /dev/etherd/e4 and
> /dev/etherd/e5 both have this superblock issue.
If we look at those devices in /proc/partitions:
> 152 0 12697913278 etherd/e4.1 <-- 11.8GiB
> 152 1 1960494281 etherd/e4.1p1 <-- 1.8GiB
> 152 48 9523468862 etherd/e5.1 <-- 8.8GiB
> 152 49 933533929 etherd/e5.1p1 <-- 0.9GiB
you can see that the partitions don't actually seeem to span much of the
device. I don't know how that happened, but it's unlikely to be an xfs
problem.... perhaps if you can figure out what went wrong there, and get
your partitions back to the right(?) size xfs will see a consistent
filesystem.
> Each of these devices
> are running the same stuff except that /dev/etherd/e5 is slightly
> smaller then the other ones in disk space. See this information below,
> do you have any suggestions to recover from it? Is there anyway to
> remap the partition description to fill the entire size correctly so
> that the xfs_repair can complete its job?
What sort of partition tables are on the devices? I'll hazard a guess
that they're dos partition tables made with parted? Hmm yep from
looking at the sizes of your devices and partitions, it does appear that
the high bits of the size have been lost.
If so then you've been bitten by a parted bug that lets you "create" dos
partition tables larger than can actually be stored on-disk (2T IIRC),
so that when you reboot, it appears to be truncated. However, the xfs
data is still there, if so.
Depending on how big the dos partition table is I think some people have
successfully replaced it with a GPT table, which can handle these larger
sizes. Doing that is a little tricky, and backing up the old table with
dd is well-advised.
-Eric
|