Admon Home

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, please click here for details about available superblocks.

# 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