Using alternative superblock to check ext3

After a long time running, your file systems may bacome rotted. There would be so many abnormal files, like pipes, sockets and damaged links, etc. But no warries please, they are only  file system with some common isssues, what you need to do are often 3 steps:

– umount the file system, using DD to backup the whole patition:
# nohup dd if=/dev/sdb10 of=/mnt/172sdb10 &
– using fsck to check the issued partition, it may take some time based on how large it is.
# nohup fsck.ext3 -y  /dev/sdb10 &
– remount the file system, and try what you can to recover the lost files, they are stored in “lost+found”.

For normal condition, you might lose very little data. If too much data is lost, don’t forget that you have backupped the partition already, it’s time to use it.

But sometimes, you are not that lucky, here I’ll give you an example:
# fsck.ext3 -y /dev/sdb10
e2fsck 1.39 (29-May-2006)
Group descriptors look bad… trying backup blocks…
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb10

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>

Here a new issue comes. As the notification message is different from normal ones, there might be some critical issue for this poor file system. What can we do now> Just followed the direction.
We need to specify an alternative superblock to fsck this fs.

All the avaiable superblocks are listed when creating file systems.

# fsck -y -b 32768 /mnt/sdb9.txt
some sotrage system e2fsck 1.39 (29-May-2006)
Group descriptors look bad… trying backup blocks…
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb10
….<the same warning messages>….
# fsck -y -b 98304 /mnt/sdb9.txt
e2fsck 1.39 (29-May-2006)
ext3 recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sdb10: recovering journal
Backing up journal inode block information.

Thank god, it works. During its long time running, we can check fsck’s output in nohup.out.
After finished, we can have a try to mount the file system as normal:
# mount -a
mount: wrong fs type, bad option, bad superblock on /dev/sdb10,
or too many mounted file systems

wrong fs type” means this file sytem type is changed, or there’s still something wrong. We need to do some modification to the file system directly now. As inode 8 is used for ext3 journal, we need to recreate it
# debugfs -w /dev/sdb10
debugfs 1.39 (29-May-2006)
debugfs:  clri <8>
debugfs:  quit
Then, we need to run fsck again, let it fix the cleaned inode.
# nohup fsck -y /dev/sdb10 &
# tune2fs -j /dev/sdb10

Now, the file system has been fixed

3 thoughts on “Using alternative superblock to check ext3

  1. Thanks, this saved a stack of my data when a disk failed. I did things a little backwards though.

    I made a backup with dd with noerrors,sync flags as the disk was faulty, and then repaired the backup file.

    Once it was fixed I mounted it using -o loop and started to retrieve the files I needed to get back.

  2. I have learn several excellent stuff here. Definitely value bookmarking for revisiting. I wonder how so much effort you put to create this type of magnificent informative site.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.