On a copy-on-write filesystem such as Btrfs or ZFS, what is a snapshot physically, and why do free space and file layout behave in ways that surprise people once snapshots exist?

## Copy-on-write in one paragraph A traditional filesystem such as ext4 or XFS writes a modified block back over the block it came from. A copy-on-write filesystem never does. When a block changes, the new version is written to free space, and the metadata node pointing at it is itself rewritten to free space, and so on up to the root of the tree, which is updated last. The effect is that the on-disk state moves atomically from one consistent tree to the next: either the new root is committed or it is not, and there is no window in which a half-updated structure is visible. That is also why these filesystems have no separate data-journalling mode — the write-elsewhere discipline is the crash-consistency mechanism. ## What a snapshot therefore is Once nothing is overwritten in place, a snapshot is almost free. On Btrfs a subvolume is an independent file tree within the filesystem, and a snapshot is a new subvolume that starts out pointing at exactly the same extents as the source: ``` btrfs subvolume snapshot -r /srv/data /srv/.snapshots/data-2026-08-20 ``` No data is copied. The operation is effectively constant time regardless of whether the subvolume holds one gigabyte or one terabyte, because all it does is create a second reference to an existing tree and mark those extents as shared. `-r` makes the snapshot read-only, which is what you want for anything you intend to keep or send elsewhere; without it the snapshot is writable and diverges independently. ZFS expresses the same idea as `zfs snapshot pool/dataset@name` over a dataset. This is why snapshot-based workflows are so appealing: a pre-upgrade snapshot, a roll-back after a failed deployment, a stable point-in-time tree for a backup to read from while the live system keeps writing. ## Where the space actually goes The cost is deferred, not avoided. From the moment the snapshot exists, every block the live subvolume rewrites must exist twice: the old version pinned by the snapshot, the new one in the live tree. Space consumption therefore tracks the *rate of change*, not the size of the snapshot. The consequence that catches people out is deletion. An engineer responding to a full disk deletes a 200 GB file and sees no space returned. That is correct behaviour: the extents are still referenced by a snapshot, so they cannot be freed. Nothing is reclaimed until every reference is gone, meaning the snapshots holding those extents are deleted too. This is also why plain `df` is untrustworthy on Btrfs — a single number cannot express space that is shared between trees, shared metadata, or space allocated to chunks but not yet used. Use the filesystem's own accounting: ``` btrfs filesystem usage /srv btrfs subvolume list /srv ``` ZFS shows the same information per dataset through the `USEDSNAP` and `USEDDS` columns of `zfs list -o space`. Btrfs quota groups can attribute space per subvolume, at a real performance cost that many operators decline to pay. ## Fragmentation and the overwrite workload The second surprise is layout. Because a rewrite of the middle of a file allocates a new block somewhere else rather than reusing the old one, a file subjected to sustained random overwrite scatters across the device. For append-mostly or write-once data this barely matters. For a database's page files or a virtual-machine disk image it matters a great deal: after months of random writes, a scan that ought to be sequential becomes thousands of seeks, and on rotational media the difference is dramatic. Btrfs gives you an opt-out. `chattr +C` sets the no-copy-on-write attribute on a file, and the `nodatacow` mount option applies it filesystem-wide. Two caveats make this less of a free win than it sounds. The attribute only takes effect on a file with no data yet, so in practice you set it on the *directory* before the files are created and let new files inherit it. And disabling copy-on-write also disables data checksumming for those files, because a checksum cannot be updated atomically with an in-place overwrite — you have given up the integrity guarantee that was a main reason to choose the filesystem. Note too that even a `nodatacow` file will copy a block once after a snapshot is taken, since the snapshot's reference must be preserved. There is also the `autodefrag` mount option, which rewrites small random writes more contiguously. It helps some workloads and hurts snapshot-heavy ones, because defragmenting rewrites extents and breaks the sharing that made the snapshots cheap — space usage can jump sharply. ## A snapshot is not a backup The last point is the one to say out loud. A snapshot shares blocks with the live data on the same device: it survives an `rm -rf` and a bad deployment, and it does not survive the device failing, the pool being destroyed, or the machine being lost. It is a fast local undo. It becomes a backup only once it has been replicated somewhere else — `btrfs send` of a read-only snapshot, or `zfs send`, into storage with an independent failure domain. ## What the interviewer wants That you can explain why a snapshot is instantaneous *and* why it can bankrupt a volume weeks later, which are the same fact seen from two ends, and that you know which workloads should not sit on copy-on-write at all.