In this lesson, you will learn how Copy-on-Write (CoW) filesystems fundamentally change the approach to data integrity compared to traditional journaling systems.
The Problem with In-Place Updates
Traditional filesystems (like ext4) often perform "in-place" updates. When you modify a file, the filesystem overwrites the existing data blocks on the disk. To prevent corruption during a power failure, these systems use a journaling mechanism. They record the intended changes in a dedicated log before applying them to the main storage. If the system crashes, the filesystem "replays" the journal to ensure consistency.
However, journaling only protects the filesystem metadata (the "map" of where files live). If a crash happens exactly while data is being written, you can still end up with "torn writes," where the file contains a mix of old and new data.
The CoW Philosophy
CoW filesystems (like Btrfs or ZFS) take a different approach: they never overwrite data in place. When you change a file, the filesystem writes the new data to an entirely new, unused block on the disk.
Think of it as a tree structure:
- The filesystem has a root node pointing to metadata.
- When a file changes, the system writes the new data to a fresh block.
- It then updates the parent metadata node to point to this new block.
- Because the parent node changed, its parent must also be updated.
- This process ripples up until the "root" is updated.
Why it Matters for Integrity
Because the system always writes to empty space first, the old data remains perfectly intact until the entire operation is committed. If a power failure occurs mid-write, the filesystem simply ignores the incomplete update. Upon reboot, the "root" still points to the old, valid state of the filesystem.
# Conceptual flow of a CoW update:
# 1. Old state: [Root] -> [Metadata A] -> [Data Block 1]
# 2. Update starts: Write new data to [Data Block 2]
# 3. Commit: Update [Metadata A] to point to [Data Block 2]
# 4. Result: [Root] -> [Metadata A] -> [Data Block 2]
This eliminates the "torn write" risk entirely, providing superior data integrity without needing a separate, high-overhead journal for user data.
Key Takeaway: While journaling attempts to fix in-place updates by logging them, Copy-on-Write ensures integrity by treating every update as a brand-new write, leaving the original data untouched until the transition is complete.