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).

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)?

Log in or register to write something here or to contact authors.