2025 年秋天,Linux 社区发生了一件引发广泛讨论的事情:bcachefs 从主线内核被移除,转为通过 DKMS 以外部维护模块的形式提供。对许多关注现代文件系统演进的工程师和运维人员来说,这既是一次技术选择,也是社区治理与信任的考验。本文将系统梳理该决定的来龙去脉,解析技术细节与风险,评估对用户与发行版的现实影响,并给出切实可行的应对建议。 背景与事情经过 Bcachefs 自早期开发以来就以高性能、多设备支持和丰富功能著称。为了在主线内核中运行,开发者曾对内核若干子系统作出适配,为文件系统功能提供必要的接口。进入内核主线后,社区和维护者对其"实验"或"非稳定"状态有明确标注。
到了 Linux 6.17,维护者将 bcachefs 标记为"外部维护(externally maintained)"。随后的 6.18 合并决定中,Linus Torvalds 最终将 bcachefs 从内核树移除,理由在于它现在以 DKMS 模块形式存在,内核内的代码会变得陈旧且容易引发版本混淆。该决定并非一夜之间做出,而是经过了长期的公开讨论与私下沟通。 关键技术点:为什么移除会带来连锁反应 文件系统进入主线内核的过程并不只是把源码放进去那么简单。很多文件系统需要与内核中其他组件协同,例如 VFS、内存管理、XArray、各种锁与数据结构等。为支持 bcachefs,曾经有一些内核子系统的变化被合并,这些变化不再依赖 bcachefs 特殊逻辑就能独立存在。
然而当 bcachefs 自身被移出内核树后,会出现两个主要风险。 第一个风险是接口或导出符号被修改或移除的可能性。内核维护者会定期清理未被内核内部其他组件使用的接口。若某些函数或内部实现只为 bcachefs 提供服务而没有任何内核内"用户",维护者可能选择移除或重构这些接口,导致 DKMS 模块在未来某个内核版本上无法构建或运行。一个具体现象是某些符号不再导出,或像 start_removing_user_path_at() 这样的接口重命名或删除。第二个风险来自于内核向外部模块暴露的承诺和稳定性问题。
当模块以 DKMS 形式存在时,模块维护者需要不断适配内核 API 的变化,若内核演化速度快且不为外部模块提供兼容层,会出现频繁"追着内核跑"的成本。 为何 Linus 与内核社区会支持移除 从内核治理的角度看,主线内核倾向于包含能够长期维护、与内核设计哲学相一致的代码。实验性或频繁需要紧急修复的代码被视为不适合长期驻留在内核树中。一方面,内核合并后需要有人持续负责代码质量、回归测试、安全审查以及在 ABI/内核 API 变动时的协调。另一方面,内核社区普遍反对以迎合单个外部项目而修改内核内部接口或导出额外符号的做法。若一个模块可以通过 DKMS 安装并在用户空间和发行版层面维护,那么将其从内核树移出能够减少主树的维护负担和未来的"遗产包袱"。
然而,决定背后也有社交与沟通因素。社区讨论中多次出现关于行为和沟通方式的争议,这些非技术因素在治理决策中有时候会被放大,进而影响技术走向。无论如何,本次移除具有深刻的技术与社会双重意义。 对用户和发行版的直接影响 对于使用 bcachefs 的个人用户和组织而言,最直接的影响是内核升级路径被复杂化。许多用户曾依赖主线内核提供的内建文件系统,以便与系统升级保持一致。现在 bcachefs 成为 DKMS 模块后,常见的影响包括内核升级后模块无法立即构建、需要等待模块作者发布兼容补丁、或者需要发行版在其内核中打补丁以保留兼容。
在一些案例里,用户在升级到新内核后发现无法挂载原有 bcachefs 卷,从而引发数据可用性担忧。 对于发行版维护者而言,选择变得更为复杂。发行版可以采取多种策略:继续给内核打补丁以保留 bcachefs,为 DKMS 打包并随内核更新提供兼容模块,或者建议用户迁移到其他已稳定的文件系统。每种做法都有成本与风险。若发行版选择 upstream 路线,即不替用户维持额外补丁,那些依赖 bcachefs 的用户需要自行通过 DKMS 或第三方源来安装模块。 对文件系统生态的长期影响 Bcachefs 被移出主线内核对文件系统生态并非单向负面影响。
短期内,可能会促使 bcachefs 社区建立更完善的发布、测试与回滚机制,强化 DKMS 包装与自动化兼容测试。长期来看,若 bcachefs 开发团队能将必要的内核补丁逐步转化为通用且能被主流内核接受的接口改变,则有希望重新争取回归。 然而也有潜在的恶果。如果相关内核改动因为失去内核内用户而被移除,其他外部模块也可能面临相同命运,这会削弱外部模块的长期可维护性,进而影响到 Linux 生态中以模块化方式发展的项目。社区如何在不牺牲内核整洁性的前提下支持健康的外部模块生态,是一个持续调和的命题。 技术应对策略与实操建议 对个人用户与系统管理员,最重要的是做好升级与备份准备。
升级内核前应先在测试环境中验证 DKMS 模块能否编译并成功加载。如果 bcachefs 用于关键数据,强烈建议在升级前创建完整备份,并准备在必要时回滚内核或使用旧内核启动盘进行恢复。此外,可以在发行版仓库中寻找由维护者打包的 bcachefs DKMS 模块,优先采用被社区验证过的版本。若发行版提供了长期支持的内核分支且包含对 bcachefs 的兼容补丁,部署到生产环境可能是最稳妥的选择。 对 bcachefs 项目维护者,有几条可行路径。第一,继续通过 DKMS 发布,并建设完善的自动化测试矩阵,覆盖多个内核版本,及时发现因内核变动导致的编译或运行时错误。
第二,努力将对内核的必要改动以更通用的方式提出,争取将关键改进并入内核公共子系统,从而减少对专用接口的依赖。第三,为常见的内核不兼容问题提供兼容层或移植工具,将模块设计为在不同内核版本间具备降级或替代实现。第四,积极与内核子系统维护者沟通,寻求能兼顾主线内核原则与 bcachefs 需求的折中方案。 对发行版维护者的建议是明确自己的立场并向用户传达兼容策略。发行版可以在包管理与安装流程中把 bcachefs DKMS 模块作为可选项,并在内核升级过程中加入自动化测试以检测模块兼容性。若有足够资源,发行版可以为受支持的内核版本维护针对性的补丁树,确保关键用户不会在每次内核升级后遭遇中断。
社区与治理层面的思考 Bcachefs 从主线内核移除的事件再次提醒我们,技术决策背后往往交织着社区治理、沟通方式与信任问题。一个技术项目要长期留在主线内核,需要的不仅是高质量代码,还需要良好的维护承诺、清晰的回归测试策略以及与其他子系统维护者的合作关系。对外的沟通风格、回应问题的态度以及处理社区反馈的能力,都会对最终能否继续留在内核树产生影响。 这次事件也提出了更广泛的问题:如何平衡内核主线的洁净与外部模块创新的空间。主线内核不可能承担所有实验性的变化,但同时也应当为那些具有明显价值且能够长期维护的项目提供可行的上游路径。建立更透明的评估机制、为外部模块提供有条件的稳定 API 或兼容策略,可能是未来改进的方向。
如何评估是否继续使用 bcachefs 或迁移到其他文件系统 选择文件系统应基于风险容忍度、功能需求与维护能力。如果对数据完整性和长期稳定性有极高要求,并且不希望依赖非标准模块,那么选用长期稳定支持的文件系统如 ext4 或 XFS 可能更为稳妥。如果需要高级功能如数据完整性检查、多设备缓存层次或高效的写时复制,且能够接受在某些升级窗口内做额外维护,那么继续使用 bcachefs 并建立严格的测试与备份流程会是合理的选择。对于考虑 ZFS 的组织,需要额外留意许可证与内核符号访问问题;ZFS 社区的经验表明,非 GPL 模块在与内核交互时会面临特殊挑战,但通过稳健的维护策略也能在生产环境中得到广泛应用。 结语与展望 Bcachefs 被移出主线内核并不是一个单纯技术上的胜负,而是 Linux 生态在快速演化阶段的一次结构性调整。对用户而言,这意味着在系统升级与数据保护方面需要更多谨慎与主动防护。
对 bcachefs 项目而言,这是一次从社区与技术两方面反思、加强测试与沟通的机会。对整个内核社区而言,这是一次关于如何在主线内核与外部创新之间找到平衡的讨论契机。 未来的走向有几种可能。若 bcachefs 团队能够通过改进发布流程、增强与内核维护者的合作并提出更通用的内核改进建议,bcachefs 有望在未来以更稳定的形式重返主线。若维护以 DKMS 为主并且生态逐渐成熟,它也可能演化为由发行版或第三方长期维护的模块化解决方案。无论路径如何,关键在于技术质量与社区治理的双重建设。
对当前使用 bcachefs 的人来说,最现实的建议是:评估风险、强化备份、在升级前进行测试、利用发行版与社区提供的 DKMS 包,并关注 bcachefs 社区的兼容性公告。通过技术手段和规范流程,可以把因内核生态变化带来的不确定性降到最低。对于整个 Linux 社区而言,让创新与稳定并行,而非互相对立,才是长期健康发展的方向。 。
