On Thu, May 29, 2008 at 11:37:25AM +0200, Jelle de Jong wrote:
>
> 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 -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
Unfortunately, it looks like the backup superblocks were also
corrupted, and in the same way. Did you *ever* run e2fsck in
read/write mode (i.e., without the -n option) on this filesystem after
when you think it had gotten corrupted?
So what I will suggest at this point is that you do the following:
debugfs -w /dev/sda1
debugfs: features dir_index filetype sparse_super
debugfs: quit
The run "e2fsck -nf /dev/sda1" and make the output looks relatively
clean. You should *not* see any messages about needing to relocate
inode tables.
If so, you can then run "e2fsck -f /dev/sda1 to fully recover the
filesysten.
> 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.
Well, absolutely no one else reporting this problem or anything like
it...
- Ted
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
