The Copy-on-Write (COW) principle is the philosophical and technical cornerstone of Btrfs. Unlike traditional file systems that modify data in place—risking corruption if a write is interrupted—Btrfs never overwrites existing data. Instead, every modification creates a new copy at a different location, and only after the write completes successfully does the file system atomically update its metadata to point to the new data.

This seemingly simple concept has profound implications. COW enables instant snapshots without duplicating data, guarantees that file system structures are always consistent even after crashes, and provides the foundation for features that would be impossible or impractical in traditional file systems.

To appreciate COW, we must first understand what traditional file systems do—and why it's problematic.

The Problem with In-Place Updates:

Consider a traditional file system like ext4 (without journaling for simplicity). When you modify an existing file:

1. The file system locates the disk blocks containing the data to modify
2. It reads those blocks into memory
3. It modifies the in-memory copy
4. It writes the modified data back to the same disk locations

This "update-in-place" approach creates a critical vulnerability: if the system crashes during step 4, the data on disk is in an inconsistent state—partially old, partially new, potentially corrupted.

Traditional file systems mitigate this with journaling: writing changes first to a dedicated log, then applying them to their final locations. If a crash occurs, the journal is replayed to restore consistency. But journaling has costs:

• Write amplification: Data is written twice (journal + final location)
• Complexity: Crash recovery requires journal replay
• Still imperfect: Data (not just metadata) journaling is expensive

The COW Alternative:

Btrfs takes a fundamentally different approach:

1. When modifying data, allocate new disk space
2. Write the modified data to the new location
3. Update metadata pointers to reference the new location
4. Mark the old location as free (after confirming no other references)

The key insight: the old data remains intact until the new data is fully written and referenced. There's never a moment when the on-disk structure is inconsistent—either the old version is complete and valid, or the new version is complete and valid.

Btrfs applies COW not just to file data but to all metadata—every tree node, every inode item, every extent reference. This is what makes Btrfs trees truly "copy-on-write trees."

The Cascade Effect:

When you modify a leaf node in a Btrfs tree:

1. A new leaf node is written with the modification
2. The parent node's pointer to the old leaf must be updated
3. But updating the parent means COW'ing the parent node too
4. This cascades up to the root of the tree
5. Finally, the tree root pointer (in the superblock) is atomically updated

This is called "path copying"—every modification creates new copies along the entire path from leaf to root.

The Cost of Path Copying:

Path copying means modifying a single item requires writing O(log n) tree nodes—the height of the tree. For a tree with height 4, that's 4 node writes instead of 1.

However, Btrfs mitigates this cost through delayed allocation and batching:

• Multiple modifications to the same tree share the new path
• Changes accumulate in memory before being flushed
• A single commit can include thousands of modifications with minimal overhead

The Benefits of Metadata COW:

By default, Btrfs applies COW to file data as well as metadata. When you overwrite existing file contents:

1. New disk space is allocated for the modified data
2. The new data is written to the new location
3. The file's EXTENT_DATA items are updated to point to the new extent
4. The old extent's reference count is decremented
5. If the old extent has no remaining references, its space is freed

Data COW Implications:

Disabling Data COW:

For certain workloads, data COW can be problematic. Database files and virtual machine images are frequently overwritten in small chunks, causing severe fragmentation and space amplification.

Btrfs allows disabling data COW per-file using the nodatacow attribute:

# Set nodatacow on a file/directory (new files inherit)
chattr +C /path/to/vm-images/

# Check COW status
lsattr /path/to/file

Important: When nodatacow is set:

