Skip to content
Kernelpedia

Journaling

Journaling is a technique for recovering from a crash or power loss without scanning an entire volume to find the damage. ext2 has no such technique: it records a state field to detect an uncleanly unmounted volume, one left mid-write, and then relies on a full fsck pass over the entire volume to find and fix whatever the interruption left inconsistent. ext3 and ext4, among other later filesystems, adopted journaling specifically to avoid that full scan, by changing how a write reaches disk in the first place rather than only reacting after the fact.

Write-ahead logging

Section titled “Write-ahead logging”

The core idea is write-ahead logging: before a change is applied to a filesystem’s main on-disk structures (an inode table, a bitmap, a directory block), the intent of that change is first written to a separate, sequential journal region reserved specifically for this purpose. Only once that journal entry is safely on disk does the filesystem go on to apply the actual change to its main structures; if a crash happens between those two steps, the journal still holds a complete, self-contained record of what was supposed to happen, rather than main structures left in some unknown partial state with no record of what was in progress at all.

1. Write intent to journal:  "update inode 42: size 4096 -> 8192"
2. Journal entry committed (fsync'd, marked complete)
3. Apply the actual change to inode 42 in the main filesystem structures
4. Mark the journal entry as checkpointed (no longer needed for recovery)

A journal entry typically groups every change belonging to one logical operation (a file rename touching a directory entry and possibly an inode) into a single transaction, committed to the journal as one atomic unit rather than as several independent writes that could themselves be interrupted midway through, which is what lets the technique guarantee that recovery only ever sees a transaction as either fully present or entirely absent from the journal, never half-recorded.

Recovery

Section titled “Recovery”

Because the journal already contains a complete, ordered record of every recent change’s intent, recovery after an unclean shutdown has a specific, bounded amount of work to do rather than an open-ended scan of the entire volume: replay every committed transaction that hadn’t yet been checkpointed to the main structures, and discard any transaction that was only partially written to the journal itself when the crash occurred (detectable because a transaction commits with a specific marker only once every part of it has reached disk). This is the concrete improvement journaling makes over ext2’s approach: recovery cost scales with how much was journaled since the last checkpoint, typically a small, recent window, rather than with the size of the entire volume the way a full fsck pass does, since only the journal itself needs to be read and replayed.

What gets journaled

Section titled “What gets journaled”

Metadata-only journaling, the default mode for ext3 and ext4, protects a filesystem’s own bookkeeping structures (inodes, bitmaps, directory entries) but not necessarily the file data blocks a write is actually modifying, which means a crash can still leave a file’s content in an inconsistent state even though the filesystem’s own structure describing that file remains consistent and mountable. Full data journaling additionally writes actual file data through the journal before it reaches its final location, giving stronger guarantees about data itself surviving a crash, at a real performance cost: every byte of file data effectively gets written to disk twice, once to the journal and once to its final location, rather than once. Most general-purpose deployments default to metadata-only journaling specifically because that tradeoff, guaranteed structural consistency without doubling ordinary write traffic, is what most workloads actually need; a workload where losing recently-written file content is genuinely unacceptable is what full data journaling exists for.

Implementation notes

Section titled “Implementation notes”

The journal itself is a reserved, fixed-size region of the volume, sized and allocated once (often at filesystem-creation time), and treated specially by the filesystem code: it needs to be written sequentially and its own writes need to reach disk in a well-defined order relative to the transaction commit marker, since a filesystem that reorders or delays journal writes the same way it might reorder ordinary data writes for performance would defeat the entire technique’s guarantee. A journal that fills up before its oldest entries have been checkpointed to the main structures also has to force those checkpoints to happen (or block new writes) rather than silently overwriting still-needed journal entries, since a filesystem crashing at that point with a corrupted or overwritten journal loses exactly the safety net the whole mechanism exists to provide.

References

Section titled “References”
  1. ^ S. Tweedie, “Journaling the Linux ext2fs Filesystem,” LinuxExpo, 1998: the original design paper introducing ext3’s journaling layer on top of ext2’s existing on-disk format.
  2. ^ M. Rosenblum and J. Ousterhout, “The Design and Implementation of a Log-Structured File System,” ACM Transactions on Computer Systems, 1992: an early, influential treatment of write-ahead logging applied to an entire filesystem’s structure.

See also

Section titled “See also”
  • ext2: the non-journaling format whose crash-recovery limitations motivate this article.
  • VFS: the layer that stays identical to callers regardless of whether the filesystem underneath journals or not.
  • Buffer Cache: the narrower gap journaling actually closes, versus what a dirty, unflushed block in this cache is still exposed to.