投稿或寻求报道 | zhanghy@csdn.net
一套被称为“下一代”的文件系统，刚被 Linux 主线接受一年半，如今又濒临出局边缘。
前一阵子，在 Linux 内核开发社区中，一场围绕 Bcachefs 的“流程之争”愈演愈烈——Linux 之父 Linus Torvalds 再次对 Bcachefs 项目的主要维护者 Kent Overstreet 表达强烈不满，原因是其在内核 6.16 的候选版本（RC）阶段提交了带有新功能的补丁，这严重违背了 Linux 长期以来的开发规则。
经过持续一周的争议后，Linus Torvalds 最终还是选择将那段代码合并，但也对 Bcachefs 给出了一个颇具警示意味的表态：“事情到了这个地步，我都不想再参与了。我们唯一真正达成一致的，大概就是‘我们已经结束了’。”
雷区引爆：RC 阶段加入新功能？
要说 Bcachefs 是 Linux 社区最具争议的文件系统之一，恐怕没人会反对。
这个项目由 KentOverstreet 于 2015 年发布，初衷是打造一个兼具 Btrfs 灵活性与 ext4 稳定性的现代文件系统，具备写时复制（COW）、快照、压缩、校验等功能，被视作 Btrfs 的有力替代者。过去十年，它一直以外部模块的形式活跃于社区，直到 2024 年初，它才终于正式被纳入 Linux 6.7 主线内核。
但 Bcachefs 的这段主线之路，并不平坦。
Bcachefs 的开发过程向来“风格鲜明”。Kent Overstreet 既是主力代码撰写者，也是唯一的核心维护者。他以高强度迭代、极度关注用户 Bug 反馈著称，几乎亲力亲为地处理所有问题。正因为如此，Bcachefs 很快积累了一批忠实用户——尤其是对 Btrfs 曾“翻车”过的开发者来说。
但在 Linus Torvalds眼里，这样的开发方式，也常常意味着流程不合规、代码管理混乱。
本次争议的导火索来自一个看似不大的功能补丁：journal_rewind。
这个功能的设计目的是允许文件系统回滚到较早的状态点，用于极端情况下的数据恢复。虽然该功能尚未完善，Kent Overstreet 也承认目前还存在“较大限制”，但他仍希望能尽早推送到主线，避免用户在数据丢失时束手无策。
于是，Kent Overstreet 便将这个新功能补丁与一些 Bug 的修复补丁一起打包，提交至 Linux 6.16-rc3 候选阶段——问题就在于此。
根据 Linux 内核的开发规范，新功能代码只能在合并窗口（merge window）期间提交，而 Linux 6.16 的合并窗口早已经关闭，在 RC 阶段只接受 Bug 修复（pure fixes）。但 Bcachefs 团队试图以“提升数据安全”为由，为新特性开绿灯，希望绕过这条铁律。
意料之中，针对这一提交，Linus Torvalds 直言不讳地表达了不满：“你似乎又忘了‘合并窗口’存在的意义。我们不能因为发现新问题，就在 RC 阶段添加新功能。”此外，他还补充说，“所有使用 Bcachefs 的人都应该知道，它只是个实验性文件系统。”
值得一提的是，除了 Linus Torvalds，一向以稳健著称的 ext4 维护者 Theodore Ts'o 也发声对 Kent Overstreet 表达不满。他指出，在 RC 阶段引入如此重大的变更，尤其是在文件系统这种高度依赖数据一致性与稳定性的核心模块中，风险极高、极易埋雷。Theodore 强调，内核社区早已就“RC 阶段只能提交 Bug 修复”这一原则达成广泛共识，而 Linus 的职责正是维护这条底线——言下之意很明确：没人可以例外，流程不是儿戏。
Kent 不服：“规则不是用来死守的”
面对 Linus Torvalds 的指责，Kent Overstreet并未示弱。他在邮件中长篇回应，核心观点只有一个：规则应以用户利益为先，而非无脑死守。
Kent Overstreet 指出，文件系统与 Linux 内核其他子模块不同，其设计缺陷往往会在用户生产环境中造成不可逆损失：“其他模块崩了大不了重启，但文件系统出问题可能就是数据全无。”
他进一步解释道，此次的 journal_rewind 只是一段约 70 行的小补丁，本质就是让日志回滚时倒序执行覆盖操作而非增量更新，主要用来抢救可能丢失的数据。
有开发者提出建议：“要么等到下一个合并窗口期再合并？”但 Kent Overstreet 提到，很多用户根本不具备从 Git 编译内核的能力，而 RC 版本在各大发行版中是自动打包的：“我们不想再等 3 个月，这可能是用户在数据崩溃和恢复之间的关键差异。”
对于社区反复强调“合并窗口就是规则”的观点，Kent Overstreet也没有退让：“规矩当然有存在的必要，但有时候，也需要判断力和常识。”
同时，他还强调自己才是 Bcachefs 的负责人，每天处理来自用户的 Bug 报告、跟踪哪些东西正常哪些有问题的人是他，不是别人，也不是 Linus。“ 这种对每一行补丁的‘微管理’行为，只是在制造冲突和戏剧性。”
Linus 沉默合并，但留下“分手预警”
这场争议持续了近一周，最终以 Linus Torvalds 将这段代码合并作为收尾。
上周四晚上，或许是考虑到这项功能对数据恢复具有潜在价值，Linus Torvalds 在没有任何额外说明的情况下，还是把Bcachefs 合并请求整合进了主线内核。
不过，在另一封与 Bcachefs 相关的邮件中，Linus Torvalds写道：
“我已经合并了这部分内容，但正如我们上次讨论的那样，我认为我们会在 Linux 6.17 的合并窗口‘分道扬镳’。你已经明确表示，我连对任何 Bug 修复提出质疑的资格都没有，只能什么都合并。坦白讲，在这种情况下，我真的不太愿意继续参与。而我们唯一真正达成一致的，大概就是——‘我们已经结束了’。”
至于这对 Bcachefs意味着什么，还有待观察。Linus Torvalds是否会直接将 Bcachefs 踢出主线？还是只是会更严格地执行“候选阶段只允许修复，不得添加新功能”的内核开发规范？现在还无法确定。
面对 Linus Torvalds 和 Kent Overstreet 之间的这场争论，社区内的开发者也演变成了两个阵营：
●支持 Linus Torvalds：“我没有和 Linus 共事过，所以无法评论他的语气。但与其说‘我不喜欢现在的做法’，不如在内核内部聚集支持者，共同商讨出一个具体的解决方案，明确需要修改哪些内容以及如何修改，并最终制定一份正式的提案，列出所有支持者的名字，这样会更有用。如果我是管理层，有人跟我说‘我不知道具体怎么做，但可以改一些东西’，我只会觉得他们是在挑事。”
●支持 Kent Overstreet：“我实在不明白 Linus 生气的点是什么。Kent 说得对，Linus 有时候真是想当然，而不是根据具体情况来考虑问题。Kent 的 Bcachefs实际上是第一个添加到 Linux 内核的、具有意义重大的新功能，却因为“流程”而受到如此多的阻力。过去Linux 内核是如何引入其他新功能的？如果按照这个新流程，添加一个新文件系统需要的时间可能是几十年，而不是几年。”
那么，你对于此次事件的看法又是什么呢？
参考链接：https://www.phoronix.com/news/Bcachefs-One-Week-Later-Merge
