Btrfs 中的漏洞排查

原文 ↗ Hacker News 讨论 ↗

Btrfs 相对于 ZFS/Bcachefs 的未来

  • 一些人认为 Btrfs 还有很长的未来，尤其是考虑到 ZFS 的许可复杂性以及 Bcachefs 在纠删码和 scrub 等功能上的不成熟。
  • 另一些人认为 Bcachefs 最终会取代 Btrfs，但指出这“还要很多年”。
  • Bcachefs 被认为历史失误更少，但它仍然缺乏关键功能和真实世界的使用经验。

ZFS 的许可与法律风险

  • 关于 GPL/CDDL 不兼容是否真的禁止在 Linux 上分发 ZFS 存在争论；一些人引用 OpenZFS 的观点，认为二进制模块是可以的。
  • 反方观点是：法律理论不如 Oracle 可能带来的高成本麻烦重要；保守的发行版合理地避免这种风险。
  • Ubuntu 长期提供 ZFS 模块而未遭到 Oracle 采取行动，被引用为风险较低但并非零的证据。

可靠性与数据损坏经历

  • 一些用户报告在消费级硬件上反复出现、甚至无法恢复的 Btrfs 数据损坏，与 ext4 相比显得更差。
  • 另一些用户则报告了十年以上的稳定使用，包括多盘 RAID1 和长期运行的系统，有时在手动修复后还能扛过硬件故障。
  • 结论：Btrfs 有棱角；某些工作负载和错误配置（坏内存、RAID5/6、配额）存在风险。

性能、后台工作与配额

  • 有报告称 Btrfs 的“cleaner”/后台线程在低端系统上占用很高的 CPU，使其感觉无法使用，尤其是在 openSUSE 默认配置（快照 + 配额）下。
  • 关闭配额通常能缓解问题；在启用配额时删除快照被指出尤其昂贵。

已知问题区域与 Bug

  • RAID5/6 被广泛认为不安全；官方文档和工具都不鼓励使用。
  • 有人描述了一个可复现的 bug：将几乎满的 ext3 转换为 Btrfs，然后在启用压缩的情况下进行碎片整理；这可能导致无法修复的“空间不足”。
  • 讨论指出文件系统是关键基础设施；一些人认为对生产软件来说，“不要使用功能 X”是不可接受的。
  • 链接文章中的竞态条件 bug 被认为在实践中非常罕见，但它引发了关于样本量（例如 100 机器小时）究竟能证明什么的争论。

使用场景与替代方案

  • 许多人选择 ext4 或 XFS，因为它们行为“非常稳”，更适合数据库工作负载；据说大多数数据库都更偏好 XFS。
  • 一些人在 Btrfs 或 ZFS 上运行数据库（PostgreSQL/MySQL 副本、RocksDB），通常是为了压缩和快照，并接受 CoW 开销。
  • Synology 等 NAS 厂商主要是在经典 RAID 之上使用 Btrfs，而避免使用 Btrfs 的原生 RAID 功能。

快照、备份与工具

  • Btrfs 快照以及 snapper/btrbk 等工具因便于回滚和快速备份而受到称赞，尤其适用于滚动发行版。
  • 有些人希望在 WSL2 中也能有类似 Btrfs 的快照功能；当前的替代方案包括 LVM、dm-snapshot，或未来的机制如 blksnap。

原地转换与预期

  • 一些人认为就地 ext→Btrfs 转换本质上是有风险的；另一些人则认为，只要有文档并得到支持，它就应该是可靠的。
  • 更广泛的观点是：对很多人来说，文件系统必须是“格式化、挂载、忘掉”，与应用失败相比，Bug 是不可容忍的。