Before 2001, system administrators lived in fear of the unexpected reboot. When an ext2 system crashed—whether from power failure, kernel panic, or hardware fault—the recovery process was predictable and painful: run fsck, watch it scan every inode and block on the disk, and wait. For large filesystems, this could take hours. A 500 GB disk might require 30 minutes or more of scanning before the system could come back online.

The root problem was fundamental to ext2's design. Without a record of in-progress operations, the only way to verify filesystem consistency was to examine everything. Every inode's link count must match directory entries. Every allocated block must be reachable. Every bitmap must accurately reflect allocation state. With no shortcuts available, recovery time scaled linearly with filesystem size.

Journaling changed everything. By recording intended changes before making them permanent, ext3 could recover from crashes in seconds rather than hours. The technique—borrowed from database systems—transformed Linux filesystems from fragile to production-ready.

This page explores how ext3's journaling works, from the fundamental write-ahead logging concept through implementation details that made it both reliable and performant.

To understand journaling, we must first understand why file systems become inconsistent after crashes.

The Multi-Write Problem:

Consider creating a new file /home/user/document.txt. This seemingly simple operation requires modifying multiple disk structures:

1. Inode bitmap: Mark a new inode as allocated
2. Inode table: Initialize the new inode with metadata
3. Block bitmap: Mark data blocks as allocated (if file has content)
4. Data blocks: Write actual file content
5. Directory inode: Update modification time
6. Directory data block: Add new directory entry

These six updates cannot complete atomically. If power fails midway:

ext2's Approach: Full Scan (fsck)

Without journaling, ext2's recovery strategy was exhaustive verification:

Pass 1: Check inodes, blocks, and sizes
Pass 2: Check directory structure
Pass 3: Check directory connectivity
Pass 4: Check reference counts (link count)
Pass 5: Check group summary information (bitmaps)

Time complexity: O(n) where n = total inodes and blocks

For a server that must be available 24/7, hours of downtime after each unexpected reboot was unacceptable.

The Core Insight: Write-Ahead Logging

Database systems solved this problem decades ago with write-ahead logging (WAL):

1. Before modifying data, write the intended change to a log
2. After writing the log entry, modify the actual data
3. After successful modification, mark the log entry as complete
4. On crash: replay incomplete log entries

This reduces recovery from O(n) scanning to O(log size) replay—typically seconds regardless of filesystem size.

The ext3/ext4 journal is stored as a special file managed by the Journaling Block Device (JBD2) layer. By default, it uses inode number 8 and occupies a fixed region of disk space.

Journal Location:

# View journal inode and size
dumpe2fs /dev/sda1 | grep -i journal
# Output:
Journal inode:            8
Journal size:             128M
Journal blocks:           32768

Journal Layout:

Journal Block Types:

Circular Buffer:

The journal operates as a circular buffer:

Journal Space:
+--------+------+------+------+------+------+------+------+
| Super  | T1   | T1   | T2   | T2   | T2   | FREE | FREE |
| Block  | desc | data | desc | data | cmit |      |      |
+--------+------+------+------+------+------+------+------+
         ↑                           ↑             ↑
      s_start                     s_end         wrap point
   (oldest active)             (newest)      (reuses space)

When the journal fills, old completed transactions are overwritten. This is safe because:

1. Committed transactions have been written to their final locations
2. Only uncommitted or recently committed transactions need preservation
3. Checkpointing ensures committed data reaches permanent storage

ext3/ext4 offers three journaling modes, each trading off between safety and performance. Understanding these modes is crucial for optimizing different workloads.

Mode 1: Journal (data=journal)

The most conservative mode journals both metadata AND data blocks:

Write file data:
1. Write data blocks to journal
2. Write metadata blocks to journal  
3. Write commit record
4. Write data blocks to final location
5. Write metadata blocks to final location
6. Checkpoint: free journal space

Characteristics:

• ✅ Full crash protection for data and metadata
• ✅ Can recover file contents after crash
• ❌ Writes every block twice (journal + final)
• ❌ Write throughput cut roughly in half
• 📊 Use case: Critical data where no loss is acceptable

Mode 2: Ordered (data=ordered)

The default mode—journals metadata only, but ensures data is written before metadata:

Write file data:
1. Write data blocks to FINAL location
2. Wait for data write completion
3. Write metadata blocks to journal
4. Write commit record
5. Write metadata to final location

Characteristics:

• ✅ Data reaches disk before metadata commits
• ✅ No stale/garbage data visible after crash
• ✅ Much better performance than full journaling
• ⚠️ Data may be lost if crash before step 3
• 📊 Use case: General purpose (default for good reason)

Mode 3: Writeback (data=writeback)

Fastest mode—journals metadata only with no ordering guarantees:

Write file data:
1. Write data blocks to final location (async)
2. Write metadata blocks to journal
3. Write commit record
4. Write metadata to final location

Characteristics:

• ✅ Maximum write performance
• ✅ Metadata always consistent after crash
• ❌ Files may contain stale/garbage data after crash
• ❌ Security risk: old file content exposed
• 📊 Use case: Scratch/temp filesystems, benchmarks

Understanding the transaction lifecycle reveals how journaling achieves atomicity while maintaining performance.

Transaction States:

Detailed Transaction Flow:

1. T_RUNNING (Active Transaction)

// Filesystem operations join the current transaction
handle_t *handle = jbd2_journal_start(journal, nblocks);

// Modify metadata blocks within the transaction
jbd2_journal_get_write_access(handle, bh);
modify_block(bh);
jbd2_journal_dirty_metadata(handle, bh);

