The UFS Components That Are Checked for Consistency
This section describes the kinds of consistency checks that the fsck command applies to these UFS file system components: superblock, cylinder group blocks, inodes, indirect blocks, and data blocks.
For information about UFS file system structures, see "The Structure of Cylinder Groups for UFS File Systems".
Superblock Checks
The superblock stores summary information, which is the most commonly corrupted component in a UFS file system. Each change to the file system inodes or data blocks also modifies the superblock. If the CPU is halted and the last command is not a sync command, the superblock almost certainly becomes corrupted.
The superblock is checked for inconsistencies in the following:
File system size
Number of inodes
Free block count
Free inode count
File System Size and Inode List Size Checks
The file system size must be larger than the number of blocks used by the superblock and the list of inodes. The number of inodes must be less than the maximum number allowed for the file system. An inode represents all the information about a file. The file system size and layout information are the most critical pieces of information for the fsck command. Although there is no way to actually check these sizes because they are statically determined when the file system is created. However, the fsck command can check that the sizes are within reasonable bounds. All other file system checks require that these sizes be correct. If the fsck command detects corruption in the static parameters of the primary superblock, it requests the operator to specify the location of an alternate superblock.
For more information about the structure of the UFS file system, see "The Structure of Cylinder Groups for UFS File Systems".
Free Block Checks
Free blocks are stored in the cylinder group block maps. The fsck command checks that all the blocks marked as free are not claimed by any files. When all the blocks have been accounted for, the fsck command checks to see if the number of free blocks plus the number of blocks that are claimed by the inodes equal the total number of blocks in the file system. If anything is wrong with the block maps, the fsck command rebuilds them, leaving out blocks already allocated.
The summary information in the superblock includes a count of the total number of free blocks within the file system. The fsck command compares this count to the number of free blocks it finds within the file system. If the counts do not agree, the fsck command replaces the count in the superblock with the actual free-block count.
Free Inode Checks
The summary information in the superblock contains a count of the free inodes within the file system. The fsck command compares this count to the number of free inodes it finds within the file system. If the counts do not agree, fsck replaces the count in the superblock with the actual free inode count.
Inodes
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 the following:
Format and type
Link count
Duplicate block
Bad block numbers
Inode size
Format and Type of Inodes
Each inode contains a mode word, which describes the type and state of the inode. Inodes might be one of nine types:
Shadow (used for ACLs)
Attribute directory
Socket
Inodes might be in one of three states:
Allocated
Unallocated
Partially allocated
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 the fsck command can take is to clear the inode.
Link Count Checks
Each inode contains a count of the number of directory entries linked to it. The fsck command 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 the fsck command 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, the fsck command 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, the fsck command 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, the fsck command changes the link count of the inode to the actual count.