fsck

Check and Repair Filesystems

The UNIX filesystem is surprisingly reliable and it does a remarkable job of coping with unexpected system crashes and flaky hardware. However, filesystems can become damaged or inconsistent in a number of ways.

Any time the kernel panics or the power fails, small inconsistencies may be introduced into the filesystems that were active immediately preceding the crash. Since the kernel buffers both data blocks and summary information, the most recent image of the filesystem is split between disk and memory. During a crash the memory portion of that image is lost. The buffered blocks are effectively “overwritten” with the versions that were most recently saved to disk.

There are a couple of approaches to fixing this problem. Minor damages can usually be fixed with the fsck command. This is not a very architecturally elegant way of approaching the issue, but it works pretty well for all of the common inconsistencies.

The five most common types of damage are:

Unreferenced inodes

Inexplicably large link counts

Unused data blocks not recorded in the block maps

Data blocks listed as free that are also used in a file

Incorrect summary information in the superblock fsck can safely and automatically fix these five problems. If fsck makes corrections to a filesystem, you should rerun it until the filesystem comes up completely clean.

Disks are normally checked at boot time with fsck -p which examines all local filesystems listed in /etc/vfstab and corrects the five errors listed above. Solaris keeps track of which file systems were unmounted cleanly and checks only the “dirty” ones.

For example fsck can be run on a particular filesystem

# fsck -p /dev/rsd0g

Errors that do not fall into one of the five categories above are potentially serious. They cause fsck -p to ask for help and then quit. In this case, run fsck without the –p option. When run in manual mode, fsck asks you to confirm each of the repairs that it wants to make. The following list shows some of the errors that fsck considers dangerous enough to warrant human intervention:

Blocks claimed by more than one file

Blocks claimed outside the range of the filesystem

Link counts that are too small

Blocks that are not accounted for

Directories that refer to unallocated inodes

Various format errors

In practice this state of affairs means that you have little choice but to accept the fixes proposed by fsck. You can minimize problems by carefully recording the messages that fsck produces since they will sometimes provide a clue about the file or files that are causing problems. If fsck asks for permission to delete a file, you should try to copy it to a different filesystem before allowing fsck to proceed. Be aware that any time you attempt to access a damaged filesystem, you risk panicking the operating system.

If fsck finds a file whose parent directory cannot be determined, it will put the file in the lost+found directory in the top level of the filesystem. Since the name given to a file is recorded only in the file’s parent directory, names for orphan files will not be available and the files place in lost+found will be names with their inode numbers.