A single "save" is really many small disk writes , and a crash between them leaves the filesystem half-broken. Journaling fixes this by first writing a complete to-do list to a scratchpad, stamping it "DONE" at the very end, so recovery only ever finds a plan that is entirely there or entirely absent — never half-applied.
This page assumes nothing . Before you read the main note , every word, symbol, and picture it leans on is built here from the ground up. Read top to bottom; each block earns the next.
Before we can talk about "writes" we need a picture of the thing being written to.
Definition Disk, sector, blockA disk is a long shelf of numbered pigeonholes. The smallest pigeonhole the hardware can read or write in one go is a sector (historically 512 bytes). The filesystem groups sectors into a block (e.g. 4 KB) — the smallest unit it cares about.
Look at the figure: the shelf is a row of little boxes with addresses (block 9, block 12, block 50…). "Writing block 50" means walking to box 50 and replacing its whole contents. Why this matters: the topic keeps saying "the inode block", "the bitmap block", "the data block" — those are just named boxes on this one shelf .
Definition Atomic (single-sector) writeAn operation is atomic if it either happens completely or not at all — there is no visible half-state. The disk promises this for exactly one sector : even if power dies mid-write, that sector ends up either fully old or fully new, never a smeared mix.
Intuition Why we obsess over "one sector"This single promise is the only solid ground the whole design stands on. The commit block trick in the main note works because it is one small write — the hardware's atomicity covers it. Everything journaling builds is a way to stretch this one-sector guarantee to cover a group of writes.
Contrast to keep straight:
Atomic (guaranteed) one sector — all-or-nothing, always.
Atomic (NOT guaranteed) two or more writes happening "together" — the disk gives no such promise.
A "create file" or "append" touches several named boxes. You must know each by sight.
Definition The four structures
Data block — a box holding the file's actual bytes ("hello world").Inode — a box of facts about a file : its size, and pointers (box numbers) to its data blocks. Think index card for one file.Bitmap — one bit per block: 1 = "this box is in use", 0 = "free". A used/free map of the whole shelf.Directory entry — a name-to-inode mapping: "notes.txt" → inode 9. The phone book .
In the figure, appending one block to notes.txt changes three of these at once: the data block (new bytes), the inode (bigger size + a pointer to the new block), and the bitmap (mark the new block used). Why the topic needs this: "one logical operation = many writes" is literally these three arrows firing separately. That is the crash-consistency problem in one picture. See File Systems for the fuller anatomy.
Definition Consistent vs inconsistentA filesystem is consistent when its structures agree with each other. It is inconsistent (corrupt) when they contradict.
Two contradictions the main note names — now picture them:
Lost block (left): the bitmap says block 12 is used , but no inode points to it. The space is leaked — reserved forever for nobody. Caused by writing the bitmap but crashing before the inode.Dangling pointer (right): a directory says "file → inode 9", but inode 9 was never written. Following it reads garbage — corruption. Caused by writing the directory before the inode.
Intuition Why order alone can't save youNo matter which order you pick, a crash can land in the gap between two writes and produce one of these contradictions. You cannot beat this by being clever about ordering the in-place writes — you need a separate place to stage the whole plan. That place is the journal.
The concept that a group of writes should be "all or nothing" has a name — Atomicity — and journaling is how a filesystem manufactures it.
The main note writes the core rule as A ≺ B
≺ < Why it feels right: it looks like less-than.
The fix: < ≺ events in time and, crucially, means "durably complete" — actually on the platter, not just sitting in memory. The whole Write-Ahead Logging discipline is this one arrow: journal write ≺ in-place write.
The recovery rule uses ⟺
Why the topic needs it: it turns a scary "did the crash break things?" into a mechanical yes/no lookup — the presence of one block.
An action is idempotent if applying it again changes nothing beyond applying it once . Setting a light switch to ON is idempotent; flipping it is not.
requires this
Recovery might crash again halfway through replay, so the same journal blocks may get copied to their homes a second time. If copying inode = final value twice differs from once, recovery could corrupt what it's trying to fix. Because a write of a fixed value is idempotent (the box just holds that value either way), replaying is always safe to repeat. This is the quiet property that makes the whole scheme correct , not just fast .
Two promises people constantly confuse.
Definition Consistent vs durable
Consistent = the on-disk structures don't contradict each other (no corruption).Durable = a specific write you asked for is guaranteed on the platter and will survive a crash.
Intuition Journaling gives the first, not the secondYour latest keystrokes may still be sitting in a RAM buffer when the power dies — journaling won't magically save them; it only promises the filesystem itself isn't broken . To force a specific write onto the platter you call fsync — see fsync and Durability . Keep these separate and the "journaling never loses data" myth dissolves.
Definition Circular bufferA fixed-size ring of slots you fill in order; when you reach the end you wrap back to the start and reuse the oldest, already-finished slots. A racetrack where writers chase, and a "cleaner" behind them frees laps that are done.
Intuition Why circular, not endlessThe journal is a temporary intent list, not a backup. Once a transaction is copied to its real home (checkpointed ), its journal slot is dead weight and gets reused. This is why the log stays small — and why recovery is fast: you only scan a small ring, not the whole disk (unlike fsck ). A related but different trick, Copy-on-Write Filesystems , avoids in-place overwrite entirely; and Databases use this exact WAL idea for their transactions.
Atomic single-sector write
FS structures: inode bitmap data dir
Inconsistency: lost block, dangling pointer
Commit block and iff recovery rule
Read it as: the disk and its atomicity guarantee sit at the root; the structures create the problem (inconsistency); the happens-before symbol powers the rule (WAL); the commit block and idempotency make recovery correct — and all of it feeds the main journaling topic.
Test yourself — you're ready for the main note when each reveal matches your own words.
What single write does the disk guarantee is all-or-nothing? A single-sector write — it ends up fully old or fully new, never smeared.
What is an inode, in one line? An index card holding a file's facts (size) and pointers to its data blocks.
What does the bitmap store? One bit per block: 1 = in use, 0 = free — a used/free map of the whole disk.
Give one concrete example of an inconsistent filesystem. Lost block (bitmap says used, no inode points to it) or dangling pointer (directory points to an unwritten inode).
Read the symbol A ≺ B "A happens-before B" — A must be durably on disk before B is allowed to start.
What does ⟺ ⇒ Both directions: present ⇒ replay AND absent ⇒ discard, so every case is decided.
Define idempotent and why replay needs it. Doing it twice = doing it once; recovery may re-copy blocks after a second crash, so repeats must be harmless.
Consistent vs durable — the difference in one line each? Consistent = structures don't contradict; durable = a specific write is guaranteed on the platter.
Why is the journal a circular buffer and not endless? It's a temporary intent log; checkpointed slots are freed and reused, keeping it small and recovery fast.