导读：Linux Kernel 6.16 可能是最后一个采用新式磁盘格式的版本。

背景

话说近日，技术极客的巨头们再次发生严重地冲突。

Linux “内核国王” Linus Torvalds 发出警告说：“对于bcachefs，我认为我们将从内核 6.17 开始，和它分道扬镳。

关于下一代 bcachefs 文件系统在该系统内核的闹剧持续进展，Torvalds暂时接受了代码，但他添加了一个令所有内核开发者警醒的通告：

“我已经撤回了这一点。根据该讨论，我认为我们将在 6.17 合并窗口中分道扬镳。

你说得很清楚，我甚至不能质疑任何错误修复，我应该把所有东西都撤下来。

老实说，在那个时候，我感觉参与其中真的不太舒服，而且在那次讨论中，我们双方唯一真正达成一致的事情似乎就是‘结束了’”。

关于Bcachefs

Bcachefs 是 Linux 系统中的一个新兴写时复制（COW）文件系统，由 Kent Overstreet 领衔开发。Kent 的先前杰作是已集成到内核多年的块缓存层工具 Bcache，可以视为 Bcachefs 的“先驱”。

实际上，早期的 Bcachefs 直接重用了大约 80% 的 Bcache 代码。

Kent 在 2015 年宣布开始研发 Bcachefs；经过近十年的精心打磨，Bcachefs 在 2024 年初的 Linux 6.7 版本中被纳入内核主线。Bcachefs 承诺将融合 ZFS、Btrfs 等现代文件系统的特性与 ext4、XFS 等传统文件系统的性能。然而，理想虽然美好，现实却充满挑战，Bcachefs 自从加入主线以来，问题频发。

Kent，作为一名开发者，在社区中的声誉并不理想，甚至可以说饱受争议。在最近的事件发生之前，他因在邮件列表中对其他开发者言辞激烈、态度粗鲁而受到批评。

例如，在2024年底，由于一次激烈的争论，他被Linus禁止参与当时的6.13内核开发。许多内核领域的资深人士对Kent的评价是“技术能力出众，但合作性差”——他常常自行其是，不愿意顺应或配合他人的工作方式。这种性格特点为此次冲突埋下了伏笔。

事情来龙去脉

事情的导火索发生在 Linux 6.16-rc 阶段。按照惯例，一旦内核合并窗口（merge window）关闭，随后的 rc 版本周期仅限于错误修复，不再接纳新功能。然而，Kent 在 6.16-rc3 发布后不久提交了一个通知，请求合并一个名为“journal-rewind”的新功能补丁。

该补丁旨在改进 Bcachefs 文件系统修复工具，解决用户报告的数据损坏问题。但这个补丁影响范围广泛，涉及超过一千行代码的改动，严格来说属于新特性——这显然违反了 rc 阶段“仅修复 Bug，不添加新功能”的规则。

Linux 版本命名方案和开发流程 · EmbeddedSystemLinus 对此表示强烈不满，在邮件中立即指出：“看来你又忘记了合并窗口的初衷。不能因为你发现了其他 Bug，就趁机添加新特性。”简而言之，Linus 认为 Kent 不遵守规则，挑战了内核开发流程的共识。

面对 Linus 的指责，Kent 并未认错或停止，反而坚持己见，认为“journal-rewind”并非普通新功能，而是解决关键问题所必需的，认为规则不应过于死板。更令人震惊的是，两人在邮件往来中言辞愈发激烈。尽管 Linus 以脾气火爆著称，这次却是 Kent 首先使用了粗鲁的语言。根据社区整理的邮件记录，Kent 在回复 Linus 时开篇就带有挑衅意味地写道：

Kent：“Linus，我并不是说你不能对 Bcachefs 发表意见，没这意思，实际上我挺愿意与你合作——只要你别那么难以相处。但有时候你确实很疯狂，而且经常如此……”

Kent 直接指责 Linus “在某些时候像个混蛋（Dick 直译为生殖器）一样难以应付”。Kent 继续抱怨 Linus 对他过于挑剔苛刻，并举了一个例子来证明：当初 Bcachefs 要合并到内核时，有其他文件系统维护者私下对 Kent 鼓励道“太好了，我们终于有了一个敢于正面挑战 Linus 的文件系统维护者！” Kent 紧接着表态：“我可不想最终也陷入那种境地。对于用户数据的完整性和必要的补丁修复，我绝不会妥协，这方面我没有任何幽默感（开不得玩笑）。”他的立场很明确：优先保证用户数据的安全，Bug 必须修复，必要时应破例，不应受流程规定的限制。

Kent 明确表示他并非无视 Linus 的建议，而是希望 Linus “能稍微缓和一些”，不要每次 Pull Request 都变成一场大争论：“正如我所说——我一直希望你不要总是纠结于 Pull Request 阶段，非要把所有争论都放到合并请求中来解决。”他甚至劝告 Linus：“你的建议确实都很棒，你也很聪明敏锐。我们不争执的时候，一起解决问题、做正事其实很愉快——我非常享受这一点。但你也需要理解别人肩上的压力，不要只顾自己的想法。” 一方面，他毫不客气地回击，甚至使用了“消停点”“难以相处”等粗鲁言辞；但另一方面，他也承认 Linus 技术一流，“和你一起工作很愉快”，话里话外希望双方能减少冲突、继续合作。

