Checking and repairing a Linux filesystem with fsck

What fsck actually checks

A filesystem keeps its own internal bookkeeping: which blocks belong to which file, which blocks are free, directory entries, and various counters and flags that describe the filesystem's own state. Under normal operation that bookkeeping stays consistent. It can fall out of sync after an unclean shutdown (a power loss or a hard reset that interrupts writes mid-flight), after certain kinds of hardware fault, or occasionally after a kernel bug. fsck (filesystem check) walks that bookkeeping, looks for inconsistencies, and, where it's confident about the correct fix, repairs them.

fsck itself is really a front end. It looks at the filesystem type on the target device and hands off to the specific checker for that type, for example e2fsck for ext2/ext3/ext4. You can call e2fsck directly if you want finer control over ext4-specific options than the generic fsck front end exposes, but for routine use fsck is simpler since it works out which checker to run for you.

Why it needs to run unmounted

A mounted, actively used filesystem keeps changing underneath you: files are written, deleted, and metadata updates as normal system activity continues. Running a consistency check against a moving target means fsck can misread structures that are mid-update, and in the worst case its own repair actions can collide with a live write and cause more damage than the original inconsistency. That's why fsck is meant to run against a filesystem that isn't mounted, or that's mounted strictly read-only.

For a server's root filesystem, that's awkward: you can't easily unmount the filesystem the running OS is using. This is exactly the kind of task rescue mode exists for. Booting into a separate, minimal environment means the disk you need to check isn't in use by anything, so fsck can run against it cleanly from outside.

Basic invocation

Point fsck at the partition's device path, not at a mount point:

fsck /dev/sdb1

Run without any flags, fsck checks the filesystem and, when it finds an inconsistency, prompts you interactively before making each repair. That's useful when you want to see exactly what it's proposing to change. When you already know you want every suggested repair applied without being asked each time, add -y to answer yes automatically:

fsck -y /dev/sdb1

Use -y deliberately. On a filesystem with structural damage, auto-accepting every fix can occasionally mean data ends up in lost+found rather than back exactly where it was, generally still better than leaving known corruption in place, but worth knowing before you run it unattended.

Reading the exit code

fsck's exit code is a bitmask, not a simple pass/fail flag, several conditions can be signalled at once by adding their values together. At a high level:

Treat this table as a rough guide rather than the final word. The exact bit meanings are documented in fsck's own manual page (man fsck), and it's worth checking that directly rather than guessing when an automated script or monitoring check needs to act on a specific code.

Before you run it

If you suspect the underlying drive itself is failing, rather than just the filesystem sitting on it, check the drive's health first, see How to recognise a bad drive in Linux. Running repeated filesystem repairs against a physically failing drive tends to produce the same errors again on the next check. Once the filesystem passes clean, mount it as usual, see Mounting a disk in Linux.