Journaling

Imagine a service creates a file containing a newly generated invoice. One logical create can modify several file-system structures:

If power fails while those blocks are being updated in place, storage can contain an arbitrary mixture of their old and new versions. A full consistency checker can search for the damage, but scanning a large file system after every unclean shutdown is expensive.

A journal gives recovery a smaller and more precise source of truth. Before installing a related set of changes in their normal locations, the file system records the changes in a dedicated log. A persistent commit record marks the set as complete.

Journaling turns a multi-block file-system update into a recoverable transaction by writing enough information to a log before reusing or relying on the normal on-disk locations.

After a crash, recovery does not have to rediscover every interrupted operation from the entire file system. It examines the journal, replays complete transactions, and ignores incomplete ones.

This chapter follows journal transactions through write-ahead logging, commit, checkpoint, and recovery, compares metadata, ordered, writeback, and data journaling, and explains replay, circular logs, costs, and guarantee boundaries.