// Complete this operation
jbd2_journal_stop(handle);

2. Commit Trigger A transaction commits when:

• Commit timer expires (default: 5 seconds)
• Transaction exceeds size limit
• Explicit sync request (fsync, sync)
• Journal space runs low

3. T_LOCKED → T_FLUSH

// Lock transaction: no new handles can join
transaction->t_state = T_LOCKED;

// Wait for all existing handles to complete
wait_for_handles_to_complete();

// Begin flushing to journal
transaction->t_state = T_FLUSH;

4. Journal Write Sequence

1. Write descriptor block (lists all blocks in transaction)
2. Write data/metadata blocks to journal space
3. Issue flush command (barrier) to disk
4. Write commit block with transaction checksum
5. Issue another flush command

The two flush commands ensure proper ordering: blocks must reach disk before commit, commit must reach disk before checkpoint.

When a system crashes with uncommitted transactions, ext3/ext4's recovery process replays the journal to restore consistency.

Recovery Detection:

During mount, the kernel checks if recovery is needed:

if (!(sb->s_state & EXT4_VALID_FS) ||
    (sb->s_feature_incompat & EXT4_FEATURE_INCOMPAT_RECOVER)) {
    // Filesystem was not cleanly unmounted
    // Journal recovery required
    jbd2_journal_recover(journal);
}

Recovery Phases:

Phase 1: PASS_SCAN

Scan the journal to identify valid transactions:

void recovery_pass_scan(journal_t *journal) {
    block_t block = journal->j_sb->s_start;
    tid_t expected_seq = journal->j_sb->s_sequence;
    
    while (block_is_valid(block)) {
        header = read_journal_block(block);
        
        if (header->h_magic != JBD2_MAGIC_NUMBER)
            break;  // End of journal or corruption
            
        if (header->h_sequence != expected_seq)
            break;  // Sequence inconsistency
        
        switch (header->h_blocktype) {
            case JBD2_DESCRIPTOR_BLOCK:
                record_descriptor(block);
                block += count_data_blocks(header);
                break;
            case JBD2_COMMIT_BLOCK:
                if (verify_checksum(header)) {
                    mark_transaction_valid(expected_seq);
                    expected_seq++;
                }
                break;
            case JBD2_REVOKE_BLOCK:
                record_revokes(block);
                break;
        }
        block++;
    }
}

Phase 2: PASS_REVOKE

Process revoke records to avoid replaying deleted blocks:

// Revoke blocks mark filesystem locations that should NOT
// be updated during replay (typically from deleted files)

for_each_revoke_record(record) {
    tid_t revoke_tid = record->r_transaction;
    block_t block = record->r_block;
    
    // If a later transaction revoked this block,
    // don't replay older data to it
    add_to_revoke_table(block, revoke_tid);
}

Phase 3: PASS_REPLAY

Replay committed transactions to restore consistency:

for_each_committed_transaction(tx) {
    for_each_block_in_transaction(tx, block) {
        // Check revoke table
        if (is_revoked(block->destination, tx->tid))
            continue;  // Skip revoked block
        
        // Replay: copy from journal to final location
        write_block(block->destination, block->data);
    }
}

The journal has finite space. Checkpointing is the process of writing committed transactions to their final locations, freeing journal space for reuse.

Why Checkpointing Matters:

Journal at 80% capacity:
+--------+------+------+------+------+------+------+------+
| Super  | T1✓  | T2✓  | T3✓  | T4✓  | T5•  | FREE | FREE |
+--------+------+------+------+------+------+------+------+
                                       ↑
                              Current transaction

T1-T4 are committed but not yet checkpointed.
Journal can only use remaining 20% until T1-T4 checkpoint.

Checkpoint Trigger Conditions:

1. Journal space falls below threshold (typically 25%)
2. Background checkpoint timer expires
3. Sync or fsync forces checkpoint
4. Unmount flushes all transactions

Checkpoint vs. Commit:

Checkpoint Ordering Constraints:

Transactions must checkpoint in order:

T1 commits → T2 commits → T3 commits
      ↓           ↓           ↓
T1 checkpoints → T2 checkpoints → T3 checkpoints

This ordering ensures that if a crash occurs during checkpointing, recovery replays transactions in the correct sequence.

Monitoring Checkpoint Activity:

# View journal status
cat /proc/fs/jbd2/sda1-8/info
# Output:
# 1 transaction, 1 locked, 0 flushing, 0 logging
# Average revision: 1 blocks used, 128 target

# Detailed stats
cat /sys/fs/ext4/sda1/journal_info

Optimizing journal performance requires understanding the trade-offs between safety, latency, and throughput.

Key Tuning Parameters:

Performance Recommendations by Workload:

External Journal Optimization:

For high-performance systems, placing the journal on a separate device eliminates seek contention:

# Create journal device (small SSD or NVMe)
mkfs.ext4 -O journal_dev /dev/nvme0n1p1

# Create main filesystem with external journal
mkfs.ext4 -J device=/dev/nvme0n1p1 /dev/sda1

# Journal operations go to fast NVMe
# Bulk data goes to high-capacity HDD

Journaling transformed Linux filesystems from fragile to production-ready, enabling reliable crash recovery in seconds rather than hours.

Next Up: Ext4 Extents

With journaling ensuring reliability, ext4's next major innovation tackled efficiency: extents. Rather than tracking files as lists of individual blocks, extents describe contiguous ranges, dramatically reducing metadata overhead for large files and improving both performance and scalability.