Copy-on-write roots and the storage that snapshots retain

Picture a root that reaches metadata nodes and data extents. Changing one leaf can require a new leaf and copies of ancestors along its path; unchanged branches can remain shared. Before publishing the replacement root, the required new children must be safely available under the filesystem's commit protocol. Otherwise a durable root could point to missing updates. Recovery must identify a valid committed view, not merely follow whichever root write happened to begin last. Real implementations include transaction machinery and recovery details beyond this small tree model.

Copy-on-write is a family of techniques rather than a universal guarantee about every byte. Filesystem features, per-file flags, direct I/O behavior, compression, and implementation choices affect actual paths. Btrfs normally uses copy-on-write and supports snapshots and reflinks, but users should consult the specific feature contracts rather than infer that all operations create an independent full copy. A reflinked file can share data extents while having a distinct file identity. That is different from a hard link, which provides another name for the same inode.

A snapshot can initially preserve a view by retaining references instead of copying every payload block. As the active version changes, older extents remain allocated while any retained snapshot still references them. Deleting a large file from the active namespace may therefore release little unique storage. Likewise, deleting one snapshot releases only blocks no remaining reference requires. Build a retention estimate from changed, uniquely retained data and metadata, then check filesystem-specific accounting instead of assuming a directory listing tells you which bytes can actually be reclaimed.

Shared extents also create shared fate. Two snapshots on one device are not two independent backups: a lost device can remove both, and damage to a shared block can affect several versions. A snapshot taken while an application is updating several objects may capture an application-inconsistent moment even if the filesystem snapshot itself is structurally coherent. Coordinate the application or use a recovery-capable format when needed. Keep an independent backup strategy and test restoration; the ability to browse yesterday's snapshot proves much less than surviving loss of the storage that holds every snapshot.

Rewriting a small range can create metadata and allocation work, and retained snapshots can reduce space available for future placement. Evaluate the workload's overwrite size, snapshot frequency, retention duration, and free-space behavior together. A benchmark that creates one empty snapshot and never mutates data misses the accumulating cost. Conversely, claiming that copy-on-write always makes large-file operations slow ignores sharing, caching, request aggregation, and workload dependence. Measure the actual application operation and synchronization boundary before choosing flags that trade away checksumming or copy-on-write behavior.

The probability lab deliberately exposes an independence assumption relevant to retained copies. Set a small success probability p to mean failure of one independently stored block, and use n trials to model n distinct blocks. Increasing n raises the expected affected-block count np. It does not mean n snapshots are independent replicas: shared extents violate that interpretation. Predict how changing n alters the distribution, then explain why counting snapshot names as trials is wrong. The model illustrates independent events only; it cannot create snapshots, follow references, or evaluate a filesystem's recovery protocol.