Power failures, system crashes, and kernel panics don't wait for file systems to finish their work. Without protection, these interruptions can leave storage in an inconsistent state—metadata pointing to non-existent data, allocation bitmaps disagreeing with actual usage, directory entries referencing corrupted inodes. The result? Filesystem corruption that requires lengthy recovery procedures and potentially permanent data loss.

Journaling solves this by recording intended changes before performing them. If a crash occurs, the journal provides a recovery path: either complete the interrupted operation or cleanly undo it. This transforms crash recovery from hours of fsck scanning to seconds of journal replay.

This page examines journaling implementations across major file systems, explaining how they work, what they protect, and what tradeoffs they embody.

Before understanding journaling, we must appreciate the problem it solves. File system operations that appear atomic to users often require multiple disk writes that can be interrupted mid-sequence.

Example: Creating a File

Creating a new file involves multiple interdependent disk writes:

1. Allocate inode — Mark an inode as in-use in the inode bitmap
2. Initialize inode — Write file attributes (size=0, permissions, timestamps)
3. Update directory — Add directory entry linking filename to inode number
4. Update directory inode — Increment link count, update modification time
5. Write data blocks (if file has content)
6. Update allocation bitmap — Mark data blocks as allocated
7. Update inode — Record data block locations, update file size

What happens if power fails after step 3 but before step 1?

The directory points to an inode that was never allocated. Subsequent operations might:

• Allocate that inode for a different file → Two files sharing an inode → Catastrophe
• Consider the filesystem corrupted and refuse to mount
• Require fsck to detect and remove the orphaned entry

Inconsistency Categories:

The fsck Solution (Pre-Journaling):

Before journaling, fsck (file system check) scanned entire file systems to detect and repair inconsistencies:

• Walk all directories, recording referenced inodes
• Walk all inodes, recording referenced blocks
• Compare against allocation bitmaps
• Repair discrepancies

For large file systems, this took hours. A 10TB array might require 4-8 hours of fsck after every crash. During this time, the system was unavailable. This was unacceptable for production servers.

Journaling (also called write-ahead logging) ensures consistency by recording operations before performing them. The principle is simple: log what you're about to do, then do it. If you crash, the log tells you what to finish or undo.

Why This Works:

Crash during journal write (before commit): The transaction is incomplete. On recovery, it's discarded as if it never started. The file system remains in its previous consistent state.

Crash during checkpoint (after commit): The transaction is complete in the journal. On recovery, replay the journal to complete the modifications. The file system reaches the intended consistent state.

Key Insight: Journaling transforms the problem from "ensure complex multi-step operation is atomic" to "ensure single journal commit is atomic." Modern storage hardware can guarantee single-sector write atomicity, making the commit reliable.

Journal Types:

Redo Logging (Physical Journaling): The journal contains the new values of modified blocks. On replay, those values are written to their target locations.

• Advantage: Replay is simple—just write the blocks
• Disadvantage: Journal entries are large (entire blocks, not just changes)

Undo Logging: The journal contains the old values of blocks that will be modified. On recovery, operations are undone to restore previous state.

• Advantage: Smaller journal entries for small changes
• Disadvantage: Requires undo during crash recovery; more complex

Redo/Undo Logging: Both old and new values are logged. Provides maximum flexibility at the cost of larger journal entries.

Logical Journaling: Rather than physical block contents, the journal contains logical descriptions of operations ("create inode 12345 with permissions 0644"). Smaller journal entries but more complex replay.

Most file systems use physical redo logging for simplicity and reliability.

Not all journaling is created equal. The critical distinction is what gets journaled: metadata only, or metadata plus data.

*Writeback mode journals metadata but allows data writes in any order relative to metadata

Understanding Ordered Mode (ext4 default):

Ordered journaling provides a critical safety property: data is written to disk before the metadata that references it.

Without this guarantee, a crash could leave:

