crash consistency

Suppose you are updating a paper ledger: erase the old balance, write the new one, then update the running total at the top. If someone yanks the page away after the first step but before the others, the ledger is now self-contradictory. A file system faces the same danger constantly, because one logical action — say, creating a file — actually requires several separate disk writes: allocate a block in the bitmap, write the inode, add the directory entry. A crash in the middle leaves the disk in an inconsistent state. Crash consistency is the property (and the techniques to achieve it) that the file system can always be brought back to a sensible state after an unexpected crash or power loss.

The danger is that disk writes are not atomic across multiple blocks: the file system cannot update the bitmap, the inode, and the directory in one indivisible step. If power fails after the bitmap marks a block used but before the inode records owning it, that block is leaked — marked used but belonging to no file. If it fails after the directory points to an inode but before the inode is written, the directory points at garbage. The naive recovery is to scan the entire file system at boot with a tool like fsck, painstakingly cross-checking every structure and patching contradictions — correct, but agonizingly slow on a large disk and not guaranteed to recover your data, only to make the metadata self-consistent.

Because full scans are too slow, modern file systems engineer crash consistency in. The main approaches are journaling (write a description of the change to a log first, so recovery can redo or discard the half-done update), soft updates (carefully order the writes so the on-disk state is always consistent even if interrupted), and copy-on-write (never overwrite live data; write new versions elsewhere and switch over atomically). One honest limitation runs through all of them: by default these techniques protect the file system's METADATA — its own bookkeeping — and not necessarily your file's DATA. After a crash the file system may be perfectly consistent while the last few seconds of what you typed are simply gone.