• Data is overwritten in place (like ext4)
• Data checksumming is also disabled (they're linked)
• Snapshots create independent copies (not shared)
• Write-hole risk returns for RAID5/6

The NOCOW tradeoff:

Btrfs organizes changes into transactions—groups of modifications that are committed atomically to disk. This transaction model is the mechanism by which COW's theoretical benefits become practical reality.

Transaction Lifecycle:

How Commits Work:

1. Running Phase: A transaction is open, accepting file operations. Modifications are accumulated in memory within COW'd tree nodes.

2. Commit Trigger: Commits are triggered by:

   • Periodic timer (default: every 30 seconds)
   • Explicit sync() or fsync() calls
   • Memory pressure from too many uncommitted changes
   • Unmount operations

3. Commit Sequence:

   • Stop accepting new operations for this transaction
   • Start a new transaction for incoming operations
   • Write all dirty data extents to disk
   • Write all dirty metadata nodes (COW'd path)
   • Write super block with new tree roots
   • Mark old tree nodes as freeable

Generation Numbers:

Each transaction has a generation number—a monotonically increasing counter. Every tree node, extent, and metadata item records which generation created or modified it.

Generation numbers enable:

• Crash recovery: Identify which state to recover to
• Snapshot distinction: Tell which items are shared vs. diverged
• Garbage collection: Determine when old data can be freed

COW creates a fundamental challenge: when multiple snapshots or files reference the same extent, how do we know when the extent can be freed? Btrfs solves this with reference counting and back-references.

The Reference Counting Challenge:

Consider a file with 100 extents that has 10 snapshots. Each snapshot might share some extents and have diverged on others. We need to track:

• How many references exist to each extent
• When the count reaches zero (extent can be freed)
• Who the referees are (for relocation and integrity checks)

Back-References:

Btrfs stores back-references alongside extent items in the extent tree. A back-reference indicates "who is pointing to this extent":

Extent Item: [disk_bytenr, num_bytes]
  ├── RefCount: 3
  ├── BackRef: { tree_id: 257, objectid: 123, offset: 0 }
  ├── BackRef: { tree_id: 258, objectid: 456, offset: 0 }
  └── BackRef: { tree_id: 259, objectid: 789, offset: 4096 }

Types of Back-References:

Btrfs uses different back-reference types depending on shared status:

Extent Sharing Mechanics:

When you create a snapshot:

1. A new tree is created with its root pointing to the source tree's root
2. The source tree's root node's reference count is incremented
3. All child pointers now point to shared subtrees
4. No extent data is copied—only the root reference is new

When you modify a file in the snapshot:

1. COW creates a new extent for the modified data
2. The new EXTENT_DATA points to the new extent
3. The old extent's reference count is decremented
4. If count > 0, the extent is kept (still referenced by original)
5. If count = 0, the extent is freed

One of COW's most valuable properties is crash consistency—the guarantee that after any crash, the file system will be in a valid, consistent state without requiring expensive fsck operations.

The Consistency Guarantee:

At any point in time, the file system has exactly one committed state—the most recently completed transaction. If a crash occurs:

• All changes from incomplete transactions are lost (as expected)
• All changes from complete transactions are preserved
• The on-disk structure is always internally consistent

Why This Works:

Recovery Process:

When Btrfs mounts after a crash:

1. Read superblock mirrors, select the one with highest generation and valid checksum
2. The selected superblock points to the last committed tree roots
3. All tree operations proceed from these known-good roots
4. Any "orphaned" data (written but not committed) is gradually reclaimed

There's no journal to replay, no structure to check—the file system is immediately consistent.

Log Tree for fsync():

While transactions enable consistency, the default 30-second commit interval could lose significant data on crash. For applications that call fsync() to ensure durability, Btrfs uses a log tree:

• fsync() writes file data to a temporary log tree
• On commit, log tree contents are merged into the main trees
• On crash, log tree replay restores fsync'd data

This provides the durability guarantee of fsync without forcing a full commit.

Copy-on-Write is not without costs. Understanding the performance implications helps in proper workload selection and tuning.

The Fragmentation Problem:

In traditional file systems, overwriting file data keeps it contiguous. In a COW file system, each overwrite allocates new space wherever available, leading to fragmentation:

• A file written sequentially becomes scattered after in-place modifications
• Sequential reads become random reads, dramatically hurting HDD performance
• Even SSDs, while tolerant, suffer from increased write amplification

Write Amplification:

Btrfs COW creates write amplification from multiple sources:

1. Metadata COW: Each data write requires updating (COW'ing) tree nodes from leaf to root
2. Checksums: Every data block has a checksum entry written to the checksum tree
3. Extent bookkeeping: Back-references and extent items add overhead

For small, random writes, this amplification can be significant—a 4KB write might require 64KB+ of metadata writes.

Optimizing for COW:

Copy-on-Write is the foundation upon which all of Btrfs's advanced features are built. Let's consolidate the key concepts:

What's Next:

With COW understood, we'll explore one of its most powerful applications: Subvolumes. Subvolumes provide lightweight, flexible containers within a Btrfs file system—enabling independent mount points, quota control, and the foundation for snapshot management.