Journaling

Crash mid-write = inconsistent FS. Solutions:

fsck (filesystem check, no journal):

• On boot after crash: scan whole FS, repair inconsistencies.
• Slow: hours for big FS.
• ext2 does this.

Journaling: write changes to a journal first; commit; THEN apply to FS proper.

1. Begin transaction T.
2. Write metadata changes to journal (e.g., new inode, dir entry).
3. fsync journal.
4. Apply changes to actual FS data structures.
5. Mark T complete in journal.

Crash between 3 and 5: replay journal on mount. Crash before 3: discard journal.

Journal modes:

• Writeback (ext3 default): metadata journaled; data written separately. Fast, but data may be inconsistent after crash.
• Ordered (ext4 default): data flushed before metadata commit. Data and metadata consistent.
• Journal (full): both data + metadata in journal. Safest, slowest.

ext4 journal:

• Reserved area on disk.
• Sequential writes (efficient).
• Circular log: oldest committed entries discarded.

Recovery:

1. Find oldest uncommitted transaction.
2. Replay from there.
3. Update FS state.
4. Mark journal clean.

Compared to xv6 simple log:

• Each transaction has list of (block_num, data) pairs.
• Commit: write blocks to journal + COMMIT marker.
• Apply: copy from journal to actual blocks.
• Truncate: clear journal.

Performance cost:

• Each metadata-changing operation is journaled.
• ~30% throughput hit for metadata-heavy workloads.
• Mitigated by batching transactions.

COW (Copy-on-Write) FS (btrfs, ZFS, APFS):

• Never overwrite live data. New writes go to fresh blocks.
• Atomicity via root pointer swap.
• No separate journal needed.
• Snapshots cheap (just keep old root).

Modern FS:

• ext4: journaling.
• xfs: journaling.
• btrfs/ZFS: COW.
• Both crash-safe; different design tradeoffs.