File System Journaling

When file systems first adopted journaling, designers faced a fundamental question: What should we journal? Journaling everything—both data and metadata—provides the strongest consistency guarantees but doubles all writes. Journaling nothing returns us to the crash vulnerability of the past.\n\nMetadata journaling emerged as the pragmatic middle ground. By journaling only the file system's structural information—inodes, directories, bitmaps, and block pointers—while writing data directly to its final location, file systems achieve rapid recovery and structural consistency with minimal performance overhead. This mode has become the default for most production file systems.

To understand metadata journaling, we must first precisely define what constitutes metadata versus data. The distinction is fundamental to understanding what protections are—and are not—provided.

Data is the actual contents of files—the bytes that applications write through write() system calls. Your document text, image pixels, database records, application binaries: these are all data.\n\nMetadata is everything the file system needs to organize, locate, and manage files and directories. Metadata answers questions like:\n- Where is this file's data stored on disk?\n- How large is this file?\n- Who owns it and what permissions apply?\n- What files exist in this directory?\n- Which blocks are free for allocation?

The Critical Insight:\n\nMetadata is what the file system uses to interpret the disk. Corrupt metadata means the file system cannot understand its own organization:\n\n- A corrupted inode might point to wrong blocks → reading garbage data\n- A corrupted directory means files cannot be found → data effectively lost\n- Corrupted bitmap might double-allocate blocks → catastrophic data intermixing\n\nCorrupt data, while certainly bad, has a bounded impact—one file's contents are wrong. The file system itself remains navigable; other files remain accessible.\n\nThis asymmetry justifies metadata journaling: protecting metadata ensures the file system structure survives crashes. Individual files may have incomplete updates, but the file system itself remains consistent and recoverable.

Metadata journaling modifies the basic WAL protocol to handle data specially. The key insight is that data can be written directly to its final location—it doesn't need the journal's intermediate storage—but the timing of data writes relative to metadata writes must be carefully controlled.

The Protocol Steps:

The Critical Ordering:\n\nThe barrier in Step 3 is essential. It ensures:\n\n> Data reaches disk before metadata that references it.\n\nWithout this ordering, consider what could happen:\n1. Metadata commits (points to block 50001)\n2. Crash occurs before data write\n3. On recovery: file now points to block 50001, which contains old/garbage data from a previous file\n\nThis is not just inconsistent—it's potentially catastrophic. The file appears valid but contains completely wrong data, possibly sensitive data from another file. The data-before-metadata ordering prevents this.

Even with proper ordering, metadata journaling has a subtle security and consistency issue: the stale data exposure problem. Understanding this issue is crucial for applications that handle sensitive data.

The Scenario:\n\nConsider allocating a new block for a file:\n\n1. Block 50001 was previously used by another file (say, containing passwords)\n2. Previous file was deleted, block marked free\n3. Your new file allocates block 50001\n4. You write new data to block 50001\n5. Crash before data write completes\n\nWith metadata journaling (ordered mode), the data write completed before metadata commit. But what if the crash occurred after metadata commit but before you wrote meaningful data?\n\nActually, with ordered mode, data must be written before metadata commits. But the block might have been freshly allocated (metadata) without the application having written all intended data yet. If the application was writing a sparse file or hadn't gotten to that part:

Mitigation Mechanisms:\n\n1. Zero-on-allocate (Delayed Allocation)\n\nModern file systems often delay actual block allocation until data is written. This means:\n- Blocks aren't allocated until data is ready\n- New data overwrites old contents\n- No window for stale exposure\n\next4's delayed allocation provides this protection for most cases.\n\n2. Zero fill\n\nSome file systems zero newly allocated blocks before making them accessible:\n- Overhead of writing zeros\n- Guarantees no stale data exposure\n- May be configurable or automatic\n\n3. Application-level protection\n\nApplications handling sensitive data should:\n- Explicitly zero buffers before writing\n- Use fallocate with FALLOC_FL_ZERO_RANGE\n- Consider encrypted file systems (stale blocks are encrypted)

ext4 provides three journaling modes that illustrate the design space between consistency and performance. Understanding these modes deeply reveals the trade-offs inherent in journaling design.

Mode: journal (Full Data Journaling)\n\nBoth data and metadata are written to the journal before being written to final locations.\n\nAdvantages:\n- Both structure and content are atomic\n- After crash: files contain either old or new complete contents\n- Strongest guarantees\n\nDisadvantages:\n- Every byte written twice (to journal, then final location)\n- Journal must be large enough for data workload\n- Significant performance overhead\n\nUse cases:\n- Databases that need atomic file updates\n- Financial/audit logs requiring bullet-proof consistency\n- Systems where correctness far outweighs performance

