OpenZFS 中的数据损坏 bug？

原文 ↗ Hacker News 讨论 ↗

OpenZFS 中一个罕见的竞态条件会在某些复制操作中把文件静默填充为零，而且传统的损坏检测方式无法通过 scrub 发现，这引发了依赖 ZFS 数据完整性的用户担忧。评论者强调该 bug 很难触发，可能并未影响大多数系统，但也借此强调要采用稳健且经过测试的备份策略、选择性的异地存储，以及了解稀疏文件和快照等特性如何与真实工作负载相互作用。讨论还涉及 bcachefs 等替代方案、Btrfs RAID 模式的局限，以及许可和 Oracle 对 ZFS 的管理对 Linux 采用率的影响。

OpenZFS bug 的影响

  • 被描述为一种非常罕见的竞态条件，在实践中很难触发。
  • 在大量写入/移动工作负载中，症状会很明显（例如，构建树中突然出现全是零填充的文件）。
  • 有人指出，检查 bcloneused/bclonesaved 并不是 可靠的测试；bclone 只是其中一个触发条件。
  • 这种损坏不是传统意义上的磁盘损坏：cp 读到零并写回，ZFS 也会正确存储它们，因此 scrub 和与备份逐字节比较都无法检测出来。
  • 考虑到该 bug 的历史悠久，以及大型 ZFS 用户没有相关报告，一些评论认为现实中的风险很低。

备份可靠性与测试

  • 强调备份经常会静默失败：工具可能跳过文件、中途停止，或者日志记录很差。
  • 建议：
    • 定期测试恢复，包括那些你很少接触的系统。
    • 让不是专家的人来执行恢复，以验证文档和工具链。
    • 保持脚本和修复工具为最新。
    • 备份完成后进行验证（大小、能否解密/解包、在可能时校验哈希）。
    • 至少使用两种不同的备份实现。
  • 数据库备份被指出尤其棘手；仅靠文件系统快照不足以保证事务一致性。

家用 NAS 与大规模数据备份策略

  • 许多人认为“普通家用 NAS”并不意味着 40 TB；对大多数人来说，只有一部分数据（照片、文档）需要云备份。
  • 提到的策略包括：
    • 云端（Backblaze、S3 Glacier/Deep Archive、Hetzner Storagebox、B2），并按重要性分层。
    • 第二台 NAS 或异地服务器（家人/朋友处），通过 VPN/Tailscale/Nebula 上的 rsync/ZFS send/syncthing。
    • 外置 HDD/SSD 冷存储，轮换使用并大部分时间离线。
    • 对于大型、关键数据集使用 LTO 磁带，有人认为长期来看性价比高，但操作上繁琐且噪音大。
  • 经验法则：为备份投入约为“热”存储成本的 3 倍；优先考虑多个非冗余副本，而不是单一的 RAID 副本。

稀疏文件与文件系统抽象

  • 围绕稀疏文件以及 SEEK_HOLE/SEEK_DATA 是否是设计失误还是有用优化展开争论。
  • 一些人认为稀疏文件把块级细节泄露到用户空间，并引入复杂性，从而可能导致类似这样的 bug。
  • 另一些人则认为它们对 torrent、数据库、虚拟机镜像以及去重等工作负载至关重要。
  • 讨论还涉及 fallocate、mmap，以及不同文件系统和 COW 语义如何与预分配和碎片化相互作用。

替代文件系统与许可政治

  • 有人指出，近期的严重 bug 出现在 OpenZFS，而不是 Oracle 的闭源 ZFS，但 Oracle 实际上已经放弃了 Solaris。
  • 关于 CDDL 与 GPL 的长篇讨论：二者不兼容使 OpenZFS 合并进 Linux 变得复杂；有人认为法律风险被夸大了，也有人认为 Oracle 仍是一个严重威胁。
  • Ubuntu 长期随系统提供 ZFS 而未遭法律行动被拿来作为例子，但一些人认为未来仍可能发生诉讼。
  • 一些人认为 bcachefs 是一个有前景的 Linux 原生替代方案（异构磁盘、类似 RAID-5/6 的冗余、对 SMR 友好），但也有人提醒它仍然年轻，真实世界暴露有限，而且已有损坏报告。