As we know fsck is a great command to check and repair error on file system. Many times i found filesystem in panic and fsck make it operation-able. I used fsck many times but every time i ensured that filesystem on which i applying fsck be in unmount state.
But the most important thing i was interested is fsck stages. Whenever i issued fsck command it output as
Phase 1: Checking Inodes,blocks and sizes
Phase 2: Checking directory structure
Phase 3: Checking directory connectivity
Phase 4: Checking Reference count
Phase 5: Checking group summary information
fsck checks the integrity of several different features of the file system. Most important checking that fsck do is of super block. As we know super block is most important aspect of file system which stores summary information for the volume. super block is also most modified item in file system so chances of corruption of super block is always high.
Checks on the superblock include:
A check of the file system size, which obviously must be greater than the size computed from the number of blocks identified in the superblock
The total number of inodes, which must be less than the maximum number of inodes
A tally of reported free blocks and inodes
On number of occasion I found super block of my file system get corruption. Although its a very difficult for me to dictates reasons of super block corruption. But the better part is that a backup super block is always present in our file system. To know that where is alternate super block we can use dumpe2fs command as follwing root# dumpe2fs /dev/sda1
#mke2fs -n /dev/device
use -j switch also if it is an ext3 file system (mke2fs -n -j /dev/device)
But the most important thing i was interested is fsck stages. Whenever i issued fsck command it output as
Phase 1: Checking Inodes,blocks and sizes
Phase 2: Checking directory structure
Phase 3: Checking directory connectivity
Phase 4: Checking Reference count
Phase 5: Checking group summary information
fsck checks the integrity of several different features of the file system. Most important checking that fsck do is of super block. As we know super block is most important aspect of file system which stores summary information for the volume. super block is also most modified item in file system so chances of corruption of super block is always high.
Checks on the superblock include:
A check of the file system size, which obviously must be greater than the size computed from the number of blocks identified in the superblock
The total number of inodes, which must be less than the maximum number of inodes
A tally of reported free blocks and inodes
On number of occasion I found super block of my file system get corruption. Although its a very difficult for me to dictates reasons of super block corruption. But the better part is that a backup super block is always present in our file system. To know that where is alternate super block we can use dumpe2fs command as follwing root# dumpe2fs /dev/sda1
more Generally block number 32768 is backup super block, so to recover filesystem using backup super block fsck command can be used in following ways root# fsck -b 32768 /dev/sda1 Other than super block corruption other error can be easily fixed by using fsck in straight ways as following root# fsck -y /dev/sda1 (Here -y option save us from pressing y while asking for yes during recovery ) When inodes are examined by fsck, the process is sequential in nature and aims to identify inconsistencies in format and type, link count, duplicate blocks, bad block numbers, and inode size. Inodes should always be in one of three states: allocated (being used by a file), unallocated (not being used by a file), and partially allocated, meaning that during an allocation or unallocation procedure, data has been left behind that should have been deleted or completed. Alternatively, partial allocation could result from a physical hardware failure. In both of these cases, fsck will attempt to clear the inode. The link count is the number of directory entries that are linked to a particular inode. fsck always checks that the number of directory entries listed is correct, by examining the entire directory structure beginning with the root directory, and tallying the number of links for every inode. Clearly, the stored link count and the actual link count should agree, but the stored link count can occasionally be different than the actual link count. This could result from a disk not being synchronized before a shutdown, for example, and while changes to the file system have been saved, the link count has not been correctly updated. If the stored count is not zero, but the actual count is zero, then disconnected files are placed in the lost+found directory found in the top level of the file system concerned. In other cases, the actual count replaces the stored count
for finding alternate/backup superblocks the following command can also be used,
#mke2fs -n /dev/device
use -j switch also if it is an ext3 file system (mke2fs -n -j /dev/device)
