A filesystem is the kind of infrastructure you never notice, until the day it decides everything.

What copy-on-write pays for downstream

Btrfs is a modern copy-on-write filesystem for Linux. The first page of the documentation gives the whole definition in one sentence and states the design goals with it: advanced features together with fault tolerance, repair and ease of administration. That order deserves attention, because putting recovery after failure into the goals means the thing was designed for long service from the start.

Copy-on-write is the pivot of the design. Data is not overwritten in place; the new version is written elsewhere and the pointer is moved, so the state before and after an edit both survive. Checksums, snapshots and send-receive are cheap to provide precisely because of that. The official feature list is long: checksums, compression, deduplication, defragmentation, inline files, quota groups, reflink, online resize, checksum repair, send and receive, subvolumes, swap files, TRIM and volume management.

It is worth being clear about what copy-on-write does not buy. Blocks are not duplicated for free forever: an edited block is written again, so a workload that rewrites the same file constantly pays twice, once in fresh allocation and once in the deferred cleanup of the old extent. That is why the maintenance steps below are not decoration but part of the daily cost of the design.

The capabilities that get used

Checksums are how bad data gets noticed. The documentation gives them a chapter of their own, covering how data and metadata are verified, and another chapter on automatic repair on read explains how data is corrected when a usable copy exists. Together the two chapters form the basic guarantee of data integrity.

Subvolumes and snapshots handle organisation. Subvolumes have their own chapter, and a snapshot is an ordinary operation on a subvolume; with copy-on-write the cost of making one and the space it occupies both stay small. Send and receive handle transport: a subvolume or snapshot is streamed into another Btrfs filesystem, which suits incremental backup. Volume management lets several devices join one filesystem, with balance, device replace and seed devices alongside.

The tooling and the release

Day to day work goes through btrfs-progs, the command line set that holds mkfs, check, scrub and balance. The official change log lists 7.1 as current, dated 14 July 2026, followed by 7.0 on 9 May 2026 and 6.19 on 13 February 2025. The tools are open source under GPL-2.0, with the licence file in the repository root and a separate one for the library part.

The 7.1 changes concentrate on efficiency in two places, building and checking. The record shows that mkfs can reuse existing checksums through the GET_CSUMS interface when a root directory is given, and with reflink it avoids reading file data a second time; check gained an option to skip quota group verification, which makes a run faster. Such changes look modest, but on a large filesystem the time saved is real.

One more practical note concerns whether the filesystem gets chosen at all. Btrfs is not the default everywhere, and the distributions that offer it usually place it next to a simpler option. Reading the feature list as a menu is the wrong instinct; the right question is which two or three of those features a machine will actually use, because every one that is enabled has to be maintained, monitored and understood by whoever is on call.

The value of a storage design is not how long its specification is, but whether you dare leave the data alone afterwards.

A few suggestions. Run a full check on a new disk and find the bad blocks before putting data on it. Keep rollback points as subvolume snapshots, far cheaper than copying a whole disk. Confirm the redundancy level before a multi-device setup goes live, so one failed disk cannot take the whole filesystem with it. Move data between machines with send and receive, where an incremental transfer saves the time a full copy would spend.