1. Metadata claiming a file has new blocks
2. Those blocks containing old data from a previously deleted file
3. Potential security exposure of deleted data

Ordered mode prevents this by:

1. Writing file data blocks to their final locations
2. Then journaling and committing the metadata update

This ensures that metadata always points to valid data, never to garbage. Performance is good because only metadata goes through the journal.

When Data Journaling Matters:

Full data journaling (ext4 data=journal, NTFS for small files) is rarely needed but essential for:

• Database write-ahead logs that must survive crashes with precise guarantees
• Financial transaction systems requiring absolute write ordering
• Application-level consistency that depends on file content atomicity

The cost: every data write happens twice (once to journal, once to final location), roughly halving write bandwidth.

Each file system implements journaling (or its equivalent) differently, reflecting its design philosophy and target use cases.

NTFS Journaling Deep Dive:

NTFS uses $LogFile, a special system file containing a circular transaction log:

What's Logged:

• MFT record changes (creating/modifying files)
• Index updates (directory structure changes)
• Attribute modifications (file metadata)
• Small file content (files small enough to fit in MFT)

Log Structure:

• Restart area: Points to current log position
• Buffer page area: Contains redo and undo records
• Log sequence numbers (LSNs) track ordering

Recovery Process:

1. Read restart area to find log position
2. Analysis pass: Determine transaction status
3. Redo pass: Complete committed transactions
4. Undo pass: Rollback uncommitted transactions

Unique NTFS Feature: NTFS also logs changes to resident file data (data stored in MFT rather than separate clusters). This provides full consistency for small files without explicit data journaling mode.

ext4 Journaling Deep Dive:

ext4's journal is managed by the jbd2 (journaling block device) subsystem:

Journaling Modes:

# /etc/fstab options
data=writeback   # Fastest; metadata only; stale data risk
data=ordered     # Default; metadata journaled, data ordered
data=journal     # Slowest; full data+metadata journaling

Journal Commits:

• Commits occur every 5 seconds by default (commit=5)
• Or when journal fills to threshold
• Or on explicit sync/fsync

Barriers: ext4 uses write barriers to ensure journal commits are truly durable before proceeding. Disabling barriers (barrier=0) improves performance but risks data loss if cache isn't battery-backed.

XFS Journaling Deep Dive:

XFS uses a metadata-only journal with several optimizations:

Log Location:

• Internal log: Allocated within the file system (default)
• External log: On a dedicated device for performance

Delayed Logging: XFS aggregates metadata changes in memory, committing batches to the log. This reduces log I/O and improves performance for metadata-intensive workloads.

LSN Tracking: Log Sequence Numbers ensure ordering without synchronous writes. Metadata carries its last-written LSN; recovery replays only log entries with higher LSNs.

Recovery: XFS log recovery is extremely fast—typically under 5 seconds regardless of filesystem size, since it only replays the log, not scan the entire filesystem.

ZFS Intent Log (ZIL) Deep Dive:

ZFS takes a fundamentally different approach: Copy-on-Write semantics mean data is never overwritten, so traditional journaling isn't needed for consistency. The ZIL serves a different purpose:

What ZIL Does:

• Journals synchronous writes (fsync, O_SYNC, O_DSYNC)
• Ensures sync semantics are honored despite ZFS's batched writes
• Does NOT journal asynchronous writes (COW handles those)

SLOG (Separate LOG):

• Optional dedicated device for ZIL
• Enterprise SSDs or NVMe for performance
• Without SLOG, ZIL uses main pool (slower for sync writes)

Recovery:

• On pool import, ZIL is replayed
• Committed TXGs need no replay (already consistent via COW)
• Only uncommitted but sync-promised writes need replay from ZIL

Why ZFS Rarely Loses Data: Between COW atomicity and ZIL for sync writes, ZFS's consistency model is arguably the most robust of any common file system.

ZFS and Btrfs achieve consistency through Copy-on-Write (COW) rather than traditional journaling. Understanding this alternative approach illuminates fundamental differences in modern file system design.

How COW Guarantees Consistency:

Consider modifying a file in a COW file system:

1. Read the file's current blocks
2. Create new blocks with modified data
3. Update inode to point to new blocks (but don't overwrite old inode)
4. Create new inode with updated block pointers
5. Update parent tree nodes, all the way to root (new copies)
6. Atomically update root pointer to new tree

Key insight: Until step 6, the old file system state is completely intact. The atomic pointer update is the "commit."

If crash occurs before step 6: The old root pointer remains valid; old consistent state preserved; new blocks are orphaned (reclaimed by garbage collection).

If crash occurs after step 6: New state is active; old blocks become garbage; consistency is guaranteed.

No journal needed because there's never partial state—either old or new, never mixed.

Btrfs Consistency Model:

Btrfs combines COW with a log tree for additional performance:

Log Tree:

• Handles fsync optimization (avoids full tree commit for every sync)
• Logs pending changes that haven't reached their final location
• Replayed on mount to complete pending operations

Tree Root Updates:

• Superblock contains pointer to tree roots
• Two superblock copies provide atomic update semantics
• Commit alternates between copies

Checksums:

• Every metadata and data block has CRC32C checksum
• Corruption detected on read, before propagation
• Self-healing possible with redundant configurations

Journaling provides essential consistency guarantees, but at a cost. Understanding these performance implications enables informed tradeoffs.

Optimizing Journal Performance:

Commit Interval: ext4's default 5-second commit interval balances durability and performance. Increasing it (e.g., commit=30) reduces write frequency at cost of more data at risk during crashes.

External Journal Devices:

Placing journals on fast NVMe devices while data lives on spinning disks provides:

• Fast synchronous write acknowledgment
• Reduced interference with data I/O
• Potentially 10x improvement in sync-heavy workloads

The SSD Journal Advantage:

On SSDs, journaling overhead is dramatically reduced:

• No seek time for journal writes
• Journal commit latency: ~100µs (SSD) vs ~10ms (HDD)
• Write amplification less impactful due to abundant IOPS

This is why journaling performance concerns are primarily HDD-era issues. Modern SSD-based systems rarely need to compromise on journaling mode.

One of journaling's primary benefits is fast recovery. Let's compare recovery procedures and expectations across file systems.

Understanding Recovery Processes:

Journal Replay (ext4, XFS, NTFS):

1. Mount process detects unclean shutdown (journal has uncommitted entries)
2. Read journal from restart point
3. Apply committed transactions that weren't checkpointed
4. Discard uncommitted transactions
5. Clear journal; complete mount

Recovery time is proportional to journal size, not file system size. Even petabyte file systems recover in seconds.

COW Recovery (ZFS, Btrfs):

1. Import/mount reads uberblock/superblock
2. Find latest consistent root pointer (atomic; cannot be partial)
3. Replay ZIL (ZFS) or log tree (Btrfs) for sync writes
4. File system is consistent; mount completes

Recovery is almost instantaneous because there's nothing to "repair"—the file system was never inconsistent.

When Full fsck Is Still Needed:

Journaling doesn't protect against everything:

• Media corruption: Bad sectors can corrupt journal or metadata beyond journal protection
• Software bugs: File system bugs might write inconsistent data
• Hardware failures: Failing drives might provide corrupted data
• Journal corruption: If journal itself is corrupted, replay fails

In these cases, full fsck (or equivalent) is required:

• e2fsck for ext4
• xfs_repair for XFS
• zpool scrub + resilver for ZFS (if redundant)
• btrfs check for Btrfs

We've explored the mechanisms that protect file system consistency across crashes. Let's consolidate the essential insights:

What's Next:

We've covered features, performance, limits, and journaling. The final page synthesizes this knowledge into Use Case Recommendations—concrete guidance on which file system to choose for specific scenarios, from embedded devices to enterprise data centers.