Btrfs/ZFS/bcachefs 在工作负载下的经典基准测试被跳过

基准测试范围与方法

• 基准测试针对多设备、CoW 文件系统和类似 RAID 的配置（包括完整性 / scrub 行为），使用 fio 测量吞吐量、IOPS 和 fsync 延迟。
• 若干工作负载是自定义的（例如每 200 ms 进行一次 4 KiB 写入 + fsync 作为“trivial op”延迟探针）。作者承认这些是项目特定的，不是行业标准。
• 目前测试主要运行在 GitHub 托管的 VM 上，并使用基于循环设备的稀疏文件；作者强调应只比较相对的“形状和比例”，不要比较绝对 MB/s。
• 有一个校准步骤用于剔除最吵的 VM，并且也有一些有限的“真实硬件”测试，更多还在进行中，包括 HDD/SSD 混合和分层配置。

数据完整性与损坏测试

• 一项测试是在复制集中的单个设备上覆写 2 GiB 的原始块，然后运行文件系统 scrub。
• 一些评论者质疑这在现实中是否真的“可恢复”，以及“完整性”成功/失败到底意味着什么。
• 作者澄清，该标签将改名为“corruption probe”：所谓“survived”只表示某个特定文件保持可读且未改变，并不意味着整个文件系统完全健康。

结果展示与可用性

• 一些人觉得页面信息密度过高且视觉上难以浏览：文字太小、图表一次太多、像“Overall Core”和“Core I/O”这类复合评分的定义也不清楚。
• 另一些人，尤其是工程师，喜欢这种“数据墙”，更偏好细节而不是简化。
• 建议包括：更清楚地描述测试对象、更好地解释派生指标、把运行元数据移出顶部，以及可能利用 JSON 数据提供替代的“简化”视图。

环境真实性与硬件覆盖

• 有人认为共享云运行环境中的“吵闹邻居”会让结果难以信任，并主张使用专用裸机测试平台。
• 也有人接受这些限制，指出该项目关注的是完整性而非绝对性能，而且大规模裸机自动化既困难又昂贵。
• 多个请求希望增加更多场景：HDD 对比 SSD、NVMe、不同 RAID 容量、非 CoW 文件系统、dm-integrity、dRAID、F2FS、DRBD、CephFS，以及带完整性层的 XFS。

Bcachefs、Btrfs、ZFS 与替代方案

• Bcachefs 在基准测试中表现强劲，并因混合设备层级和按文件复制等特性受到称赞，但人们仍担心其成熟度以及最近被移出主线的问题。
• 一些用户对通过 out-of-tree/DKMS 在某些发行版上使用 bcachefs 感到满意（例如基于 NixOS 的配置、NAS 设备），并表示实际体验良好。
• Btrfs 被视为“默认的现代”树内选项，但也受到批评，原因包括：
  • 空闲空间报告不可靠。
  • 卷填满时行为脆弱。
  • 修复工具较弱，且 RAID5/6 仍不被推荐。
  • 在某些环境下，大量删除文件时偶尔会出现严重卡顿。
• ZFS 因数据安全性而广受信赖，但也受到以下批评：
  • 某些工作负载下性能较低。
  • 许可证带来的摩擦使它无法进入许多发行版和救援环境。
  • 在部分发行版上，DKMS 无法跟上快速的内核更新。
• 许多更偏生产环境的评论者仍然偏好 ext4/XFS 这类更简单的栈，而不是 LVM/MD RAID，因为它们更可预测，有时再辅以单独的压缩/去重层（例如 dm-vdo）。

社会因素与内核治理

• 一些评论强调，文件系统的“社会健康”（bus factor、维护者争议、CoC 问题、企业赞助）与原始性能同样重要。
• Bcachefs 被移出主线，以及此前与内核维护者的冲突，让一些人对其信任度和未来稳定性产生担忧；也有人认为这些主要是维护者层面的问题，最终用户只需要好的工具和可靠性。
• 大家普遍希望 bcachefs 在开发稳定、并且有更广泛的维护团队后，最终能回到主线。