a copy-on-write file system
/ btrfs -> BUTTER-eff-ess /
Imagine you never erase a manuscript page to edit it. Instead, to change a line you photocopy the page, edit the copy, and only when the copy is perfect do you swap it into the binder in place of the old one. The old page survives untouched until the very last move. A copy-on-write file system works this way: it never overwrites a live block in place. To change data, it writes the new version to a fresh, free block, then updates the pointers to point at the new block — and the old version stays intact until that switch happens.
Because nothing live is overwritten, the on-disk state is always consistent: at any instant the file system either still points at the entirely-old version or has switched cleanly to the entirely-new one, never a half-mixed mess. The switch is made atomic by chaining the change all the way up a tree of pointers to a single root that is updated last: write the new data block, then the new inode pointing to it, then the new directory pointing to that inode, and finally flip the one root pointer (the superblock) to the new tree. A crash before the root flip simply leaves the old, consistent tree; a crash after it leaves the new one. This same mechanism makes snapshots almost free: keep the old root pointer around and you have a frozen, read-only view of the entire file system as it was at that instant, sharing all the unchanged blocks. ZFS and btrfs are the well-known copy-on-write file systems.
Copy-on-write gives strong crash consistency without a separate journal (the consistency is built into how writes happen), plus cheap snapshots, checksums for detecting silent corruption, and easy rollback. The honest costs: writing new copies instead of overwriting tends to scatter a file's blocks over time (fragmentation), which can hurt sequential read speed, and tracking many shared blocks and snapshots takes extra metadata and memory. It is a different bargain from journaling, not a strictly free upgrade.
On btrfs you run snapshot before a risky upgrade — instantly, costing almost no space, because the snapshot just shares all the existing blocks. The upgrade then writes only new copies of changed blocks. If it breaks the system, you roll back to the snapshot's root pointer and every original block is still there untouched.
Never overwrite in place: write new, switch the root atomically — consistency and cheap snapshots for free.
This is the same copy-on-write idea used in memory management (sharing pages until one is written), applied to disk blocks. The trade-off is real: out-of-place writes can fragment files and the metadata to track shared blocks is heavier.