What the fsck Command Checks and Tries to Repair
This section describes what happens in the normal operation of a file system,
what can go wrong, what problems the fsck command (the checking and repair utility)
looks for, and how this command corrects the inconsistencies it finds.
Why UFS File System Inconsistencies Might Occur
Every working day, hundreds of files might be created, modified, and removed. Each
time a file is modified, the operating system performs a series of file
system updates. These updates, when written to the disk reliably, yield a consistent
file system.
When a user program does an operation to change the file system,
such as a write, the data to be written is first copied into
an in-core buffer in the kernel. Normally, the disk update is handled asynchronously.
The user process is allowed to proceed even though the data write might
not happen until long after the write system call has returned. Thus, at
any given time, the file system, as it resides on the disk, lags
behind the state of the file system that is represented by the in-core
information.
The disk information is updated to reflect the in-core information when the buffer
is required for another use or when the kernel automatically runs the fsflush
daemon (at 30-second intervals). If the system is halted without writing out
the in-core information, the file system on the disk might be in an
inconsistent state.
A file system can develop inconsistencies in several ways. The most common causes
are operator error and hardware failures.
Problems might result from an unclean shutdown, if a system is shut down improperly,
or when a mounted file system is taken offline improperly. To prevent unclean
shutdowns, the current state of the file systems must be written to disk
(that is, “synchronized”) before you shut down the system, physically take a disk
pack out of a drive, or take a disk offline.
Inconsistencies can also result from defective hardware or problems with the disk or
controller firmware. Blocks can become damaged on a disk drive at any time.
Or, a disk controller can stop functioning correctly.
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 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 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. 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
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
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
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:
Regular
Directory
Block special
Character special
FIFO (named pipe)
Symbolic link
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. However, these inodes 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 one 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. However, 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.
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 duplicate blocks are found, the fsck command makes a second pass of
the inode list to find the other inode that claims each duplicate block.
The fsck command cannot determine with certainty which inode is in error. So,
the fsck command prompts you to choose which inode should be kept and
which inode should be cleared. Note that a large number of duplicate blocks
in an inode might be caused by an indirect block not being written
to the file system
Bad Block Number Checks
The fsck command checks each block number claimed by an inode to determine
whether its value is higher than the value 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 uses the
number of characters shown in the size field to calculate how many blocks
should be associated with the inode, and then compares that number 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:
These consistency checks listed are also performed for direct 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 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 shut down 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 that is not linked to the file system is found, 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. However,
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.
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 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder 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:
- # files
Number of inodes in use
- # used
Number of fragments in use
- # free
Number of unused fragments
- # frags
Number of unused non-block fragments
- # blocks
Number of unused full blocks
- % fragmentation
Percentage of fragmentation, where: free fragments x 100 / total fragments in the file system
For information about fragments, see Fragment Size.
