The modern-fs-benchmark project addresses a critical limitation in filesystem assessment by testing capabilities that traditional benchmarks overlook. While standard evaluations like those from Phoronix focus on single-device performance with default settings, this suite examines how btrfs, ZFS, and bcachefs behave under realistic multi-device scenarios including redundancy layouts, snapshot management, and compression - features that define their actual deployment value but are absent from conventional testing methodologies that run fio on one device with default mkfs options. As the project documentation states, 'Classic filesystem benchmarks run fio on one device with default mkfs options. That says nothing about what modern filesystems are actually deployed for.'
This image shows the source repository of the benchmark discussed in the article, which evaluates btrfs, ZFS, and bcachefs under realistic multi-device scenarios.
The benchmark’s methodology measures a wide range of workloads that reflect real storage use. It begins with host calibration (fio on the runner’s disk before any filesystem exists) to anchor VM noise, then proceeds through sequential/random write and read baselines, trivial-op latency under load, source-tree operations (copying a kernel tree), large-directory scalability (100k empty files), parallel random reads, fsync tail latency, snapshot aging (random-overwrite bandwidth as snapshots accumulate), snapshot create/delete costs, compression ratios and throughput, reflink and clone divergence tests, degraded operation and rebuild timing, snapshot-count scaling (up to 500 snapshots), near-full/ENOSPC behavior, physical I/O amplification, and corruption-plus-scrub verification. Ext4 and XFS over md/LVM RAID serve as classic-stack baselines for comparison.
The image illustrates Btrfs features such as subvolumes and snapshots that are evaluated in the benchmark’s workloads like snapshot aging and compression testing.
This image shows subvolume management in Btrfs, relevant to the benchmark’s snapshot create/delete costs and snapshot-count scaling tests.
A key contribution is the data‑integrity verification test. Classic stacks (ext4/XFS on md/LVM RAID) lack end‑to‑end checksumming and can silently return corrupted data during scrub operations, yielding an “UNPROVEN” result because they only count mismatches without identifying which copy is correct. In contrast, btrfs, ZFS, and bcachefs verify every read against checksums and, given appropriate redundancy, can reconstruct a bad allocated block from a good replica or parity, producing “SURVIVED” (file still readable with same hash) or “FAIL” (hash changed or unreadable) outcomes. The documentation notes that the classic stack can achieve a similar guarantee using LVM raid with --raidintegrity y and md parity over per‑member dm‑integrity, but at a measurable performance cost.
The benchmark runs in GitHub Actions using loop devices on shared virtual machines, which limits the usefulness of absolute performance numbers due to noisy neighbours and VM variability. The author acknowledges that within‑job ratios and shapes (e.g., aging‑curve slope, compression on/off, degraded vs healthy) remain directly meaningful because they come from the same VM and disk, and that trends over repeated runs (six‑hourly cron plus every push) average out the VM lottery. With 593 runs recorded, the averages are considered quite meaningful, though the author continues to seek real‑hardware results, having managed three runs on a Hetzner machine before it failed.