经典基准测试漏掉了什么？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 评论区
97- 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 运行在共享的临时虚拟机上使用循环设备（每个文件系统一个 VM）：请对比形状和比例，而非绝对的 MB/s。每个作业都会记录一个主机校准锚点——见表格。
我认为如果你没有使用裸机进行此类测试，结果很可能根本不具备可比性？如果另一个租户也在使用该磁盘怎么办？
- irusensei
在存储成本高昂的当下，BCacheFS 是 Linux 上最好的文件系统。
你可以在 bcachefs 上混合使用不同大小和类型的设备。你可以拥有前景设备和背景设备以平衡性能，还可以为前景和背景事务设置不同的压缩策略。
你可以在 bcachefs 上为单个文件或目录设置 replicas=N。例如，对于那些你可以重新下载或重新构建的文件，可以设置较低的副本数；同样，你也可以为重要文件设置更高的副本数。
- bhaney
看到 bcachefs 如此出色的表现，更让我难过的是 Kent 和其他内核开发者未能达成共识，无法让 bcachefs 进入主线内核。我迫切想在我的存储阵列上使用它，但目前仍被困在 btrfs 上，因为它是唯一可用的具备现代特性的主线文件系统。
- sippingabonedry
所以，有两个文件系统本质上被 Linux 内核排斥，沦为永久的二等公民，还有一个被 Red Hat 移除且可靠性历史存疑。哦天哪，我该选哪个？
我选在另一个操作系统上使用 ZFS。