Re: Invalid superblock after e2fsck

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

e2fsck quits after the bad magic number message. I didn't pasted the
entire e2fsck output (sorry!). The full output was that:

root@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
forced.
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:
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

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
superblock:
    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
behavior. 

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)
va escriure:
> 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@xxxxxxxx>
>         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
-- 
  Albert Sellarès        GPG id: 0x13053FFE
  http://www.wekk.net    whats@xxxxxxxxxx 
  Linux User: 324456                

Attachment: signature.asc
Description: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part d'un missatge signada digitalment

_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux