Filesystem Journals and Crash Consistency

A filesystem journal helps complete or discard an interrupted metadata transaction after a crash — it is a consistency mechanism, not a general-purpose backup of everything the application had written.

What journaling actually solves

Filesystem metadata — directory entries, allocation bitmaps, inode or file-record fields — is usually updated through several related writes. If power loss or a crash interrupts that sequence partway through, the metadata can be left internally inconsistent: a block marked both allocated and free, a directory entry pointing at a record that no longer matches it. A journal exists to make that specific failure recoverable, by recording enough about a transaction to either complete it or discard it cleanly the next time the filesystem mounts.

NTFS $LogFile: consistency, not history

NTFS uses a transaction log, $LogFile, so that NTFS can complete or roll back filesystem metadata operations after a crash. It should not be described as a backup, a full historical record of file content, or an undelete database — a common but mistaken assumption, since people hear “journal” and imagine old file versions being replayed backward. A filesystem journal records enough transactional state to restore metadata consistency; it does not generally carry enough information to restore previous user data.

NTFS also has a separate, different journal: $UsnJrnl

NTFS additionally keeps a USN Change Journal, which Microsoft documents as a persistent log of changes to filesystem objects — it can record that a file was created, deleted, renamed, overwritten, truncated or modified. Microsoft is explicit that the USN journal does not contain enough information to reverse those changes. So $LogFile and $UsnJrnl answer different questions entirely: $LogFile is about filesystem transactional consistency, while $UsnJrnl is a record that objects changed and roughly why. The recovery value of USN data is timeline and context — historical names, evidence that an object existed, correlating deletion or rename events — not restoring file content.

ext4 JBD2: the same principle, a different filesystem

Linux kernel documentation describes ext4's JBD2 journal as existing to avoid leaving filesystem metadata halfway through a transaction after a crash. A journal transaction is built from a descriptor, the data or metadata blocks being protected, and a commit record; without a valid commit record, the transaction is discarded entirely during replay. By default ext4 journals metadata rather than all user data, though data=journal mode can journal both, data=ordered is the common default-style model where data ordering is coordinated without making data itself the primary journal content, and fast-commit modes can store minimal deltas. The underlying principle transfers directly from NTFS: journal replay can restore structural consistency without restoring every write the application expected to have landed before the crash.

Journal replay is not the same operation as repair

Journal replay applies already-committed transactional metadata to reach a consistent, recent state — it is a narrow, defined operation. Filesystem repair is much broader: it can rewrite trees, discard orphaned records, rebuild allocation metadata, relink files, free blocks, and alter directory structures outright. A filesystem that becomes mountable after repair may no longer contain every structure that existed before the repair ran. For recovery, this is the reason to image the source first, rather than treat repair as a diagnostic step.

Why a journal can quietly overwrite recovery evidence

Journals are finite, managed regions reused as new transactions occur — older log records get overwritten by newer ones, mounting can trigger a replay of pending journal state, and ordinary filesystem activity keeps updating metadata. In a recovery case this means mounting a damaged volume read-write “just to see if it works” can modify precisely the metadata history that might otherwise have been useful for reconstruction — the same caution behind Why Mounting a Damaged File System Can Be Risky.

Crash consistency is not application consistency

A journal restores the filesystem's own internal consistency after a crash. It does not, on its own, guarantee that a database, virtual machine disk or other application sitting on top of that filesystem was in a logically coherent state at the moment of failure — that is a separate question the application's own logs or recovery mechanisms have to answer, not something the filesystem journal was ever designed to address.

Related: NTFS MFT, Allocation and File Reconstruction · ext4 Superblocks, Inodes, Extents and Journal · Why Mounting a Damaged File System Can Be Risky · Repair vs. Recovery · File System Corruption