needs help, root inode gone after usb bus reset on sata disks
Jelle de Jong
jelledejong at powercraft.nl
Thu May 29 09:37:25 UTC 2008
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
More information about the Ext3-users
mailing list