It is sometimes necessary to check your Linux filesystem for errors and consistency, and to repair them if there are any errors or Lost Data. Such errors are often caused by a Power Failure or a crash, where the kernel isn't able to sync the filesystem buffer cche with the contents of the disk.

In most cases, such errors are relatively minor. However, if the system were to crash while writing a large file, that file may be lost and the blocks associated with it marked as "in use" when there is no file entry corresponding to them. In other situations, the hard drive device can claim errors because of accidently writing data directly to it (for instance, /dev/hda) or one of the partititons.

We use the program fsck to check the filesystems for any such errors and to correct them. fsck is actually a front end for filesystem specific File Ssystem Checkers in a fsck.systemtype method. (of course if the fsck frontend is not installed, since fsck.systemtype is a symbolic link, you could just run that directly.)

The use of fsck is rather easy, The syntax is

fsck -t systemtype device

For instance, if you wanted to fsck an ext2 filesystem on /dev/hda5 we use:

root@ragu# fsck -t ext2 /dev/hda5
Parallelizing fsck version 0.5a (5-Apr-94)
e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5 94/03/10
/dev/hda5 is mounted. Do you really want to continue (y/n)? yes

Lets note that the system asks for confirmation before checking a mounted filesystem, if any errors are found and corrected while using fsck you'll need to reboot the system so the changes made by fsck can be noted by the system and written into it's internal knowledge of the filesystem layout. In general, it's a bad idea to check mounted filesystems, so don't do it unless you absoloutely have no other choice.

"But how do I check a filesystem if it's unmounted?"

Uhhh, you unmount it then you run fsck on it, silly goose. Of course this doesn't work on the root filesystem, which is probaly what you were talking about. If you want to fsck the root filesystem while it's unmounted, you could use a boot/root linux floppy combination, like say... the installation floppies used by your linux distribution.

Mounting your system as read only with "Lilo: ro" is another good option, but other parts of your system configuration (like the programs in /etc/init, that you may wanna run at boot time) may require write access to the root filesystem, so you can't boot the system normally or these programs will fail. Which means we use The boot option of single. This prevents additional system configging at boot time, then you can check the root filesystem and reboot normally.

special thanks to O'Reilly's Running Linux by Matt Welsh and Lar Kaufman, who I take implied psychic consent from to use their work, even though I did change alot of what they said about this.