Journaling — why, how it works: Question bank

Parent: the main Journaling note.

Before you start, keep three earned words in front of you:

Journal — a small circular scratchpad region on disk where intent is written first.
Commit block — the single small write, written last, that says "the whole transaction is safely logged."
Checkpoint — copying committed journal blocks to their real in-place homes.

If any of those feel shaky, revisit the parent note, Write-Ahead Logging, and Atomicity before continuing.

True or false — justify

Journaling guarantees you never lose recent writes.

False — it guarantees consistency (no half-broken filesystem), not durability; buffered writes in RAM can still vanish on a crash. See fsync and Durability.

The journal keeps a permanent history of every file you've ever saved.

False — it is a small circular buffer; once a transaction is checkpointed in place its journal space is reused, so it holds only in-flight intent, not history.

If the new data was fully written into the journal, it is safe to apply even without a commit block.

False — a missing commit means we cannot trust that all blocks arrived, so applying a partial transaction risks corruption; the commit is the all-or-nothing boundary.

Default ext3/ext4 mode journals your file data.

False — the default is ordered mode, which journals only metadata and merely orders data writes before the commit.

Replaying a committed transaction twice can corrupt the filesystem.

False — replay writes the same final values, and writing the same value twice equals writing it once; this idempotency is exactly what makes recovery safe.

In ordered mode, metadata is written to its real location before the data blocks it points to.

False — the whole point of ordered mode is the reverse: force data blocks to disk first, then commit the metadata, so metadata never points at garbage.

Journaling replaces the need for fsck entirely.

Mostly true for crash recovery, but false in general — a journaled FS can still develop corruption from disk faults or bugs, and fsck remains the tool of last resort for those.

Because the journal is on the same disk, a single sector failure there defeats the whole scheme.

Partly true as a risk, but the design tolerates it: an unreadable/incomplete journal record simply lacks a valid commit, so recovery discards it and the in-place FS is untouched.

Writing to the journal makes every operation slower because everything is written twice.

True only in full data (journal) mode; in ordered/writeback modes only metadata is double-written, so file data is written once.

The commit block contains the actual new file data.

False — the commit block is a tiny marker written last; the new block contents were written in the earlier journal-data step.

Spot the error

"Recovery scans the whole disk for contradictions, just faster than fsck." — what's wrong?

Recovery does not scan the whole disk; it scans only the journal (in-flight work), which is why its cost scales with work done, not disk size.

"We write the commit block first so recovery knows a transaction started." — what's wrong?

The commit is written last, not first; the descriptor (the scope-naming header) marks the start, and the commit's whole value is that its presence proves completeness.

"Journaling is safe because each of the many writes for one operation is individually atomic." — what's wrong?

Per-sector atomicity is exactly the problem, not the solution — the disk atomically writes one sector but gives no guarantee across multiple writes, which is why WAL is needed.

"In writeback mode, ordering data before metadata protects against garbage." — what's wrong?

Writeback does no ordering; that lack of ordering is precisely why a crash can expose stale/garbage data in a newly extended file.

"After checkpointing, we keep the journal entry so we can replay it again if needed." — what's wrong?

Once checkpointed, the entry is freed and the circular log advances; keeping it forever would fill the small journal and there's no reason to replay an already-applied change.

"The WAL invariant says: modify in-place data, then log the intent." — what's wrong?

The order is reversed — WAL demands log the intent first, and you may never touch in-place structures until that journal record is durably on disk.

Why questions

Why is discarding a non-committed transaction always safe?

Because checkpointing hadn't run, so the in-place structures were never touched; the on-disk filesystem is still in its valid pre-transaction state.

Why must the commit block be a single small write rather than spread across many?

So that its arrival is atomic — a single-sector write either fully lands or doesn't, giving a clean present/absent signal with no "half-committed" middle state.

Why does journaling recover faster than fsck even though both run after a crash?

fsck cost grows with disk size (scan everything for contradictions), while journal recovery cost grows only with the tiny in-flight journal.

Why does ordered mode exist instead of just always using full data journaling?

Full data mode writes everything twice (slow); ordered mode gets safety from metadata journaling plus data-before-commit ordering at roughly half the write cost.

Why can a crash still lose your last few seconds of work under journaling?

Writes sit in RAM buffers until flushed; journaling protects filesystem structure, not un-flushed data, so use fsync when specific bytes must survive.

Why is idempotency the property that makes replay correct rather than just convenient?

Because a crash can strike during checkpointing, so a block may be re-copied; only if re-writing the same final value is harmless can recovery blindly replay without tracking partial progress.

Why is journaling conceptually the same trick that databases use?

Both use write-ahead logging to turn a multi-step change into an atomic one — the parallels to Databases and Write-Ahead Logging are exact, differing only in what the "records" describe.

Edge cases

A crash happens while writing the commit block itself — what does recovery do?

The commit is a single sector, so it's either fully present (⇒ replay) or absent/garbled (⇒ discard); either way the outcome is consistent.

The transaction's descriptor header is torn (half-written) but data blocks and a commit both exist — what happens?

The descriptor is checksummed/validated, so a torn or inconsistent header makes the transaction fail validation and be discarded; recovery never replays a transaction whose scope it cannot trust, so the in-place FS stays intact.

A crash happens after checkpoint finished but before the journal space was freed — what happens?

Recovery sees a committed transaction and replays it idempotently, re-writing values that already match, then frees the space; no harm done.

Two transactions are logged and only the first has a commit block — what survives?

Only the first is replayed; the second, lacking a commit, is discarded, and because the log is ordered you never apply a later transaction while skipping an earlier one.

You append to a file in writeback mode and crash right after the metadata commits — what might the file show?

The inode may report the new larger size but the data block was never flushed, so reading it returns stale/garbage leftover contents — the classic writeback hazard.

The journal fills completely because checkpointing lags behind new transactions — what must happen?

New transactions must stall/block until checkpointing frees circular space; the journal being small and circular means it can exert back-pressure, not grow unbounded.

A copy-on-write filesystem crashes mid-update — does it need a journal to stay consistent?

No — CoW writes new data to fresh blocks and atomically flips a single root pointer, achieving crash consistency by a different mechanism than a write-ahead journal.

The "data block" write in ordered mode never made it to disk, but the crash was before commit — is the file corrupt?

No — with no commit the metadata transaction is discarded, so the file simply reverts to its pre-append state with no dangling pointer.

Recall One-line self-test

Answer in your head in the form "X vs Y, because …", then reveal the line below and check that both your two words and your reason match. If either is missing, re-read the first mistake box in the parent note. If someone claims "journaling means my saved work is guaranteed safe," what two words separate their claim from reality? ::: Consistency vs durability — journaling promises the filesystem stays consistent (never half-broken); it does not promise durability of un-flushed writes, which is fsync's job.