Three prevalent themes in the discussion
- Concerns about benchmark methodology and realism
- Users questioned whether writing 2 GiB directly to the block device and bypassing the page cache produced meaningful results.
- “I’m not sure that nuking 2G of the underlying block device is a recoverable error on any filesystem that I'm aware of? Can you confirm if any of the filesystems really came out of the other side in a usable state after scrubbing?” — Farmadupe
-
“Are any of the metrics you used standard industry metrics? It looks like several of the tests are bypassing the kernel's page cache? — which I worry may fall into the trap of ‘I modified the system to be unrepresentative of reality and then tested it’.” — Farmadupe
-
Readability / UI of the results page
- Several commenters found the presentation hard on the eyes and suggested improving the HTML/CSS.
- “I'm sure you've got good data but speaking on behalf of my eyeballs, the results page is... hard to read!” — Farmadupe
-
(Implicitly echoed by others who did not quote but expressed similar discomfort.)
-
Preference for established filesystems (especially ZFS) over newer alternatives
- Many participants expressed trust in ZFS due to long‑term stability, despite acknowledging its performance trade‑offs.
- “For peace of mind I'm still using zfs (since the last 15+ years) but I'm definitely not impressed by the performance…” — blop
- “Different tools for different jobs; use ZFS for your data store and ext4 for your primary drive.” — slyfox125