Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
  Previous   Contents   Next 
   
 
Chapter 42

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.

 
 
 
  Previous   Contents   Next