Linux Superblock: Basic Concept and Troubleshooting

When you create file system on hard drive it will sub divided into multiple file system blocks. Blocks are used for:
* To store user data
* Some blocks used for to store file system's metadata.

The content of files is stored in contiguous blocks of 1024 bytes on a Red Hat Linux System by default (the actual size depends on command line parameters passed to mke2fs when the file system was first created and can be 1024, 2048 or 4096 bytes).

Each file system is different and they have type like ext2, ext3 etc. Further each file system has size like 5 GB, 10 GB and status such as mount status. In short each file system has a superblock, which contains information about file system such as:
* File system type
* Size
* Status
* Information about other metadata structures

The Superblock contains a description of the basic size and shape of this file system. The information within it allows the file system manager to use and maintain the file system. Usually only the Superblock is read when the file system is mounted but each Block Group contains a duplicate copy in case of file system corruption. Amongst other information it holds the:

Magic Number: This allows the mounting software to check that this is indeed the Superblock for an EXT2 file system. For the current version of EXT2 this is 0xEF53.
Revision Level: The major and minor revision levels allow the mounting code to determine whether or not this file system supports features that are only available in particular revisions of the file system. There are also feature compatibility fields which help the mounting code to determine which new features can safely be used on this file system, Mount Count and Maximum Mount Count Together these allow the system to determine if the file system should be fully checked. The mount count is incremented each time the file system is mounted and when it equals the maximum mount count the warning message ``maximal mount count reached, running e2fsck is recommended'' is displayed.
Block Group Number: The Block Group number that holds this copy of the Superblock,
Block Size: The size of the block for this file system in bytes, for example 1024 bytes.
Blocks per Group: The number of blocks in a group. Like the block size this is fixed when the file system is created,
Free Blocks: The number of free blocks in the file system,
Free Inodes: The number of free Inodes in the file system,
First Inode: This is the inode number of the first inode in the file system. The first inode in an EXT2 root file system would be the directory entry for the '/' directory.

The dumpe2fs command displays information from the superblock:

#dumpe2fs -h /dev/sda1
Filesystem volume name: /boot
Last mounted on: "not available"
Filesystem UUID: b8c5462a-76a6-481a-826c-b56e525451bc
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
[ output truncated ]

If for some reason the superblock gets corrupted or becomes unreadable, the entire filesystem becomes unusable. In order to avoid this problem a backup copy of the information contained into the superblock gets stored on the filesystem at regular intervals, depending on the blockize, creating what are actually called the backup superblocks. If the main superblock is not recoverable, there is a chance we can use the information provided by the backup superblocks in order to restore the filesystem to a usable state.

To use a backup superblock, we must first locate them. To locate them, it helps us to know the blocksize used during the filesystem creation.

We can use of the utility mke2fs with the non-destructive option -n in order to see what backup superblocks would be created on the filesystemgiven a certain blocksize:

#mke2fs -b 1024 -n /dev/sda1
Superblock backups stored on blocks:
8194 24578 40962 [ output truncated ]

This will not actually make a filesystem, but will pretend to, displaying the output as if it had made a filesystem using a block-size of 1K.

We can now test the validity of the superblock backup by trying to mount the partition using the information using information provided by the superblock, avoiding the default superblockwhich is presumable corrupted.

#mount -o sb=8194 /dev/sda1 /path-to-mountpoint

If mounts successfuly, then it is likely that only the first superblock is curroupted; the backup superblocks are sane. You can restore the main superblock by running a filesystem consistency check on filesystem:

#e2fsck -b 8194 -B 1024 /dev/sda1

The e2fsck command will ensure that primary superblock is properly updated upon completion of the check.

In the most unlikely case where the most backup superblocks are corrupted you can manually force the rebuild of all superblocks, issuing something like this:

#mke2fs -S -b 1024 /dev/sda1

WARNING: This will force the recreation of all the superblocks and block descriptors only. This means that it will not touch the actual data. For this reason you must apply the right block size to the command. However there is no certainity this will restore the filesystem to an operating state. Use it at your own risk as the very last resort.