经典基准测试漏掉了什么？Btrfs、ZFS、bcachefs 在真实负载下的表现
Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
经典文件系统基准测试往往只测顺序读写和简单 IOPS，却跳过了快照老化、空间回收、设备降级重建、接近写满等真实场景。这份持续更新的基准测试专门针对这些盲区，在 kernel 7.0.0-1012-azure 上记录了 593 次运行，覆盖 ext4、XFS、ZFS、Btrfs、bcachefs 的单盘、RAID、LUKS 加密、zvol 等多种配置。测试用共享临时 VM 上的 loop 设备，因此作者强调应关注不同文件系统之间的形状和比例，而非绝对 MB/s。每个任务还记录了宿主机磁盘校准锚点，用来判断 VM 噪声。结果表格里，ZFS 的 mirror、raidz1、raidz2 以及 bcachefs 的 replicas2、ec 都通过了完整性检查，而部分 ext4 和 XFS 的 RAID 配置在损坏恢复测试中失败。
快照累积期间每次迭代的随机覆写带宽（MB/s）——持平是好事，下降则意味着 CoW 碎片化的代价。
HN 评论区
159- fenio
我是这篇基准测试的作者。我看过一些评论，打算在这里逐一回应。
我很清楚，基于 GH runner 的基准测试远非完美，原因包括邻居干扰等。因此，每个测试首先会运行所谓的“校准”……以彻底剔除那些完全不可靠的虚拟机。
我完全意识到这无法彻底解决问题。只能缓解，无法根除。
但截至目前，已记录了 593 次运行，平均值应该仍然很有意义。
话虽如此，我正拼命想办法搞到真正的硬件来运行这个基准测试。并且已经取得了一些进展 ;)
几个月前，我从 Kent Overstreet 那里得到了一台 Hetzner 机器，在机器挂掉之前我完成了 3 次运行……
结果：https://bartosz.fenski.pl/modern-fs-benchmark/real-hw/
目前我弄到了一台更有趣的机器，上面挂载了大量磁盘，我正在运行新一批基准测试，不过还处于非常初期的阶段。
https://bartosz.fenski.pl/modern-fs-benchmark/sas-hdd/
第二次运行正在进行中……在真正的硬件上跑一次比在 GH runner 上耗时多得多，所以速度很慢。
但这台新硬件拥有大量磁盘，计划是尝试更复杂的多层缓存拓扑结构。我正在着手处理。
我很乐意回答任何其他问题。这个基准测试的每一个部分源码都是公开免费的，我也没声称它们 100% 正确。我欢迎改进。
- Farmadupe
> CI 运行使用的是共享临时虚拟机上的 loop 设备（每个文件系统一台虚拟机）：请比较形状和比例，不要比较绝对 MB/s。每个任务都会记录一个主机校准锚点——见表格。
我认为如果你不是用裸机做这类测试，结果可能根本不具备可比性？万一另一个租户也在用这块盘怎么办？
- gdgghhhhh
如果有人好奇为什么 bcachefs 遗憾地不再属于主线内核，请从这里开始阅读：
- bhaney
看到 bcachefs 如此出色的结果，让我更加难过，因为 Kent 和其他内核开发者没能达成一致，无法让 bcachefs 保留在内核树中。我多么想把它用在我的存储阵列上，但我目前还是只能被困在 btrfs 上，因为它是唯一可用的、具备现代特性的内核文件系统。
- sippingabonedry
所以有两个文件系统基本上被 Linux 内核排斥，沦为永久的二等公民，还有一个被 Red Hat 移除且可靠性历史存疑。天哪，我该怎么选？
我的建议是：在另一个操作系统上用 ZFS。
- irusensei
在存储成本高昂的当下，BCacheFS 是 Linux 上最好的文件系统。
你可以在 bcachefs 上混合使用不同大小和类型的设备。你可以设置前台和后台设备来平衡性能，还可以为前台和后台事务设置不同的压缩参数。
你可以在 bcachefs 上为单个文件或目录设置 replicas=N。例如，对于那些可以重新下载或重新构建的文件，你可以设置较低的副本数。同样，你也可以为重要文件设置更高的副本数。
- loeg
md-raid10 到底做了什么，导致它在“I/O”和“响应速度”方面比 lvm-raid10 差那么多？无论是从链接的页面还是 https://github.com/fenio/modern-fs-benchmark 来看，这对我来说都不太明显。从原理上讲，它们应该差不多才对？
- blop
我认为评测还应该包含这些文件系统的社会层面因素……
过去和现在都有许多有前景、令人兴奋的文件系统可以取代那些老旧无聊的，但对于存储来说，你不仅想避开技术问题，还想避开维护者之间的戏剧性冲突……