Re: needs help, root inode gone after usb bus reset on sata disks

[Jelle de Jong <jelledejong@xxxxxxxxxxxxx>]

Theodore Tso wrote:
> On Wed, May 28, 2008 at 04:44:21PM +0200, Jelle de Jong wrote:
> > > dumpe2fs -o superblock=32768 /dev/sdXX
>
> I asked you to do the above, but you did this instead:
>
> > dumpe2fs -ob 32768 /dev/sda1 > dumpe2fs-32768-info-sda1.txt 2>&1

My humble excuse, i had to place the disk in a server and this server 
had an older version of the dumpe2fs tool that did not supported the 
superblock option. I upgraded the server and rerun all the test for you.

dumpe2fs /dev/sda1 > dumpe2fs-info-sda1.txt 2>&1
dumpe2fs -o superblock=32768 /dev/sda1 > 
dumpe2fs-superblock-32768-info-sda1.txt 2>&1
dumpe2fs -o superblock=98304 /dev/sda1 > 
dumpe2fs-superblock-98304-info-sda1.txt 2>&1
e2fsck -n /dev/sda1 > e2fsck-n-info-sda1.txt 2>&1

http://www.powercraft.nl/temp/dumpe2fs-info-sda1.txt.gz
http://www.powercraft.nl/temp/dumpe2fs-superblock-32768-info-sda1.txt.gz
http://www.powercraft.nl/temp/dumpe2fs-superblock-98304-info-sda1.txt.gz
http://www.powercraft.nl/temp/e2fsck-n-info-sda1.txt.gz

I hope this is the correct information, that can tell you want command 
is best to run to restore the filesystem with the data.

> Resulting in this:
>
> dumpe2fs: No such file or directory while trying to open 32768
>
> So I can't tell if the backup superblock was corrupted, but this is
> definitely one for the record books.  Looking at primary superblock,
> we see the following:
>
> dumpe2fs 1.40-WIP (14-Nov-2006)
> Filesystem volume name:   <none>
> Last mounted on:          ^^<BA><8B>
> Filesystem UUID:          2e27ae79-fc96-43f5-9758-15ed74dd55fb
> Filesystem magic number:  0xEF53
> Filesystem revision #:    0 (original)
> Filesystem features:      (none)
> Default mount options:    MNTOPT_15 MNTOPT_16 MNTOPT_18 MNTOPT_20 MNTOPT_21 MNTOPT_22 MNTOPT_24 MNTOPT_26
>
> The above, especially the Filesystem features, and default mount
> options, are garbage.  But it looks like the rest of the superblock,
> including the magic number, the block counts, etc., look sane --- at
> least in sane enough that it passed e2fsck's sanity checking.
>
> This is unlike *any* corruption I've seen before; usually there will
> be a single bit flip, or the entire disk sector is corrupted, but it's
> extremely rare to see this kind of selective corruption.
>
> It's even wierder that this apparently happened on more than one hard
> drive.  In any case, I would ditch that USB<->SATA converter as fast
> as possible, because there is something seriously wrong.  The other
> possibility is that you're running with buggy kernel, but no one else
> has ever reported anything like this, and for two disks to be
> corrupted the same way means it's unlikely to be caused by a random
> wild pointer or some such.  So if I really had to guess I'd go with
> the USB converter, but that's not for certain.
>
> In terms of how to fix it, I'd would have to see the results of 
>
> dumpe2fs -o superblock=32768 /dev/sdXX
>
> and 
>
> dumpe2fs -o superblock=98304 /dev/sdXX
>
> Hopefully one of the superblocks look OK.  We could also try manually
> repairing the superblock with debugfs, in the worse case, but it'll be
> easier if we can fix things via the backup superblock.
>
>        	     	     	    	    	   - Ted

I always seem to get the impossible out of Linux tools, but most times 
this is during quality tests... however this was on "normal usage". I 
hope it has noting to do with the latest release changes or with corrupt 
binaries on my client system.

Thank you Ted,

Kind regards,

Jelle


_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users