Most of us have been editing a file when our system crashed. We were much chagrined when we restarted the system and found that the editing we had worked so long on had disappeared. Most of us accept this as our mistake: we should have saved the file periodically to ensure that the majority of our work was permanent. 

This same sequence of events occurs outside of your control on every modern operating system. Any time a file is updated, the update occurs first to a copy of the data in-memory. At a later time, the data is written to the disk. Thus, each filesystem mounted into the Unix filesystem is referred to as having an on-disk state (the saved state, if you wish), and an in-memory state. Usually these two states are very close. When the filesystem is detached from the system by umount, the two states are synchronized. This is called sync-ing the disk. The umount command will not succeed if a process is accessing the filesystem and until all pending filesystem writes are complete.  (Note: there is a command, sync, which can be used to flush any pending writes on the filesystems. Historically, Unix Administrators would type this command several times prior to rebooting the system. This happens as part of the normal shutdown process, but if you ever have to physically remove the power from a Unix system without shutting it down, using the sync command is a good idea first. (Of course, if you cant shut the system down, it probably isn't responding, so it wont accept the sync command either.) Why several times? It so happens that the sync command is asynchronous, and it returns before the flush is complete. The idea was that typing it a few times gave the system long enough to actually write the changes.)

One of the parameters kept in the superblock is a flag used to indicate whether the filesystem was unmounted gracefully (i.e., using umount). It indicates whether the filesystem can be relied upon to be in a consistent state. This flag has two possible values: clean and dirty. When the filesystem is mounted, this flag is marked dirty. If the filesystem is later detached gracefully with umount, the flag is marked clean. (Journaled filesystems are always marked clean. The journal is used to recover the filesystem rather than checking it.)

At boot, each filesystem is checked before mounting to ensure it is clean. If not, the filesystem checking program fsck is run on the filesystem before mounting. fsck will do whatever is needed to place the filesystem in a consistent state. Normally this is nondestructive, although it may result in scavenging some files that have not been named and saving them for later examination.

You can run fsck on any unmounted filesystem before you mount it. You should do this on manually-mounted filesystems if there is any reason to suspect the filesystem was not cleanly unmounted. Clean filesystems are not checked - if fsck is asked to check a filesystem that is marked 'clean', it simply exits, indicating the filesystem is clean. 

Running fsck

fsck is simple to run. As with most utilities, it has lots of options, but only a few are often used. 

fsck [-t fstype] [-y] [-A] [-f] [other options] {device | mount point }

The simplest way to run fsck is to tell it the filesystem type and the device.  If the filesystem you want to check is in the filesystem table (fstab), fsck will use that information to determine its type and device. In this case, you can give fsck the mount point instead of the device. 

The important options are:

• -t fstype  the type of the filesystem (ext2, ext3, dos, reiserfs, etc). This is required if the filesystem type is not in the file system table.
• -y  answer 'yes' to all fsck's questions automatically.
• -A  automatically check all the filesystems indicated in the file system table (fstab)
• -f  force the check even if the filesystem is marked 'clean'. Normally fsck will quit immediately if the filesystem is 'clean'. You can force an fsck of the root filesystem (only) by creating a file named /forcefsck before rebooting.
  

The filesystem you check must be unmounted. Never run fsck on a mounted filesystem.

The program fsck is actually a front-end to a number of filesystem-specific fsck programs. The -t option tells fsck which filesystem-specific fsck to invoke. The options above are for the fsck front-end. The individual fsck programs have options of their own. To investigate these, examine their man pages as man fsck.filesystem, such as fsck.ext3 or fsck.vfat. (Note: this is true of the mkfs program as well. Information on the individual filesystem-specific mkfs programs are similarly available by man mkfs.filesystem.)

Filesystem errors

When fsck finds a problem with the filesystem, it reports it and asks if you want to fix it. The questions it asks are usually just for verification purposes, but their content always sounds alarming. Very few administrators are equipped to understand fully the questions fsck asks, much less answer them intelligently. Further, if you answer any question 'no', fsck may stop checking the filesystem. Unless you really know what you are doing, it is usually better to simply answer 'yes'  and admit that fsck knows intimately more about the issues than you do. Fortunately for the filesystem, this is the case. fsck has an option, -y, that simply answers 'yes' to all questions for you.

One of the most common types of problems to find on the filesystem, and one which you want fsck to remedy, is an unreferenced inode. As discussed earlier, this is a complete file that has an inode associated with it, but no name. If you choose to 'reattach' these files (when fsck asks you about them), fsck will attempt to place them in the lost+found directory, assigning their inode numbers as names. If this happens, it is imperative that you go to the lost+found directory on that filesystem and decide the fate of each of the inodes. Then delete them from lost+found. This directory has limited space, and fsck cannot increase its size during the check operation. If fsck needs to reattach an orphaned inode and the lost+found directory does not exist (because some idiot deleted it) or it is full (because some administrator was lazy), the newly-found unreferenced inode will be discarded.

Filesystem checking at boot

All filesystems are checked at boot. If the system was shut down cleanly, they will be marked 'clean', which short-circuits the checking process. Any filesystem that was not found 'clean' will be checked. journaled filesystems will usually be checked quickly due to the journal. ext2 filesystems will be checked completely, which can be time consuming.

A complete check of ext3 and ext4 filesystems is forced periodically. This parameter, which is part of the filesystem parameters, is initialized when the filesystem is created. It is usually set to a certain number of days and/or a certain number of mounts. When this number runs out, the next boot forces a complete check of the filesystem. This 'forced checking' parameter on a filesystem can be altered using tune2fs(8)