不幸的是，Linus 的态度已经彻底被激怒。在与 Kent 的争执期间，Linus 勉强接受了包含争议功能的 Pull Request（暂时合并了“journal-rewind”补丁），但随即发出严厉警告：“补丁我拉了，但根据我们讨论的情况来看，6.17 合并窗口时，我们可能就要分道扬镳了。你已经明确表示我今后对你的补丁不应再有任何疑问，反正你提交的东西我就得全盘接受。说实话，在那种情况下，我完全看不出参与其中还有什么意义。我们俩似乎唯一达成的共识就是——‘到此为止’（‘we're done’）——Linus 已经决定不再参与 Bcachefs 的维护，这意味着他打算将其从内核主线中移除。”

毕竟，作为掌舵者，如果 Linus 对某个子系统（尤其是新加入主线的试验性文件系统）失去信心，他完全可以在下一个版本的合并窗口拒绝任何来自该维护者的代码提交。实际上，一旦 Linus 放弃，其他高级维护者也不会轻易介入，一个由新人驱动的文件系统可能会因此被“搁置”。

值得注意的是，在这场冲突中，不仅 Linus 一人提出质疑。著名的 ext4 文件系统维护者 Theodore Ts'o 也公开批评了 Kent 的做法，指出在 rc 阶段引入如此重大的更改极易引发问题，尤其是对于涉及磁盘数据安全的文件系统模块更应谨慎。他强调内核社区长期以来对合并窗口规则已有共识，而 Linus 的职责就是执行这些规则。换句话说，没有人可以例外。面对各方压力，Kent 依然强调 Bcachefs 的特殊情况和用户迫切需要修复的问题，希望大家能“通融”。但这次 Linus 并未让步。随着 6.16-rc 系列进入尾声，Linus 的言辞中透露出一个明确的信息：“Bcachefs 就别留在我这儿添乱了”。

网友观点

Linux 内核是世界上最大的自由/开源软件 (FOSS) 项目，这部分当归功于 Torvalds 本人的强力掌控。尽管没有正式的文档和描述，但 Linux 内核确实已经已经有一个固定的开发流程。

如同 Linux 本身一样，这个过程也正随着时间的推移而发展。每当内核发布新的版本号时，Torvalds 就会开始下一个版本的开发。正如Linus前几年前所描述，他开启了所谓的“合并窗口”。

在此期间，开发人员提交新代码以便纳入到内核。随后会发布一系列正在进行的测试版本，版本号末尾带有rc （代表“候选版本”），它会如此说：目前，我们使用的是6.16-rc4 版本。在此期间，代码提交（用 Git 修订控制系统的术语来说，即“拉取请求”）会继续进行，但这些提交仅用于修复错误。

这次，bcachefs 维护者 Kent提交了一个包含一些新功能的 PR。这在内核中可是个大忌：RC 阶段是用来修复合并窗口期间提交的内容的。Torvalds 对此很是不满意，但 Overstreet 一如既往地没有退缩，而是维护了这项变更。

有人认为规则就是规则，Bcachefs 并不是什么特殊的存在，Kent 不应期望 Linus 为他破例。他们指出，其他文件系统的维护者在开发新特性时都严格遵守规则，没有人像 Kent 那样提出特殊要求。这类观点支持 Linus 的立场：流程不能因为个人能力突出或自认为特殊而被忽视，否则将后患无穷。

也有网友在回顾邮件线程后直言不讳：Kent 总是难以接受他人的拒绝，总是试图为自己辩解。在整个讨论中，Linus 只要求一个“仅包含修复的 Pull Request”，但 Kent 却不愿接受，似乎认为自己特殊到可以不受规则约束。尽管 Kent 技术能力出众，但他似乎难以与他人合作。这番评论建议，鉴于 Kent 的个性，或许他应该找一个协同维护者来处理提交事宜，让他自己专注于编写代码。

一些网友质疑 Bcachefs 是否真的已经成熟到可以并入主线。有评论认为，从这次事件来看，Bcachefs 可能还未准备好融入内核生态，或许应该继续在主线外进行打磨。毕竟，如果连基本的开发流程都无法顺利配合，又怎能期待长期的维护呢？在他们看来，现在将 Bcachefs 排除在主线之外或许并非坏事——等到代码和维护都变得更加成熟稳定时，再考虑并入也不迟。

更多人则通过实际行动表达了对 Bcachefs 开发现状的不信任。一位网友戏谑地说：“行吧，我还是继续用 ext4”——言下之意是经过这次事件的观察，他已完全失去了尝试 Bcachefs 的勇气。还有人附和：“我们相信 Ted T（Theodore Ts'o）的就够了”——他们支持稳定可靠的 ext4，不愿尝试这些新事物。甚至有网友尖锐地批评：“在我看来，连基本规则都不遵守的开发者不能算是‘人才’，无论他多么有才华，我也不敢使用他的软件”。可见，这次事件已经让许多原本观望的用户对 Bcachefs 产生了疑虑。

结语

但是即使发生这种情况，也不意味着bcachefs 项目的终结。事实上，正如 LWN 评论中所讨论的那样，还有几种潜在的发展方向。它可以作为外部开发继续进行。使用它有多种可能性。

比如，想要尝试的开发者还可以构建自己的定制修改版内核。

另一种方案是，可以构建一个使用FUSE 子系统的版本，该子系统允许文件系统代码在内核之外运行。这种方法证明可行，并且近年来已进行了优化，但速度比内核代码要慢一些。或者，可以在内核更新时按需构建代码：有一个标准工具可以实现这一目标，它名叫 DKMS，运行 Nvidia 显示驱动程序的用户可以通过它获取这些代码。

或者，这两个天才级程序员之间的争端会忽然得到解决……

作者：行动中的大雄