Checking Filesystems: The fsck Command

. . .

353 root

6 bin

5.6.4 Checking Filesystems: The fsck Command

A filesystem can be corrupted by any number of things: operator errors, hardware failures, etc. The fsck command (it stands for filesystem check) checks the filesystem’s consistency, reports any encountered problems, and optionally tries to repair them (sometimes such repairs can cause minor data loss). The fsck command interactively repairs inconsistent filesystem conditions.

fsck can encounter the following filesystem problems:

• One block belonging to several files (inodes)

• Blocks marked as free but in use

• Blocks marked as used but free

• Incorrect link counts in inodes, indicating missing or excess directory entries

• Incorrect directory sizes

• Inconsistencies between inode size value and the amount of data blocks referenced in the address field

• Illegal blocks (e.g., system tables) within files

• Inconsistent data in the filesystem’s tables

• Lost files (nonempty inodes that fully identify files not listed in any directory) — fsck places these orphaned files in the filesystem directory named lost+found (each filesystem has its own lost+found directory), so they can be recognized later by owners and reused; the name assigned to a lost file corresponds to the inode number

• Illegal or unallocated numbers in directories

On BSD, the fsck command is run automatically on boots and reboots. On System V, fsck is run at boot time on nonroot filesystems only if they have not been dismounted cleanly, i.e., if the system crashed. A manual run of the fsck command is needed only occasionally: at boot, when fsck’s automatic mode cannot fix all encountered problems, after creating a new filesystem (although it is a good idea to reboot the system upon filesystem creation, if possible), and under a few other circumstances. Nevertheless, a system administrator should understand how the fsck command works to be able to quickly recognize abnormal situations.

The syntax of the fsck command is:

fsck[options] spec_ file where

spec_file The name of the filesystem’s special file options Available options:

-n|-N Answer no to all prompts, and list problems but do not repair them -y|-Y Answer yes to all prompts (Be careful when using this option! It repairs

all damage regardless of the severity!)

-p Preens the filesystem and performs noninteractive repairs that do not change any file’s contents

-bnn Use an alternate superblock located at nn-th block -m Perform a sanity check only — do not repair

-q Quiet mode; removes nonreferenced named pipes and reconstructs the free list without comment

-f Force filesystem checking regardless of the superblock status -Ftype Specify a filesystem type to be fsck-ed

-V Echo, but do not execute, the command; verify and validate a com-mand line

The fsck command runs faster on character special files. However, the block device must be used for the root filesystem. If the filesystem is not specified, the fsck command checks all filesystems listed in the filesystem configuration file (/etc/fstab, or /etc/vfstab);

this happens at boot time. Under AIX, the checking of filesystems is determined in the filesystem configuration file /etc/filesystems (if the keyword check is true for a corresponding filesystem).

Normally, the fsck command runs with -p option, i.e., it silently fixes the following problems:

• Link counts in inodes too large

• Missing blocks in the free list

• Blocks in the free list and also in files

• Incorrect counts in the filesystem’s table

• Nonreferenced zero-length files deleted

• Lost files placed in the filesystem’s lost+found directory, and named by their inode number

More serious errors will be handled with a prompt for confirmation.

Iffsck modifies any filesystem, it will display the message:

*** FILESYSTEM WAS MODIFIED ***

If the root filesystem is modified, an additional message also appears:

*** REBOOT UNIX ***

or

***** REMOUNTING ROOT FILESYSTEM ****

When modifications happen during a boot procedure, the reboot, or remount, is initiated automatically. If the fsck has been executed from the command line on the root filesystem, then the reboot command has to be started manually, too:

# reboot -n

The -n option is very important to prevent previous execution of the sync command, which flushes the output buffers and might, under these circumstances, recorrupt the filesystem (the only case when the system is rebooted without sync-ing the disks).

An example (from the Apollo workstation and HP-UX):

$fsck -y

fsck: /dev/dsk/c201d6s0: root file system continue (y/n)? y

** /dev/dsk/c201d6s0

** Last Mounted on/

** Root file system

** Phase 1 — Check Blocks and Sizes

** Phase 2 — Check Pathnames

** Phase 3 — Check Connectivity

** Phase 4 — Check Reference Counts

FREE INODE COUNT WRONG IN SUPERBLK FIX? yes

** Phase 5 — Check Cyl groups

SUMMARY INFORMATION (SUPER BLOCK SUMMARIES) BAD BAD CYLINDER GROUPS

FIX? yes

** Phase 6 — Salvage Cylinder Groups

21806 files, 0 icont, 296674 used, 128312 free (1472 frags, 15855 blocks)

***** MARKING FILE SYSTEM CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****

***** REBOOT HP-UX; DO NOT SYNC (USE reboot -n) *****

It is not the end of the world to have messages about filesystem inconsistencies during system startup. As long as the fsck command can fix them, sometimes even in several attempts, everything will be fine. However, it can be very upsetting if fsck fails; the failure

usually indicates a more serious filesystem problem, frequently, a hardware-related problem that requires a more radical approach. The fsck command can resolve many logical inconsistencies, but it cannot repair a broken disk.

fsck is a very time-consuming command; for a large filesystem, a complete check can take a while. This is why filesystems that were cleanly dismounted during system shutdown are skipped — they will have no problems and checking them is a waste of the time. Also, the journaled filesystem (the jfs type) is the most robust with regards to corruption; if it is corrupted, the recovery is much faster. The price paid for such robustness is additional overhead in the filesystem use; the online journaling of filesystem transactions requires more resources and time.

6