The list of inodes is checked sequentially starting with inode 2 (inode 0 and inode 1 are reserved). Each inode is checked for inconsistencies in:
Format and type
Bad block numbers
Shadow (used for ACLs)
When the file system is created, a fixed number of inodes are set aside, but they are not allocated until they are needed. An allocated inode is one that points to a file. An unallocated inode does not point to a file and, therefore, should be empty. The partially allocated state means that the inode is incorrectly formatted. An inode can get into this state if, for example, bad data is written into the inode list because of a hardware failure. The only corrective action fsck can take is to clear the inode.
Each inode contains a count of the number of directory entries linked to it. The fsck program verifies the link count of each inode by examining the entire directory structure, starting from the root directory, and calculating an actual link count for each inode.
Discrepancies between the link count stored in the inode and the actual link count as determined by fsck might be of three types:
The stored count is not 0 and the actual count is 0.
This condition can occur if no directory entry exists for the inode. In this case, fsck puts the disconnected file in the lost+found directory.
The stored count is not 0 and the actual count is not 0, but the counts are unequal.
This condition can occur if a directory entry has been added or removed but the inode has not been updated. In this case, fsck replaces the stored link count with the actual link count.
The stored count is 0 and the actual count is not 0.
In this case fsck changes the link count of the inode to the actual count.
Each inode contains a list, or pointers to lists (indirect blocks), of all the blocks claimed by the inode. Because indirect blocks are owned by an inode, inconsistencies in indirect blocks directly affect the inode that owns the indirect block.
The fsck program compares each block number claimed by an inode to a list of allocated blocks. If another inode already claims a block number, the block number is put on a list of duplicate blocks. Otherwise, the list of allocated blocks is updated to include the block number.
If there are any duplicate blocks, fsck makes a second pass of the inode list to find the other inode that claims each duplicate block. (A large number of duplicate blocks in an inode might be caused by an indirect block not being written to the file system.) It is not possible to determine with certainty which inode is in error. The fsck program prompts you to choose which inode should be kept and which should be cleared.
The fsck program checks each block number claimed by an inode to see that its value is higher than that of the first data block and lower than that of the last data block in the file system. If the block number is outside this range, it is considered a bad block number.
Bad block numbers in an inode might be caused by an indirect block not being written to the file system. The fsck program prompts you to clear the inode.
Each inode contains a count of the number of data blocks that it references. The number of actual data blocks is the sum of the allocated data blocks and the indirect blocks. fsck computes the number of data blocks and compares that block count against the number of blocks the inode claims. If an inode contains an incorrect count, fsck prompts you to fix it.
Each inode contains a 64-bit size field. This field shows the number of characters (data bytes) in the file associated with the inode. A rough check of the consistency of the size field of an inode is done by using the number of characters shown in the size field to calculate how many blocks should be associated with the inode, and then comparing that to the actual number of blocks claimed by the inode.