[lug] how to repair GPT

[Aaron D. Johnson]

Steve A Hart writes:

> OK, well I let fsck run with it and many errors still keep cropping
> up so I think I'm just going to call it and wipe the thing.  Yes,
> fsck is trying to read past the end of the block device due to bad
> info in the filesystem's superblock.  Fsck actually finishes but the
> filesystem still does not come up clean.  It ends with:
> 
> Error writing block 550731776 (Attempt to write block from filesystem 
> resulted in short write).  Ignore error? yes
> 
> Error writing block 644972544 (Attempt to write block from filesystem 
> resulted in short write).  Ignore error? yes

Ouch.  :(

But, um, block 644972544 isn't past the end of a 7Tbyte drive, I don't
think.  Block 644972544 is 2641807540224 bytes in (assuming a 4kbyte
block size).  A 7Tbyte disk would be 7696581394432 bytes in size.
Which would point back to IO errors coming from what should be valid
blocks inside your RAID device.  (Someone should probably check my
math here.)

Feel like trying to read the whole thing with dd instead of badblocks?
Something like "dd if=/dev/sdd1 of=/dev/null bs=4096".  It would be
interesting to see if it reports errors at the same sorts of offsets
that fsck is reporting errors.

> I initially thought it was a GPT problem but it's just easier now to 
> reinitialize the filesystem.

If this RAID device is only ever going to hold just the one filesystem
for backups, you might consider skipping the partitioning step next
time around.  (Do the mkfs on /dev/sdd instead of creating a /dev/sdd1
then running mkfs on that.)  One less layer of things to get confused by
the next time trouble comes up.

> I'm going to run the built in diagnostics on the RAID itself to make 
> sure the hardware is fine and then reinitialize the filesystem.  Then 
> I'm going to buy a frickin UPS!

Do you have a regular test schedule for that UPS?  They fail, too.  As
do expensive, top-tier vendor disk arrays.  (Been there, done that.
It sucks.)

- Aaron