dashboard. These runs provided meaningful absolute measurements and exposed concurrency behavior that cannot be observed when several loop devices share one virtual disk.

During the fourth run, one NVMe controller entered the kernel’s dead state. The existing machine environment had its operating system on RAID0 across the two NVMe devices, so the hardware failure also made part of /nix/store unreadable and eventually prevented new SSH sessions.

The incomplete fourth run is not being published as benchmark data. This was a failure of the underlying hardware, not a result attributable to any filesystem being tested.

I am grateful to Kent for providing the machine and making the real-hardware experiment possible. Without that access, the three existing hardware runs would not exist.

Where I would like to take it

Better hardware would not merely produce more reliable throughput numbers. It would enable an entirely new class of tests designed for multi-device and multi-tier filesystems.

I would eventually like to run the suite on a machine containing several storage classes, for example two HDDs, two SSDs and an NVMe device.

That could support scenarios such as:

\- HDD, SSD and NVMe baselines using identical workloads

\- bcachefs foreground and background targets

\- ZFS HDD data vdevs with SSD special vdevs

\- Separate ZFS L2ARC and SLOG experiments

\- LVM dm-cache in writeback and writethrough modes

\- Metadata and small-block placement on faster media

\- Foreground latency during background migration

\- Contention between fast and slow storage tiers

\- Degraded operation and rebuild under application load

\- Performance before, during and after promoting or evacuating a storage tier

These are the kinds of scenarios for which multi-device and multi-tier filesystems are built, but they cannot be represented honestly when every “device” is a loop file backed by the same cloud disk.

I am considering either renting a suitable dedicated server or eventually building and hosting my own machine. Providers such as Worldstream offer configurations close to what I need, but the recurring cost is currently outside the project’s budget.

For now, the benchmark will remain in its hosted-CI form for an unknown amount of time. The existing dashboard will continue to be useful for correctness, behavioral comparisons and regression tracking, but it cannot answer every real-hardware performance question or model complex mixed-media topologies.

I am also open to running the suite on hardware provided by someone else. A useful environment would need Linux root access, clearly identified block devices that may be wiped, and enough uninterrupted access to complete repeated runs. The hardware description, methodology and resulting data would remain public.

I would appreciate technical feedback:

\- Which current tests are misleading or unfair?

\- Which failure scenarios are missing?

\- Which mixed-media topologies would be most useful?

\- Which additional filesystems or layered stacks should be included?

\- Which results deserve deeper investigation?

The methodology, implementation and raw results are public. If a filesystem is being tested in a way that misrepresents it, I consider that a bug in the benchmark.

https://redd.it/1v4lsfk
@r_linux