fsck

Often fsck seems to be used as an explitive in many a geek conversation on the 'net. As far as using it to check a filesystem I suggest seeing man fsck for the down low.

Note: the past tense is usually spelled fsck'd.

At a company I worked for in England, I learnt that the true pronunciation of "fsck" is "fiz-check" (with a very short "i" sound).

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.

How fsck works:

The fsck utility verifies all the links and blocks. It starts with the superblock, then moves on to the allocated disk blocks, pathnames, directories, link reference counts and the free blocks/inodes. This is usually done in five passes in UNIX. Note that in IRIX machines the xfs utility has replaced the fsck utility.

Every change in the filesystem affects the superblock in RAM. It is periodically written to the hard drive. If the superblock is corrupt, fsck will correct it. The superblock counts the free blocks and inodes. The fsck utility runs in five passes or phases:

1. Check blocks and inodes
   The fsck utility checks the inode list for invalid entries. It compares the inode entries to the blocks that the actual files use.

2. Check pathnames
   The fsck utility removes directory entries discovered from bad inodes and looks for directories that have inode pointers that index out-of-range or point to bad inodes.

3. Check connectivity
   The fsck utility looks for unreferenced or orphaned directories. Should one be found, it is placed in the lost+found directory.

4. Check reference counts
   Using information from pass two and three, the fsck utility looks for unreferenced files and bad link counts.

5. Check cylinder grouping
   The last pass looks at the resulting free blocks and inode maps. It creates an updated map from the corrections made during pass one through four.

The fsck utility cannot fix everything, but it will let you know that there is a problem with any part of the file system. You may (often) need to perform data recovery yourself manually.

Of course, if you have a journalling filesystem such as ufs or xfs (or even ntfs), fsck becomes largely redundant.

Rather than having to check the entire filesystem in the event of an error, the filesystem is simply rebuilt by consulting the journal. As the journal is updated by the operating system before any change is committed to disk, the uncomitted changes made before the crash can be brought into sync, bringing the filesystem back to a coherent state much more quickly.

This is infinitely useful with a system with large numbers of drives.

After reading the entry by Shanoyu, I thought this was pretty funny:

# fsck -t ext2 /dev/hotbabe
...
/dev/hotbabe is mounted. Do you really want to continue (y/n)?