Exercises — Journaling — why, how it works

Consistency ::: the filesystem's structures never contradict each other (no block claimed by two files, no directory pointing at nothing). Durability ::: a write you were told "succeeded" survives a power cut. Different from consistency! See fsync and Durability. Idempotent ::: doing it twice gives the same result as doing it once — writing the value $8$ into a box, then writing $8$ again, leaves $8$.

The COMMIT block. It is written last and is a single small sector write (disks guarantee one sector is atomic). Recovery rule: commit present ⇒ replay; commit absent ⇒ discard. This is why the parent note calls it "the atomic go switch."

WAL invariant: ==the intent must be durably on the journal before any in-place (real) structure is touched== — written $\text{journal}\prec \text{in-place}$, where $\prec$ means "strictly completes before". (A) obeys it (journal first). (B) violates it — if a crash lands between the two steps in (B), the real inode is already broken and there is no journal record to fix it. See Write-Ahead Logging.

Ordered mode journals only metadata: the inode and the bitmap → 2 structures enter the journal. The data block does not enter the journal; instead it is forced to disk before the commit block for the metadata is written. This prevents the inode from pointing at garbage. See the modes table in the parent note.

Discard the transaction. Because the commit is missing, recovery cannot trust that all $N$ metadata blocks made it durably — it treats the whole thing as never-committed. Crucially, the checkpoint step (copying journal → in place) had not run, so the real inode/bitmap were never touched. The filesystem is byte-for-byte in its pre-transaction state → still consistent. The append simply "didn't happen." ✅

Convert to megabytes: $D=4\text{TB}=4\times 10^6\text{MB}$. (a) $t_{\text{fsck}}=\frac{D}{R}=\frac{4\times 10^6}{200}=20000\text{s}\approx 5.56\text{hours}$. (b) $t_{\text{journal}}=\frac{J}{R}=\frac{128}{200}=0.64\text{s}$. (c) Factor $=\frac{t_{\text{fsck}}}{t_{\text{journal}}}=\frac{20000}{0.64}=31250\times$ faster. The point: journal recovery scales with work in flight ($J$, fixed), while fsck scales with total disk size ($D$). Bigger disks make fsck worse but leave journaling untouched.

The reader sees the stale/garbage contents of blocks 40–41 — here, someone else's old password data. The committed metadata legitimately points at those blocks, but the intended new data never landed. This is a real security/integrity leak. Ordered mode's fix: it forces the data blocks to disk before committing the metadata (data $\prec$ metadata-commit). So if the metadata is durable, the data it points to is guaranteed already durable — no window for exposing stale blocks. This is why ordered mode is the default sweet spot.

Useful payload $=8\text{MB}+16\text{KB}=8.015625\text{MB}$ (since $16\text{KB}=0.015625\text{MB}$). In data mode every byte is written twice — once into the journal, once in place: $\text{total}=2\times 8.015625=16.03125\text{MB}.$ Write amplification $=\frac{16.03125}{8.015625}=2.0\times$. Synthesis point: this exact 2× cost is why full data mode is "safest, slowest," and why ordered mode was invented — it journals only the $16\text{KB}$ of metadata, so amplification for the data is $1\times$. This is the same tension studied in Databases with Write-Ahead Logging.

Before the second copy, disk inode.size $=8192$ (from the first checkpoint). The journal's copy of inode.size is also $8192$. Re-copying writes $8192$ over $8192$ → the value is unchanged. The bitmap, which was missed, now gets bit[50] $=1$ from the same replay. Final state: inode.size $=8192$, bitmap.bit[50] $=1$ — exactly the committed intent. General property: idempotency — replaying a committed transaction any number of times yields the same final state as replaying it once. This is what makes crash-during-recovery safe: recovery itself can crash and be re-run without limit. See Atomicity.

The OS issues: (1) journal metadata, (2) commit block, (3) checkpoint in place — correctly ordered. But if the disk reorders and pushes the commit block to platter before the journal metadata, then a crash can leave a committed transaction whose logged data is missing. Recovery sees the commit, trusts it, replays — and copies garbage/incomplete blocks in place. Corruption, despite perfect OS ordering. Root cause: the disk's own cache broke the durability boundary the OS assumed. The fix: a cache flush / write barrier — the OS must call fsync() (or issue a FLUSH/FUA barrier) after writing the journal data and again after the commit, forcing the disk to durably persist each group before the next begins. Without an honest flush primitive, WAL's $\prec$ ordering cannot be enforced on physical media. See fsync and Durability.

Journaling: update in place, but write intent to a side journal first; recovery replays or discards. In full data mode it writes data twice (journal + in place). Copy-on-write: never overwrite; write new data to fresh blocks, then atomically flip a single root pointer to the new tree — the old version stays valid until the flip. See Copy-on-Write Filesystems. CoW never writes user data twice — it writes each new block exactly once to a new location and just re-points to it. Journaling's data mode inherently double-writes; that's the fundamental trade the two designs make.

Journaling is not broken. Its promise is consistency (structures never contradict), not durability of un-synced buffered writes. A returned write() only means "copied into a kernel RAM buffer," not "on the platter." Since that data never reached a committed journal transaction, recovery correctly has nothing to replay — and the on-disk filesystem is perfectly consistent, just without the 500 KB. What the program should do: call fsync(fd) after write() to force the buffered data (and its journal transaction) durably to disk before treating it as saved. Consistency is the filesystem's job; durability of specific bytes is the application's, via fsync(). See fsync and Durability.

The write that decides replay-vs-discard is the COMMIT block. WAL orders journal write strictly before in-place modification. Recovery is safe to re-run because replay is idempotent. Ordered mode journals only metadata but forces data before the metadata commit. Journaling guarantees consistency, not durability; use fsync for the latter.