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

[Theodore Tso]

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

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