Filesystems

Btrfs entered the mainline kernel earlier this year, so naturally I created a filesystem and started putting unimportant data on it. Filesystems are fascinating, provided the nouns “only copy” and “family photographs” remain elsewhere in the sentence.

The central structure is a copy-on-write B-tree. When metadata changes, Btrfs writes new blocks rather than overwriting the existing path in place. Data can also be copy-on-write. This makes snapshots and clones natural consequences of the storage model instead of layers awkwardly attached above a filesystem.

Snapshots are cheap at creation because they initially share existing extents. As either side changes, new extents represent the differences. That is attractive for test trees: I can capture a known state, run an unpleasant upgrade and return without copying every unchanged file. Shared blocks also mean deletion and free-space accounting are less obvious than in a simple independent copy.

Checksums cover data and metadata, allowing corruption to be detected rather than quietly delivered. With redundant storage, the design can potentially use a valid copy to repair damaged data. Detection alone remains valuable, although it cannot reconstruct bytes that exist in only one damaged place. A checksum is an alarm, not a backup wearing mathematical spectacles.

Btrfs also aims to manage multiple devices and provide subvolumes, online growth, compression and other facilities usually assembled from several layers. Integrating them allows the filesystem to understand which blocks contain live data, which can help operations that would otherwise see only an undifferentiated block device.

The ambitious scope is exactly why I am cautious. Mainline inclusion makes development and testing easier; it does not make the format or implementation mature overnight. Repair tools, failure behavior and operational knowledge matter more than a successful benchmark. A filesystem earns trust through years of dull recoveries, not a feature table.

My current test uses build outputs and source trees already stored elsewhere. I exercise snapshots, fill the filesystem, delete subvolumes and simulate untidy shutdowns. Performance is interesting, but I care more about whether every operation has understandable results and whether tools can explain the state afterward.

I prefer Btrfs’s integrated copy-on-write direction for experiments that benefit from snapshots. I do not yet prefer it for important production data. ext4 is the conservative choice today, and even that choice requires backups. Btrfs is early and explicitly experimental; the most useful contribution ordinary testers can make is finding failures without turning those failures into personal disasters.

I have been testing ext4 on disposable filesystems for a while, but I have avoided recommending it for ordinary machines. Linux 2.6.28 was released on December 24 and removed ext4’s experimental designation. Only now am I comfortable calling it stable in the kernel sense, which is not the same as volunteering the only copy of my photographs.

The most visible change from ext3 is the use of extents. Rather than describing a large contiguous file as a long list of individual blocks, an extent describes a range. Large files need less metadata, and allocation can stay contiguous more easily. The on-disk format can also support much larger filesystems and files than ext3’s older structures comfortably allow.

Delayed allocation is another important piece. The filesystem can postpone the final block placement until dirty data is written, when it knows more about the size and neighboring writes. Combined with multiblock allocation, this can reduce fragmentation and improve throughput. The tradeoff is that allocation and write timing differ from ext3, so applications that confuse close() with durable storage may have their assumptions exposed.

The journal still protects filesystem metadata, but it is not a magical backup and does not promise that every recently written byte survives a crash. Applications that require ordering and durability need to use the proper synchronization operations and safe replacement patterns. A stable filesystem cannot repair an application protocol that never asked data to reach the disk.

Migration is possible because ext4 grew from ext3, but enabling new features changes what older kernels and tools can understand. I prefer creating a fresh ext4 filesystem for serious evaluation rather than turning an existing one into an archaeology project. Current e2fsprogs support is as important as kernel support, especially when the machine fails to boot and the rescue environment suddenly becomes relevant.

My cautious plan is to use ext4 first for build trees and other replaceable data, with backups and a recent kernel. If that remains boring, it can graduate to less disposable machines. I strongly prefer its extent-based direction over stretching ext3 forever, but five days with a stable label is not decades of field experience.

So ext4 is stable now, after December 24, 2008. It is also new, complex software in the least amusing place to discover a bug. Both statements can be true, and my backup disk does not mind the apparent indecision.