Checking UFS File System Consistency (Tasks)
This chapter provides overview information and step-by-step instructions about checking UFS file system consistency.
This is a list of step-by-step instructions in this chapter.
This is a list of the overview information in this chapter.
For information about fsck error messages, see "Resolving UFS File System Inconsistencies (Tasks)" in System Administration Guide: Advanced Administration.
For background information on the UFS file system structures referred to in this chapter, see Chapter 43, UFS File System (Reference).
File System Consistency
The UFS file system relies on an internal set of tables to keep track of inodes used and available blocks. When these internal tables are not properly synchronized with data on a disk, inconsistencies result and file systems need to be repaired.
File systems can be inconsistent because of abrupt termination of the operating system in these ways:
Power failure
Accidental unplugging of the system
Turning off the system without proper shutdown procedure
A software error in the kernel
File system inconsistencies, while serious, are not common. When a system is booted, a check for file system consistency is automatically performed (with the fsck command). Most of the time, this file system check repairs problems it encounters.
The fsck command places files and directories that are allocated but unreferenced in the lost+found directory. A inode number is assigned as the name of unreferenced file and directory. If the lost+found directory does not exist, the fsck command creates it. If there is not enough space in the lost+found directory, the fsck command increases its size.
For a description of inodes, see "Inodes".
How the File System State Is Recorded
The fsck command uses a state flag, which is stored in the superblock, to record the condition of the file system. This flag is used by the fsck command to determine whether a file system needs to be checked for consistency. The flag is used by the /sbin/rcS script during booting and by the fsck -m command. If you ignore the result from the fsck -m command, all file systems can be checked regardless of the setting of the state flag.
For a description of the superblock, see "The Superblock".
The possible state flag values are described in the following table.
Table 42-1 Values of File System State Flags
State Flag Values | Description |
|---|---|
FSACTIVE | When a file system is mounted and then modified, the state flag is set to FSACTIVE. The file system might contain inconsistencies. A file system is marked as FSACTIVE before any modified metadata is written to the disk. When a file system is unmounted gracefully, the state flag is set to FSCLEAN. A file system with the FSACTIVE flag must be checked by the fsck command because it might be inconsistent. |
FSBAD | If the root (/) file system is mounted when its state is not FSCLEAN or FSSTABLE, the state flag is set to FSBAD. The kernel will not change this file system state to FSCLEAN or FSSTABLE. If a root (/) file system is flagged FSBAD as part of the boot process, it will be mounted read-only. You can run the fsck command on the raw root device. Then remount the root (/) file system with read and write access. |
FSCLEAN | If a file system is unmounted properly, the state flag is set to FSCLEAN. Any file system with an FSCLEAN state flag is not checked when the system is booted. |
FSLOG | If a file system is mounted with UFS logging, the state flag is set to FSLOG. Any file system with an FSLOG state flag is not checked when the system is booted. |
FSSTABLE | The file system is (or was) mounted but has not changed since the last checkpoint (sync or fsflush) that normally occurs every 30 seconds. For example, the kernel periodically checks if a file system is idle and, if so, flushes the information in the superblock back to the disk and marks it as FSSTABLE. If the system crashes, the file system structure is stable, but users might lose a small amount of data. File systems that are marked as FSSTABLE can skip the checking before mounting. The mount command will not mount a file system for read and write access if the file system state is not FSCLEAN, FSSTABLE, or FSLOG. |
The following table shows how the state flag is modified by the fsck command, based on its initial state.
Table 42-2 How the State Flag is Modified by fsck
Initial State: Before fsck | State After fsck |
| |
|---|---|---|---|
No Errors | All Errors Corrected |
Uncorrected Errors | |
unknown | FSSTABLE | FSSTABLE | unknown |
FSACTIVE | FSSTABLE | FSSTABLE | FSACTIVE |
FSSTABLE | FSSTABLE | FSSTABLE | FSACTIVE |
FSCLEAN | FSCLEAN | FSSTABLE | FSACTIVE |
FSBAD | FSSTABLE | FSSTABLE | FSBAD |
FSLOG | FSLOG | FSLOG | FSLOG |
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 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. Blocks can become damaged on a disk drive at any time, or a disk controller can stop functioning correctly.