Solving filesystem problems

Using fsck_ufs to check inodes

The list of inodes in the filesystem is checked sequentially starting with inode 2 (inode 0 marks unused inodes; inode 1 is saved for future generations) and progressing through the last inode in the filesystem. Each inode is checked for inconsistencies involving:

Using fsck_ufs to check format and type

Each inode contains a mode word. This mode word describes the type and state of the inode. Inodes can be one of six types:

Inodes can be in one of three allocation states: This last state means that the inode is incorrectly formatted. An inode can get into this state if bad data is written into the inode list. The only possible corrective action fsck can take is to clear the inode.

Using fsck_ufs to check link count

Each inode counts the total number of directory entries linked to the inode. fsck verifies the link count of each inode by starting at the root of the filesystem, and descending through the directory structure. The actual link count for each inode is calculated during the descent.

Discrepancies between the link count stored in the inode and the actual link count as determined by fsck can be of two types:

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 an indirect block directly affect the inode that owns it.

Using fsck_ufs to check duplicate blocks

fsck compares each block number claimed by an inode against a list of already allocated blocks. If another inode already claims a block number, then the block number is added to 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 performs a partial second pass over the inode list to find the inode of the duplicated block. The second pass is needed, because without examining the files associated with these inodes for correct content, not enough information is available to determine which inode is corrupted and should be cleared. If this condition does arise, the inode with the earliest modify time is usually incorrect, and should be cleared. If this happens, fsck prompts you to clear both inodes. You must decide which one should be kept and which one should be cleared.

Using fsck_ufs to check bad block numbers

fsck checks the range of each block number claimed by an inode. If the block number is lower than the first data block in the filesystem, or greater than the last data block, then the block number is a bad block number. Many bad blocks in an inode are usually caused by an indirect block that was not written to the filesystem, a condition that can occur only if there has been a hardware failure. If an inode contains bad block numbers, fsck prompts you to clear it.

Using fsck_ufs to check inode size

Each inode contains a count of the number of data blocks that it contains. The number of actual data blocks is the sum of the allocated data blocks and the indirect blocks. fsck computes the actual number of data blocks and compares that block count against the actual number of blocks the inode claims. If an inode contains an incorrect count, fsck prompts you to fix it.

Each inode contains a 32-bit size field. The size is the number of data bytes in the file associated with the inode. The consistency of the byte size field is roughly checked by computing, from the size field, the maximum number of blocks that should be associated with the inode, and comparing that expected block count against the actual number of blocks the inode claims.

Data associated with an inode

An inode can directly or indirectly reference three kinds of data blocks. All referenced blocks must be the same kind. The three types of data blocks are plain data blocks, symbolic link data blocks, and directory data blocks. Plain data blocks contain the information stored in a file; symbolic link data blocks contain the pathname stored in a link; and directory data blocks contain directory entries. fsck can only check the validity of directory data blocks.

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004