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.

fsck -t systemtype device

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

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.

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.

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