5. a ZFS dRaid configuration. There could be very different characteristics there with it using slabs.

Speaking of slabs, MS ReFS of you feel adventurous!

1. XFS reflink is enabled and its reflink/CoW-break measurements do run. The dashboard button currently means “native/full-CoW filesystem family”, not “supports reflink”, but that distinction is not clear from the label. I’ll rename it to “Native CoW” and add a separate reflink-capable filter that includes XFS.

2. The current integrity comparison is XFS on LVM/dm-raid10 with dm-integrity in its default journal mode. It is not mdraid and not bitmap mode, so your suggested stack would be a genuinely different and useful data point. An md RAID5/6 over per-member bitmap-mode dm-integrity comparison against RAID-Z1/Z2 makes sense, with the weaker post-crash bitmap semantics documented.

3. I did not pin or record the scheduler, which is a reproducibility gap. The dedicated SAS machine currently has mq-deadline active on all HDDs and SSDs. I’ll add queue/scheduler metadata to results before considering separate scheduler variants, since it can strongly affect the mixed and latency-sensitive phases.

For that you have to dig into the methodology, look at the code, look at user reports, etc.

But you can get a pretty good approximation just from the philosophies and attitudes of the engineers and what they're talking about.

The talk I just gave at the Rust for Linux conference was all about that - how do we make the system debugable, the community aspect of how we respond to bug reports and talk to users, the prep work for the Rust conversion and formal verification and how we're approaching all that.

Reliability doesn't come out of nowhere, "all bugs are shallow with enough eyeballs" really doesn't apply to filesystems. You just have to plan for it, come up with a methodology, and do the work.

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

<- 5Y ago.

It's not materially better now. The devs are in denial about the problems because lots of big users are saying "works fine on my machine."

Sure, if you have lots of backups, if you have huge volumes on huge disks and they never fill up...

But it's the default in Fedora, Spiral Linux, Garuda Linux, siduction and others. Personal distros for people's own PCs and those are not well-supported enterprise kit.

Most normal users and especially servers have no reason to run latest upstream kernels

Well don't do that then. There's lots of other options. Probably the simplest is a single bare metal install on a simple filesystem on one device. run the filesystems under test on other storage dedicated to testing.

You could also boot into a network install and use local storage exclusively for testing.

In this case, given that the author's own disclaimer (above) already disclaims the numeric readings, I'm not sure how it's possible to make any inference on "shapes and ratios" derived from the numeric readings.

Real hardware is used in: https://bartosz.fenski.pl/modern-fs-benchmark/real-hw/ https://bartosz.fenski.pl/modern-fs-benchmark/sas-hdd/

But unfortunatelly it's much more limited number of actual runs. sas-hdd is still in progress so numbers for it should increase over time.

Well except for Ubuntu, one of the most popular Linux distros supporting it.

Eh. Just wait until Oracle goes bankrupt due to their AI misinvestments & see where ZFS rights end up.

But there's a LOT of FUD about it.

I could drop bricks on and cord pull those all day and they would not lose data. Which is a small ask for a filesystem IMO.