Btrfs — Copy-on-Write & Snapshots
Linux Filesystems
Chapter 3 · Btrfs — Copy-on-Write & Snapshots
fs1-2 closed with a promise: Btrfs isn't a free upgrade over ext4, it's a genuinely different philosophy. This chapter is that difference, in full — starting with the one structural change that makes everything else in this chapter possible.
Copy-on-Write — The Real Structural Difference
ext4's own model: modifying a file generally updates data in place, overwriting existing blocks, with journaling protecting against a crash mid-write. Btrfs takes a genuinely different approach — Copy-on-Write (COW). Modifying a file never overwrites existing blocks in place; Btrfs writes the new version to a fresh location, then atomically updates the metadata pointer to reference the new blocks instead of the old ones. The old blocks remain completely untouched until nothing references them anymore.
This single mechanism is what makes snapshots, below, essentially free and instant — a snapshot is just "a pointer to the metadata exactly as it existed at this moment," which COW naturally preserves, since old blocks are never overwritten while still referenced by anything.
Subvolumes — Btrfs's Own Internal Partitioning
A genuinely new concept with no ext4 equivalent: a subvolume is an independently mountable, independently snapshottable "filesystem within a filesystem," all sharing the same underlying storage pool.
A real use: separate subvolumes for /, /home, and /var/log, each independently snapshottable, without needing separate partitions the way ext4 would require for the same isolation.
Snapshots — The Real Payoff of COW
This completes almost instantly and initially consumes almost no extra space — the snapshot and the original share every single block, per COW. Only as the original (or the snapshot) is subsequently modified do the two start to diverge, with new blocks written only for whichever side changed, while unmodified blocks stay shared. A snapshot of a 500GB subvolume with no changes yet takes essentially zero additional disk space — not another 500GB. A real, practical use: taking a snapshot immediately before a risky system update, so a bad update can be rolled back simply by switching back to the pre-update snapshot — this is genuinely how tools like openSUSE's own Snapper rollback system work underneath.
Checksumming and Self-Healing
A genuinely new capability ext4 doesn't have at all: Btrfs checksums both data and metadata by default. On every read, the checksum is verified — if a block has silently corrupted (bit rot, often from a failing disk), Btrfs can detect this, something ext4 simply cannot do on its own; ext4 would just return the corrupted data, unaware anything was wrong. Running with redundancy (RAID1, previewed here, fuller coverage in fs1-7/fs1-8), Btrfs can automatically self-heal — reading the good copy from the mirror and repairing the corrupted one, transparently.
Proactively reads and verifies every checksum on the filesystem, catching (and, where redundancy exists, repairing) corruption before it's ever encountered by a real read — a genuinely valuable maintenance operation with no ext4 equivalent.
A Concrete Worked Example — Snapshot Before a Risky Change
Take the snapshot, run the upgrade, and if it breaks something, the pre-update state is right there, ready to boot into instead — no restore process, no waiting.
| Write model | Snapshot cost | Corruption detection | |
|---|---|---|---|
| ext4 | In-place, journaled | No native snapshots | None — silently returns corrupted data |
| Btrfs | Copy-on-write | Near-instant, near-free | Checksummed on every read, self-healing with redundancy |
btrfs filesystem df /mnt/data shows accurate space usage that accounts for COW and shared blocks between a subvolume and its snapshots — a traditional df can be genuinely misleading here, since it doesn't understand block sharing.
Hands-On Exercises
Explain, using this chapter's own COW model, why a Btrfs snapshot of an unmodified 500GB subvolume takes almost no additional disk space, while a full copy of the same data would take another 500GB.
📄 View solutionExplain why ext4 would silently return corrupted data after a bit-rot event on a failing disk, while Btrfs would detect the problem, referencing what each filesystem actually does (or doesn't do) on a read.
📄 View solutionA team relies entirely on nightly Btrfs snapshots of their production data, with no separate backup system, reasoning "we have snapshots, we're covered." Explain the real gap in this reasoning, using this chapter's own warn-box.
📄 View solutionChapter 3 Quick Reference
- Copy-on-write — modifications write new blocks instead of overwriting in place; old blocks live on until unreferenced
- Subvolumes — independently mountable/snapshottable filesystems-within-a-filesystem, no separate partitions needed
- Snapshots are near-instant and near-free — they share every block with the original until something changes
- Btrfs checksums data and metadata by default — real corruption detection ext4 doesn't have, plus self-healing with redundancy
btrfs scrubproactively verifies and repairs before a real read ever hits corrupted databtrfs filesystem df— real, COW-aware space accounting, unlike a traditional df- Snapshots are not backups — same disk/pool, no protection against actual disk failure