New Continuous Benchmark Tests What Btrfs, ZFS and Bcachefs Are Actually Used For

Bartosz Fenski's modern-fs-benchmark measures snapshot aging, redundancy, fsync tail latency, compression, rebuilds and near-full behavior, areas single-drive filesystem benchmarks like Phoronix's don't cover.
New Continuous Benchmark Tests What Btrfs, ZFS and Bcachefs Are Actually Used For
New Continuous Benchmark Tests What Btrfs, ZFS and Bcachefs Are Actually Used For

Most Linux filesystem benchmarks run fio against a single drive with default settings. Bartosz Fenski’s modern-fs-benchmark project tests something different: the features copy-on-write filesystems such as Btrfs, ZFS and bcachefs are actually deployed for. “Classic filesystem benchmarks run fio on one device with default mkfs options. That says nothing about what modern filesystems are actually deployed for,” the project’s README says.

The suite runs continuously and publishes results to a public dashboard, with charts sorted best-first, aging curves and trends across runs, filterable by filesystem family and redundancy layout. Ext4 and XFS running over md or LVM serve as classic-stack baselines.

What it measures

Beyond baseline sequential and random throughput on each redundancy layout, the suite covers areas single-device tests skip:

  • Latency under load: a small write and fsync every 200 milliseconds, measured idle and while a streaming writer floods the filesystem, plus p99 and p99.9 fsync tail latency, where periodic CoW transaction commits show up.
  • Snapshots: overwrite bandwidth as up to 100 snapshots accumulate, snapshot create and delete costs, how long reclaimed space takes to return, and scaling to 500 snapshots.
  • Compression, encryption and reflinks: zstd ratio and throughput, native encryption versus LUKS, and the penalty when cloned files diverge.
  • Failure handling: I/O while an array is degraded, rebuild time onto a spare, and whether a scrub repairs deliberately corrupted data.
  • Near-full behavior: write throughput at 95% and 99% full, and whether you can still delete files at hard ENOSPC, a known problem area for CoW designs.
  • Write amplification: how many bytes member devices actually read or write per logical byte, file or snapshot.

Fenski documents caveats too. Btrfs hits its chunk-allocation limit before reaching the target fullness on small CI-sized arrays, and ZFS layouts at the default 128K recordsize are capped at 10 snapshots because each snapshot pins nearly the whole test file. The README treats those caps as findings, not shortcuts. Methodology and run history are in the GitHub repository, so the results can be reproduced.

How single-drive tests compare

The contrast with conventional benchmarks is clear in Phoronix’s Linux 6.17 filesystem comparison from September 2025, which tested default configurations on a single Crucial T705 PCIe Gen5 SSD. Ext4 edged out XFS on the geometric mean, which Phoronix called likely the first upset over XFS thanks to ext4 scalability work. F2FS was a distant third, followed by Btrfs, OpenZFS and bcachefs. OpenZFS led SQLite insert tests but was slowest in ClickHouse, and the CoW filesystems trailed in 4K random reads.

Those numbers reflect out-of-the-box, single-device performance. Fenski’s project measures what that setup can’t, including snapshot aging, redundancy and recovery, which are usually the reasons administrators pick a CoW filesystem in the first place.

Subscribe for Updates

SysAdminNews Newsletter

News & updates for IT system administrators.

By signing up for our newsletter you agree to receive content related to ientry.com / webpronews.com and our affiliate partners. For additional information refer to our terms of service.

Notice an error?

Help us improve our content by reporting any issues you find.

Get the WebProNews newsletter delivered to your inbox

Get the free daily newsletter read by decision makers

Subscribe
Advertise with Us

Ready to get started?

Get our media kit

Advertise with Us