Bcachefs被移出内核主线：转向DKMS及其影响

引言

经过多年的争论和开发，bcachefs——一个曾并入Linux内核的现代写时复制文件系统——正被移出内核主线。自内核6.17起，内核内实现已被移除，未来使用预计将通过树外DKMS模块。这标志着bcachefs项目的一个转折点，引发了关于其稳定性、采用率以及与内核开发社区关系的疑问。

什么是Bcachefs？

在深入探讨移除过程之前，我们先回顾一下bcachefs是什么以及它为何引起关注。

• 起源与目标：由Kent Overstreet开发，bcachefs源于早期bcache项目（块设备缓存层）的想法。它旨在构建一个功能齐全的通用文件系统，将性能、可靠性和现代特性（快照、压缩、加密）结合在一个连贯的设计中。
• 主线包含：经过漫长的审查和孵化期后，Bcachefs被合并到主线内核版本6.7（2024年1月发布）中。
• “实验性”分类：即使成为内核的一部分，bcachefs始终带有关于其成熟度和稳定性的免责声明——并不一定推荐所有用户在生产中使用。

导致移除的原因

bcachefs从内核中移除并非突然，而是开发实践、补丁接受时机和上游政策规范之间紧张关系的 culmination。

6.17中的“外部维护”状态

在内核6.17的准备过程中，维护者将bcachefs标记为“外部维护”。尽管代码仍然存在，但这一变化意味着上游将不再接受内核树内的新补丁或更新。 这一举措允许了一个过渡期。代码在树内被“冻结”，以避免立即破坏现有系统，同时为未来的移除做准备。

分歧与最后一根稻草：“journal_rewind”补丁

决定性的 breakdown 发生在6.16 / 6.17开发周期期间。bcachefs负责人在合并窗口后期提交了一个主要补丁（称为journal_rewind）——这是一个新增功能，而不仅仅是错误修复。这一举动违背了内核社区规范，社区期望新功能在合并窗口之前或更早的开发周期中提交。 Linus Torvalds公开表达了沮丧，认为bcachefs树越来越像一个开发沙箱，而不是与上游政策保持一致。他抱怨说开发工作是在发布候选版本期间进行的，而不是在此之前，这使得维护稳定性变得困难。 最终，Torvalds宣布他不再希望参与这种动态，并在6.17合并窗口中，bcachefs将被移除。

最终移除

随着Linux内核版本6.18的发布，核心bcachefs代码被正式剥离。给出的理由是内核内副本已经过时，继续存在只会造成版本混淆。 此次移除从内核源代码树中删除了大约117,000行代码。

现状：DKMS与树外方法

移除之后，bcachefs项目转向作为DKMS模块（动态内核模块支持）发布，这意味着它存在于内核树之外，可以根据需要为各种内核编译和安装。

关于这一转变的一些关键点：

• 该模块设计用于与内核版本6.16及更新版本兼容，并计划跟踪内核预发布版本以提供模块支持。
• 用户仍然可以将bcachefs作为根文件系统运行，前提是initramfs包含DKMS模块以便在启动过程早期加载。
• 由于策略或安全原因不允许发布树外模块的发行版可能会限制bcachefs的可用性；一些发行版通过社区存储库（例如Debian / Ubuntu APT仓库）或Fedora的COPR提供它。
• 性能比较表明，在某些基准测试中，DKMS版本可能比树内版本表现更好（Phoronix报告了改进）。

影响与风险

bcachefs从主线移除影响了多个利益相关者：用户、发行版维护者和bcachefs项目本身。

对用户和部署的影响

• 依赖bcachefs的用户必须适应：他们需要在内核升级时安装和维护DKMS模块。
• 在某些发行版中，这意味着更多的手动步骤或依赖社区打包。
• 如果模块构建失败或无法与未来的内核更改保持兼容，则存在风险。
• 一些内核级优化或钩子可能更难通过树外模块维护（因为树内代码可以更容易地适应最深的集成）。

对发行版的影响

• 一些发行版（尤其是那些具有限制性模块策略的发行版）可能会放弃上游支持或默认排除bcachefs。
• 发行版必须决定是否打包DKMS、提供用户说明，或在稳定内核中黑名单其使用。

对bcachefs维护与开发的影响

• 与内核解耦提供了更多自由：项目可以按照自己的时间表发布更新，而不受内核合并周期的束缚。
• 但它也失去了树内文件系统所具有的可见性和集成优势。
• 有人推测，缺乏内核内用户引用可能导致相关内部API或辅助函数随时间推移被移除（即，仅由bcachefs使用的代码可能被考虑移除）。
• 项目必须保持强大的测试、跨内核版本的兼容性以及响应能力以避免回归。

移除的社区反响

社区反应不一。一些人同情bcachefs的开发方法与内核更高级别政策不太一致。另一些人则担心失去一个有前途的文件系统，该文件系统旨在推动其他文件系统所缺乏的功能。 批评者警告说，未来的内核可能会移除bcachefs所依赖的内部API——因为没有树内用户保留——从而进一步削弱树外模块。 一些人持乐观态度：DKMS路径为项目提供了自主权，并可能允许更快的迭代和修复，而无需等待内核合并。

用户现在应该做什么

如果您正在使用或计划使用bcachefs：

• 检查您当前的内核是否仍包含bcachefs，或者是否已经超过6.17/6.18。
• 准备安装DKMS版本（查找发行版存储库或通过社区包中的“bcachefs-tools”包或模块源）。
• 确保您的initramfs包含该模块，以便系统可以从bcachefs启动。
• 在每个内核升级周期中监控兼容性——特别是对于您依赖的构建或API。
• 关注发行版的支持决策——一些发行版可能会移除或限制树外模块。
• 对于关键任务设置，如果bcachefs在您的环境中变得不可行，请考虑备用文件系统或迁移路径。

结论

bcachefs从Linux内核主线中移除标志着一个转折点。对于那些希望有一个完全集成的先进文件系统的人来说，这可能感觉像是一种倒退，但此举也解放了项目，使其能够按照自己的条件发展。DKMS模型引入了灵活性，但也带来了关于兼容性、发行版支持和长期集成的风险。 尚待观察的是bcachefs能否在内核核心之外保持势头——提供稳定、高性能和经过充分测试的功能。对于用户和Linux发行版来说，适应新现实至关重要。