2025 年下半年,Linux 社区迎来一个备受关注的决定:Linus Torvalds 在 6.18 合并窗口中将 Bcachefs 相关代码从主线内核中移除。这个动作并非完全出人意料 - - 在上一个版本 6.17 中,Bcachefs 已被标记为『externally maintained』,但代码仍保留在树中以便平滑过渡。到了 6.18,Linus 直接剔除了这部分代码,并在提交记录中解释道,Bcachefs 已经变成了 DKMS 模块,内核树里的代码已经变得陈旧,继续保留反而会导致版本混淆。与此同时,约 117k 行代码随之被移除,这对依赖 Bcachefs 的用户和发行版带来了明显影响。对任何关心存储、内核模块管理或企业部署的读者,理解这项变更的技术细节与可行应对策略非常重要。以下内容将围绕变更背景、具体影响、如何继续使用 Bcachefs、替代方案与长期建议展开详尽讲解,便于实际操作与决策。
为什么会发生移除 从内核维护流程来看,文件系统进入主线必须满足长期维护、代码质量与社区支持等多重条件。标记为『externally maintained』通常意味着维护责任主要由外部开发者承担,主线内核对其后续改动的直接接受会放缓。Bcachefs 在功能设计上目标雄心勃勃,旨在兼顾性能与现代文件系统特性,但其代码在内核树中长期保持外部维护态势,会产生若干现实问题。内核 API 和内部 ABI 随内核版本频繁演进,若模块不随主线同步更新,内核中保留旧代码会造成版本混淆与维护负担。Linus 的决定本质上是为了减少主线树中的陈旧代码,明确模块应当以 DKMS 或发行版补丁形式维护,而不是长期占据内核主树。 对用户和运维的直接影响 移除意味着主线内核从 6.18 开始不再包含可直接使用的 Bcachefs 实现。
对使用 Bcachefs 做为根文件系统或关键数据存储的系统,这带来两类主要影响。第一是引导与启动风险。如果系统依赖内核自带的 Bcachefs 模块,而用户升级到 6.18 及以后版本,系统可能无法加载该文件系统,从而无法正常启动。第二是运维与兼容问题。Bcachefs 作为外部模块,必须通过 DKMS 或由发行版提供的 out-of-tree 包来匹配当前内核。否则在内核升级时会出现模块编译失败或 ABI 不匹配的情况。
DKMS 是什么以及为什么成为首选路径 DKMS(Dynamic Kernel Module Support)允许第三方内核模块在内核升级时自动重建与安装。将 Bcachefs 转为 DKMS 模块意味着源码和构建脚本由项目维护,安装在系统后,DKMS 会在每次内核安装或更新后尝试为新内核编译模块,从而维持模块与内核版本的一致性。Linus 在提交信息中提到这一点,也是移除内核代码的直接理由:Bcachefs 模块如今作为 DKMS 更合适,主线内核保留旧版本反而造成混乱。 如何为现有系统做好迁移与保护 首先评估当前系统是否依赖 Bcachefs 作为根文件系统或关键分区。如果是,升级内核前必须保证有可用的回滚计划。最稳妥的做法是先将系统备份并测试迁移流程。
其次,准备 DKMS 环境并验证模块能否成功构建。常见步骤包括安装 DKMS、安装对应内核的开发头文件并从官方或可信仓库获取 Bcachefs 源代码。构建成功后,需要在 initramfs 中包含生成的模块,以确保系统在引导阶段能正确加载 Bcachefs。许多发行版在内核更新时会自动重建 initramfs,但如果使用自定义内核或非标准流程,务必手动验证。若系统启用了 Secure Boot,还需为外部模块签名或采用合适的签名和 MOK 注册流程,否则模块可能被内核拒绝加载。 再次,测试升级过程。
推荐在非生产环境或测试服务器上先运行完整升级流程,从 6.17 升到 6.18 及之后版本,检查 DKMS 模块是否被编译并注入到 initramfs,验证引导与文件系统一致性。任何失败都应在升级生产环境之前修复。 最后,若企业环境对可用性要求极高,评估是否暂时保留在包含 Bcachefs 的稳定内核版本,直到有成熟的发行版打包方案或项目本身稳定可靠地支持 DKMS。退回旧内核或使用发行版长期支持(LTS)内核也是常见的风险缓释措施。 如何构建与部署 Bcachefs DKMS 模块(高层次指导) 准备构建环境并安装必要依赖是关键。确保系统具备 DKMS、内核头文件以及构建工具。
获取 Bcachefs 源代码后,按照项目提供的 DKMS 模式进行注册、构建与安装。构建成功后,检查 /lib/modules/$(uname -r) 下是否存在 bcachefs.ko 并运行 depmod 更新模块依赖。为了引导时能加载模块,更新或重生 initramfs,验证内核能找到并加载该模块。对于使用 UEFI Secure Boot 的系统,需为模块签名或禁用模块签名检查,具体策略应符合企业安全策略。上文只是高层次步骤说明,实际操作应参照项目文档与发行版的最佳实践。 长期维护与社区协作的方式 Bcachefs 作为一个有吸引力的文件系统选项,其长期前景取决于项目能否建立稳定的维护机制并与发行版协作。
维护者需要明确模块的 CI/CD 流程,自动化对多版本内核的编译与测试,并及时响应内核 API 变更。发行版则可以通过打包 DKMS 模块、提供预编译内核模块或与项目合作将特定内核版本的补丁纳入发行版源中,来为用户提供更平滑的体验。 从更宏观的角度看,Linus 的决策反映了内核树向清晰边界和更好维护性的倾斜。保留旧的外部代码容易使主线变得臃肿并引发责任归属不清的情况。将出色但外部维护的功能转移到 DKMS 或发行版打包体系,是一种鼓励外部项目建立良好维护机制的策略。对项目贡献者而言,这既是挑战也是机会:挑战在于必须承担持续适配内核的工作量,机会在于获得独立发展与更灵活发布的自由。
替代文件系统的考量 对于评估迁移的用户,考虑可替代的成熟文件系统是必要的。Btrfs、XFS、EXT4 和 ZFS 各有优缺点。Btrfs 提供了快照、子卷和在线扩展等功能,并且已被多家发行版采用,但在某些场景下性能或稳定性问题仍需评估。ZFS 在数据完整性和快照方面表现优良,但受许可限制,通常作为外部模块或特殊打包方式提供。XFS 和 EXT4 则以稳定和成熟著称,适合对高级功能需求不强但重视稳定性的场景。选择替代方案时,应结合性能基准、数据完整性需求、恢复流程和备份策略做全面评估。
社区反应与未来展望 移除 Bcachefs 代码的消息在社区内引发热议,不同群体的反应各不相同。部分开发者认为这是维护主线内核整洁性与明确责任边界的必要举措,能促使外部项目建立更健全的维护流程;另一方面,部分用户与发行版维护者担心临时适配成本、引导风险以及对现有生产环境的影响。对于 Bcachefs 项目本身而言,转为 DKMS 既是挑战也是常态化发展的机会:通过完善自动化构建、多内核测试矩阵和与发行版的深度协作,项目依然有可能在将来以更稳定、更被接受的形式重回主线或被广泛采纳。 总结与行动建议 Linus Torvalds 从主线内核移除 Bcachefs 代码,是一次为了减少主线陈旧内容与明确维护责任的决策。对个人用户与企业运维而言,关键在于识别是否有依赖并采取相应措施。短期应对包括启用 DKMS、确保 initramfs 包含模块、在测试环境模拟升级路径并准备回滚计划。
中长期建议围绕建立自动化构建与测试、与发行版提高协作、评估并可能迁移至替代文件系统或继续以 DKMS 方式维护。对于关注文件系统创新的社区成员而言,继续关注 Bcachefs 项目的更新、贡献测试用例与协助构建多内核持续集成,将有助于其走向更加稳健的未来。 无论立场如何,这一事件再次提醒我们在采用新兴文件系统与外部内核模块时,必须同时考虑维护策略、升级流程与备份恢复能力。做好前期评估与自动化保证,才是保障生产系统长期稳定运行的关键。 。
