Crash Consistency

Suppose a process creates:

The operation looks like one action to the application. Inside the file system, it can require several persistent updates:

Now imagine power fails after only some of those updates reach storage.

The directory might contain a name whose inode was never initialized. A block might be marked free even though an inode points to it. An allocated inode might become unreachable, leaking space.

Preventing or repairing such partial states is the problem of crash consistency.

A crash-consistent file system preserves its structural invariants across an abrupt stop, even when one logical operation required several persistent writes.

Crash consistency does not necessarily preserve the newest application data. A file system can recover to an older but valid state.

This chapter develops the crash failure model and file-system invariants, analyzes partial multi-block operations, ordering, atomicity, durability, and torn writes, and examines checking, recovery protocols, safe replacement, and crash testing.