The fsck tool short for File System ChecK

French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

Using fsck

The fsck tool, short for File System ChecK, is used to diagnose and repair file systems that may have become damaged in the course of daily operations. Such repairs are usually necessary after a system crash in which the system did not get a chance to fully flush all of its internal buffers to disk. (Although this tool’s name bears a striking resemblance to one of the expressions often uttered after a system crash, that this tool is part of the recovery process is strictly coincidence.) Usually, the system runs the fsck tool automatically during the boot process (much in the same way Windows runs Scandisk) if it detects a partition that was not cleanly unmounted. Linux makes an impressive effort to automatically repair any problems it runs across and in most instances does take care of itself. The robust nature of the ext3 file system helps in such situations. Nevertheless, it may happen that you get this message: Your system appears to have shut down uncleanly Press Y within 5 seconds to force file system integrity check If you press Y, you’ll see messages appear on the screen telling you how the check is proceeding. The system will tell you what file system is being checked and how far the check has progressed. You may see messages such as these:

    recovering journal
    clearing orphaned inode

These messages are normal; fsck is just doing its thing. If you find that a file system is not behaving as it should (log messages are excellent hints to this situation), you may want to run fsck yourself on a running system. The only downside is that the file system in question must be unmounted in order for this to work. If you choose to take this path, be sure to remount the file system when you are done.

NOTE

The name fsck isn’t the proper title for the ext2/ext3 repair tool; it’s actually just a wrapper. The fsck wrapper tries to determine what kind of file system needs to be repaired and then runs the appropriate repair tool, passing any parameters that were passed to fsck. In ext2 and ext3, the real tool is called e2fsck. When a system crash occurs, you may need to call e2fsck directly rather than relying on other applications to call it for you automatically.

Parameters Available for e2fsck

The parameters available for e2fsck are shown in Image 7-4. For example, to run e2fsck on the /dev/hda3 file system, you would run:

[root@tedford /root]# e2fsck /dev/hda3

To force a check and automatically answer Yes to any prompts that come up, you would enter this command:

    [root@tedford]# e2fsck -f -y /dev/hda3
    

TIP

You won’t find an “e3fsck” command. The ext2 and ext3 file systems are so similar that the e2fsck command works on both of them.

What If I Get Errors?

First, relax. The fsck check rarely finds problems that it cannot correct by itself. When it does ask for human intervention, telling fsck to execute its default suggestion is often enough. Very rarely does a single pass of e2fsck not clear up all problems. On the rare occasions when a second run is needed, it should not turn up any more errors. If it does, you are most likely facing a hardware failure. Remember to start with the obvious: Check for reliable power and well-connected cables. Anyone running SCSI systems should verify that they’re using the correct type of terminator, that cables aren’t too long, that SCSI IDs aren’t conflicting, and that cable quality is adequate. (SCSI is especially fussy about the quality of the cables.)

The lost+found Directory

Another rare situation is when e2fsck finds segments of files that it cannot rejoin with the original file. In those cases, it will place the fragment in the partition’s lost+found directory. This directory is located where the partition is mounted, so if /dev/hda3 is mounted on /usr, then /usr/lost+found correlates to /dev/hda3. Anything can go into a lost+found directory—file fragments, directories, and even special files. When normal files wind up there, a file owner should be attached, and you can contact the owner and see if they need the data (typically, they won’t). If you encounter a directory in lost+found, you’ll most likely want to try to restore it from the most recent backups rather than trying to reconstruct it from lost+found. At the very least, lost+found tells you if anything became dislocated. Again, such errors are extraordinarily rare.