Invalid superblock after e2fsck

[Stephen Samuel (gmail)]

The system is using the backup superblock -- which sounds  reasonable, under
the circumstances, and should result in a half-decent recovery.

A couple of questions:
Was the superblock zero to begin with, or did it become zero during the
FSCK?
In either case, I'm worried about the zero data having been written. This is
obviously worth further investigation.
Did the system abort the FSCK after this error? or did you stop it?
did you try explicitly using one of the backup superblocks?
  a list of backup superblocks can be found by using -n on mkfs
  check the -b option on fsck.ext2 for more details on the backup superblock
defaults.

2010/2/21 Albert Sellarès <whats at wekk.net>

> Hi all,
>
> I'm trying to fix a 7.5Tb ext3 filesystem using e2fsck on a x86_64
> machine with plenty of memory ram. The filesystem is corrupted, but I
> can mount it.is
>
> Before starting the filesystem check, I did a LVM snapshot to be able to
> start it again from the same point in case of error.
>
> After 12 hours checking the filesystem, I got this error message:
>
> Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
> 65673.66/1550.92/1371.06
> Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s
> Restarting e2fsck from the beginning...
> e2fsck: Superblock invalid, trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to
> open /dev/storage/cabina_snapshot
>
> Once I saw this message, my first thought was that e2fsck didn't manage
> to fix the filesystem and it corrupted the superblock. To be sure I
> dumped the entire block and compared it against the original superblock.
> Doing that I realized that the entire superblock only contained zeros.
>
> Any ideas of what can I do?
>
>
-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20100221/8f29dc7b/attachment.htm>