Mode: ordered (Metadata Journaling with Ordering)\n\nOnly metadata is journaled. Data is written directly to final locations but must reach disk before the metadata transaction commits.\n\nAdvantages:\n- File system structure always consistent\n- Data writes not doubled\n- Good balance of safety and performance\n\nDisadvantages:\n- After crash: file may have partial new data (but valid old/new for each block)\n- Ordering requirement adds some overhead\n- Still vulnerable to application-level inconsistencies\n\nUse cases:\n- General-purpose workloads\n- Systems where file structural integrity is primary concern\n- Default for most production systems

Mode: writeback (Metadata Only, No Ordering)\n\nOnly metadata is journaled. Data can be written in any order relative to metadata—before, after, or interleaved.\n\nAdvantages:\n- Maximum flexibility for write scheduling\n- Best performance (no ordering barriers)\n- File system structure still protected\n\nDisadvantages:\n- After crash: file may contain stale data from previous file\n- Security risk: sensitive data exposure\n- Application data consistency not guaranteed\n\nUse cases:\n- Scratch/temp file systems\n- Cases where applications manage their own consistency\n- Performance-critical systems with data redundancy elsewhere

Modern file systems like ext4 use delayed allocation (also called allocate-on-flush), which interacts importantly with journaling. Understanding this interaction is crucial for predicting file system behavior.

Traditional Allocation:\n\nWith traditional allocation, blocks are assigned immediately when data is written:\n\n1. write(fd, data, 4096) called\n2. Immediately: allocate block 50001\n3. Immediately: update inode to point to block 50001\n4. Eventually: write data to block 50001\n\nThis approach has fragmentation issues—if you write a file in pieces, blocks are allocated in the order of writes, not optimally for sequential reading.\n\nDelayed Allocation:\n\nWith delayed allocation, block assignment is postponed:\n\n1. write(fd, data, 4096) called\n2. Data goes to page cache, marked dirty\n3. No blocks allocated yet\n4. Later (writeback time): examine total dirty data\n5. Allocate contiguous blocks for all pending writes\n6. Write data to allocated blocks\n7. Update metadata

The Data Loss Controversy:\n\nDelayed allocation interacted problematically with some application patterns, leading to a significant compatibility issue in ext4's early days.\n\nThe problematic pattern:\n\n1. Rewrite config file:\n fd = open("config", O_TRUNC | O_WRONLY) // Truncate existing\n write(fd, new_config) // Write new content\n close(fd) // No explicit fsync\n\n2. Crash occurs\n\n3. Expected: Either old config or new config\n Actual: Zero-length file (old truncated, new not allocated yet)\n\n\nWith delayed allocation, the write's data might still be in page cache with no blocks allocated. A crash loses everything. Traditional allocation at least had blocks allocated, so something would survive.\n\nThe Fix:\n\next4 now detects patterns like truncate+write and forces earlier allocation for such files. Additionally, applications that care about durability should always use fsync()—the pattern above was always subtly incorrect, just masked by traditional allocation.

While we've focused on ext4, metadata journaling is used across many file systems. Each implementation has unique characteristics that reflect design priorities and legacy constraints.

XFS Journaling:\n\nXFS uses an "intent-based" journaling approach:\n\n- Operations are logged as intents (e.g., "allocate extent from A to B")\n- Actual work happens after intent is logged\n- Recovery replays intents, not raw blocks\n\nAdvantages:\n- Log entries are smaller (intents vs. full blocks)\n- Operations are idempotent by design\n- Better parallel logging\n\nNTFS Journaling:\n\nNTFS ($LogFile) uses more sophisticated logging:\n\n- REDO + UNDO information\n- True transaction support with rollback capability\n- Transactional NTFS (TxF) for application use (deprecated)\n\nNTFS can undo incomplete operations, not just redo them. This provides additional recovery options but adds complexity.

Metadata journaling's performance impact varies significantly by workload. Understanding these patterns helps you choose the right mode and optimize system configuration.

Write Amplification Analysis:\n\nExtents of writing differs by journaling mode:

Fsync Performance:\n\nFsync behavior is where journaling mode matters most:

Key Performance Observations:\n\n1. HDD barrier dominance: On HDDs, the barrier cost (~8ms for disk rotation) dominates. Reducing barrier count matters more than reducing write count.\n\n2. SSD barrier efficiency: SSDs handle barriers much faster (~0.1ms), making journaling overhead proportionally smaller.\n\n3. Batching critical: Combining multiple operations into one transaction dramatically improves throughput by sharing barrier cost.\n\n4. Sequential log writes: Journal writes are sequential, which is efficient on both HDDs (no seeks) and SSDs (better wear leveling).\n\n5. Full journal paradox: For pure fsync latency, full journaling can be faster because data write doesn't need a separate barrier—everything goes to journal. But total write volume increases.

We've thoroughly explored metadata journaling, the dominant approach in production file systems. Let's consolidate our understanding:

What's Next:\n\nWe've seen metadata journaling; now we'll examine full data journaling mode where both data and metadata are journaled. This mode provides the strongest guarantees at significant performance cost, and is essential for certain specialized workloads.