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 damaged or become inconsistent because of abrupt termination of the operating system in these ways:
Accidental unplugging of the system
Turning the system off without proper shutdown procedure
A software error in the kernel
File system corruption, while serious, is not common. When a system is booted, a file system consistency check is automatically performed (with the fsck program). Most of the time, this file system check repairs problems it encounters.
This chapter describes what the fsck program checks and repairs, and the fsck options. It also describes the following tasks:
How to modify the automatic checking done during booting
How to find out if a file system needs to be checked
How to check and repair a UFS file system interactively
How to restore a bad superblock
How to fix a UFS file system that fsck cannot repair
The fsck error messages are covered in "Troubleshooting File System Problems" in System Administration Guide, Volume 2.
The fsck program places files and directories that are allocated but unreferenced in the lost+found directory. The inode number of each file is assigned as the name. If the lost+found directory does not exist, fsck creates it. If there is not enough space in the lost+found directory, fsck increases its size.