Invalid superblock after e2fsck
whats at wekk.net
Sun Feb 21 14:00:15 UTC 2010
e2fsck quits after the bad magic number message. I didn't pasted the
entire e2fsck output (sorry!). The full output was that:
root at pacs:~# e2fsck -C 0 -y -t /dev/storage/cabina_snapshot2
e2fsck 1.41.9 (22-Aug-2009)
/dev/storage/cabina_snapshot2 contains a file system with errors, check
Pass 1: Checking inodes, blocks, and sizes
/dev/storage/cabina_snapshot2: |================== / 60.0%
Until 60% of the progress bar, there was no error messages. After reach
the 60%, e2fsck started fixing a lot of things. In the output I
recognized the inode that it was analyzing. Once e2fsck analyzed the
last inode of the filesystem, it printed this message and exited:
Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
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
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate
e2fsck -b 8193 <device>
About your questions:
The content of the default superblock (I mean the superblock located at
block 0) was correct before to launch e2fsck because I was able to mount
it and use the filesystem. (I also dumped their content and checked it).
After the filesystem check, the superblock was filled only with zeros
(no magic number, no inode counts, etc...), all the 4096 bytes at zero.
I've not tried to launch the e2fsck over a backup superblock instead of
over the default one because I think that this would produce the same
result. I'm sure that the original superblock was not corrupted then I
guess that with a backup superblock, e2fsck would have the same
What do you think? Should I try to launch it over a backup superblock at
the first time?
Any other ideas?
Thanks you very much!
El dg 21 de 02 de 2010 a les 04:51 -0800, en/na 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
> 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
> Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
> 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
> 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
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats at jabber.org
Linux User: 324456
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Aix? ?s una part d'un missatge signada digitalment
More information about the Ext3-users