Re: needs help, root inode gone after usb bus reset on sata disks
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Theodore Tso wrote:
On Wed, May 28, 2008 at 04:44:21PM +0200, Jelle de Jong wrote:dumpe2fs -o superblock=32768 /dev/sdXXI 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>&1dumpe2fs -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.gzI 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 ofdumpe2fs -o superblock=32768 /dev/sdXXanddumpe2fs -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
[Linux RAID] [Kernel List] [Red Hat Install] [Video 4 Linux] [Postgresql] [Fedora] [Fedora Legacy] [Gimp] [Yosemite News] [Linux Software]