
sun.com \| docs.sun.com	How To Buy \| My Sun \| Worldwide Sites

Previous Contents Index Next Next

Chapter 43

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 44, 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 43-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 43-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 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.