Analyses / Filesystem recovery

Ext4 journal replay: why old writes must sometimes be skipped

Published 14 October 2026 / Linux v6.12 source review and constructed model

Recovery is not simply copying every old journal entry back to disk. Reused blocks need protection from obsolete images, and recovery itself may be interrupted. Ext4 illustrates two different answers: revocation and replayable outcomes.

Commit and checkpoint are different boundaries

In the reviewed Linux v6.12 design, a committed journal transaction can recover changes whose final-location writes are incomplete. A missing commit record or failed checksum disqualifies a transaction from replay. The default ordered mode journals metadata, not every file-data update. [1]

A journal checkpoint writes committed buffers to their home locations, allowing the corresponding log space to be reclaimed. That is distinct from making the recovery information durable. [2] Neither event alone establishes an application's multi-file transaction boundary; compare atomic rename and directory durability.

A valid old image can be the wrong write

JBD2's revoke records prevent obsolete metadata images from overwriting newer data at a reused block. Recovery tracks the last revoking transaction for each block. Images at or before that transaction are skipped; a later image remains eligible. Revocation is not a permanent ban on using the block. [3]

Constructed example: block 42 already contains new user data. The validated, committed log holds an old metadata image at transaction 10 and a revocation at transaction 11. These are labels, not measured disk addresses.

Replay rule	Final block 42
Ignore revocation	old-metadata
Respect revocation	new-user-data
Then add an image at transaction 12	later-metadata

The last row is the essential control: a rule that skips every image of a revoked block would protect the reused data but wrongly suppress the later metadata. Our model tests both boundaries, including an image in the same transaction as a surviving revoke. Inputs represent the final accepted log, not operations before revoke cancellation.

Fast commit records recoverable metadata deltas

Ext4 fast commit records smaller metadata deltas for eligible ordered-mode updates. A full commit is still needed when the fast-commit space fills, an operation is ineligible or the commit timer fires; it invalidates preceding fast commits. This is a scoped Linux v6.12 design description, not a recommendation to enable it or a measured latency improvement. [1]

The implementation explains replay in terms of intended outcomes, including directory entries and inode state. Re-running a destructive procedure can remove its own previous result. Re-enforcing the recorded result can converge after another interruption. The source also lists replay-hardening work: its design explanation must not be read as a proof that every kernel failure path is correct. [4]

What happens if recovery crashes too?

Our namespace model starts with config pointing to inode 7 and temporary pointing to inode 9. The desired result is config=9, no temporary name, and one link to inode 9. It applies four outcomes: remove config; set config=9; remove temporary; set inode 9's link count to one. Names, inode IDs and the simplified state are illustrative.

Each row interrupts this model after a prefix, then restarts the complete outcome sequence. The link count column concerns inode 9 only. Intermediate state is not exposed as a valid recovered filesystem.

Outcomes before interruption	Names at interruption	Names after recovery	Final link count
0	config=7; temporary=9	config=9	1
1	temporary=9	config=9	1
2	temporary=9; config=9	config=9	1
3	config=9	config=9	1
4	config=9	config=9	1

The tests additionally enumerate all 25 ordered pairs of interruption prefixes before a final complete replay. Every case reaches that explicit target. A negative control instead deletes config and renames temporary: after one completion, repeating it deletes config and fails because the temporary source is gone. Merely retrying is not equivalent to idempotent recovery.

Download the generated results and code hash, dependency-free model and executable tests. Run the two adjacent JavaScript files with node --test journal-replay.test.mjs. These finite counts need no sampling interval; their relevance to real failure behavior is limited by the abstraction.

A model is not a filesystem certification

Pillai and colleagues' OSDI 2014 study separates application persistence properties from filesystem metadata consistency. BOB explored reordered block traces across six filesystems and sixteen configurations, respecting barriers. Section 2.2 explicitly distinguishes finding a counterexample from proving a property always holds. These historical experiments are methodological context, not evidence about fast commit in Linux v6.12. [5]

No filesystem was mounted or crashed for this model. It excludes allocation, concurrent updates, inode reclamation, torn sectors, cache flushes, checksum validation, transaction-ID wrap and real journal parsing. Records are assumed already validated and committed. The namespace and block examples are separate models, not a combined ext4 recovery engine.

Our engineering conclusion: identify the accepted transaction range, reused-block rules and post-recovery application invariants separately. Test interruptions during recovery as well as during normal writes, using a disposable environment. A completed mount or a valid checksum is not by itself the application's correctness oracle.

Related: crash-test oracles,checksum identity limits and database WAL checkpoints. For a different approach to safe metadata updates, see soft updates and dependency ordering.

Primary sources

Reviewed 14 October 2026. Kernel references are version-pinned; no unverified DOI, hardware measurement or independent reproduction is claimed.