Creating partitions and filesystems are tasks you're likely to perform every once in a while—say, when adding a new hard disk or making major changes to an installation. Another task is much more common, though: checking a
filesystem for errors. Bugs, power failures, and mechanical problems can all cause the data structures on a filesystem to become corrupt. The results are sometimes subtle, but if they are left unchecked, they can cause severe data loss. For this reason, Linux includes tools to verify a filesystem's integrity, and to correct any problems that might exist. The main tool you'll use for this purpose is called fsck. Like mkfs, fsck is actually a front-end to other tools, such as e2fsck (aka fsck.ext2). The syntax for fsck is as follows:
fsck [-sACVRTNP] [-t fstype] [--] [fsck-options] ^filesystems
The following list contains the meanings of the more common parameters to this command:
-A This option causes fsck to check all the filesystems marked to be checked in /etc/fstab. This option is normally used in system startup scripts.
-C This option displays a text-mode progress indicator of the check process. Most filesystems don't support this feature, but ext2fs does.
-V This option produces verbose output of the check process.
-N This option tells fsck to display what it would normally do, without actually doing it.
-t fstype Normally, fsck determines the filesystem type automatically. You can force the type with this flag, though. If used in conjunction with -A, this causes the system to check only the specified filesystem types, even if others are marked to be checked. If fstype is prefixed with no, then all filesystems except the specified type are checked.
-- fsck-options Filesystem check programs for specific filesystems often have their own options. fsck passes options it doesn't understand, or those that follow a double dash (--), to the underlying check program. Common options include -a or -p (perform an automatic check), -r (perform an interactive check), and -f (force a full filesystem check even if it appears to be clean).
filesystems This is the name of the filesystem or filesystems being checked, such as /dev/sda6.
Normally, you run fsck with only the filesystem name, as in fsck /dev/ sda6. You can add options as needed, however. Check the fsck man page for less common options.
Run fsck only on filesystems that are not currently mounted, or that are mounted in read-only mode. Changes written to disk during normal read/ write operations can confuse fsck and result in filesystem corruption.
Linux runs fsck automatically at startup on partitions that are marked for this in /etc/fstab, as discussed in Chapter 6, "Managing Files and Services." The normal behavior of e2fsck causes it to perform just a quick cursory examination of a partition if it's been unmounted cleanly. The result is that the Linux boot process isn't delayed because of a filesystem check unless the system wasn't shut down properly. There are a couple of exceptions to this rule, though: e2fsck forces a check if the disk has gone longer than a certain amount of time without checks (normally six months), or if the filesystem has been mounted more than a certain number of times since the last check (normally 20). Therefore, you will occasionally see automatic filesystem checks of ext2fs partitions even if the system was shut down correctly.
A new generation of filesystems, exemplified by ext3fs, ReiserFS, JFS, and XFS, does away with filesystem checks at system startup even if the system was not shut down correctly. These journaling filesystems keep a log of pending operations on the disk so that in the event of a power failure or system crash, the log can be checked and its operations replayed or undone to keep the filesystem in good shape. This action is automatic when mounting such a filesystem. Nonetheless, these filesystems still require check programs to correct problems introduced by undetected write failures, bugs, hardware problems, and the like. If you encounter odd behavior with a journaling filesystem, you might consider unmounting it and performing a filesystem check—but be sure to read the documentation first. In mid-2001, Linux's journaling filesystems were still largely experimental, and the support utilities (including filesystem check programs) were under active development and were potentially buggy.
Was this article helpful?