Duplicate Block Checks

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 command 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, the fsck command 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 command prompts you to choose which inode should be kept and which should be cleared.

Bad Block Number Checks

The fsck command 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 command prompts you to clear the inode.

Inode Size Checks

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. The fsck command computes the number of data blocks and compares that block count against the number of blocks that the inode claims. If an inode contains an incorrect count, the fsck command 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.

Indirect Blocks

Indirect blocks are owned by an inode. Therefore, inconsistencies in an indirect block affect the inode that owns it. Inconsistencies that can be checked are the following:

• Blocks already claimed by another inode

• Block numbers outside the range of the file system

These consistency checks listed are also performed for indirect blocks.

Data Blocks

An inode can directly or indirectly reference three kinds of data blocks. All referenced blocks must be of the same kind. The three types of data blocks are the following:

• Plain data blocks

• Symbolic-link data blocks

• Directory data blocks

Plain data blocks contain the information stored in a file. Symbolic-link data blocks contain the path name stored in a symbolic link. Directory data blocks contain directory entries. The fsck command can check only the validity of directory data blocks.

Directories are distinguished from regular files by an entry in the mode field of the inode. Data blocks associated with a directory contain the directory entries. Directory data blocks are checked for inconsistencies involving the following:

• Directory inode numbers that point to unallocated inodes

• Directory inode numbers that are greater than the number of inodes in the file system

• Incorrect directory inode numbers for "." and ".." directories

• Directories that are disconnected from the file system

Directory Unallocated Checks

If the inode number in a directory data block points to an unallocated inode, the fsck command removes the directory entry. This condition can occur if the data blocks that contain a new directory entry are modified and written out, but the inode does not get written out. This condition can occur if the CPU is shutdown abruptly.

Bad Inode Number Checks

If a directory entry inode number points beyond the end of the inode list, the fsck command removes the directory entry. This condition can occur when bad data is written into a directory data block.

Incorrect "." and ".." Entry Checks

The directory inode number entry for "." must be the first entry in the directory data block. The directory inode number must reference itself; that is, its value must be equal to the inode number for the directory data block.

The directory inode number entry for ".." must be the second entry in the directory data block. The directory inode number value must be equal to the inode number of the parent directory (or the inode number of itself if the directory is the root directory).

If the directory inode numbers for "." and ".." are incorrect, the fsck command replaces them with the correct values. If there are multiple hard links to a directory, the first hard link found is considered the real parent to which ".." should point. In this case, the fsck command recommends that you have it delete the other names.

Disconnected Directories

The fsck command checks the general connectivity of the file system. If a directory is found that is not linked to the file system, the fsck command links the directory to the lost+found directory of the file system. This condition can occur when inodes are written to the file system, but the corresponding directory data blocks are not.

Regular Data Blocks

Data blocks associated with a regular file hold the contents of the file. The fsck command does not attempt to check the validity of the contents of a regular file's data blocks.

The fsck Summary Message

When you run the fsck command interactively and it completes successfully, a message similar to the following is displayed:

# fsck /dev/rdsk/c0t0d0s7
** /dev/rdsk/c0t0d0s7
** Last Mounted on /export/home
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
2 files, 9 used, 2833540 free (20 frags, 354190 blocks, 0.0% fragmentation)
# 

The last line of fsck output describes the following information about the file system:

For information about fragments, see Fragment Size.

Interactively Checking and Repairing a UFS File System

You might need to interactively check file systems in the following instances:

• When they cannot be mounted

• When they develop inconsistences while in use

When an in-use file system develops inconsistencies, error messages might be displayed in the console window, the system messages file, or the system might crash. For example, the system messages file, /var/adm/messages, might include messages similar to the following:

Sep  5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected
free inode 630916, run fsck(1M)

hostname is the system reporting the error.

Before using the fsck command, you might want to refer to Syntax and Options for the fsck Command and "Resolving UFS File System Inconsistencies (Tasks)" in System Administration Guide: Advanced Administration for information on resolving fsck error messages.

Keep the following points in mind when running the fsck command to check UFS file systems:

• A file system should be inactive when using fsck to check that file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck checking process can be interpreted as file system corruption and may not be a reliable indication of a problem.

• A file system must be inactive when using fsck to repair that file system. File system changes waiting to be flushed to disk or file system changes that occur during the fsck repairing process might cause the file system to become corrupted or might cause the system to crash.

• Unmount a file system before using fsck on that file system, to ensure that it is inactive and that all file system data structures are consistent as possible. The only exceptions are for the active root (/) and /usr file systems, because they must be mounted to run fsck.

• If you need to repair the root (/) or /usr file systems, boot the system from an alternate device, if possible, so that these file systems are unmounted and inactive.

  For step-by-step instructions on running fsck on the root (/) or /usr file system, see How to Check the root (/) or /usrFile Systems From an Alternate Boot Device.