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
