整理 | 屠敏
出品 | CSDN（ID：CSDNnews）
上周，随着 Linus Torvalds 的正式决策，Linux 6.13 版本合并了从内核中删除 ReiserFS 文件系统的补丁，将移除 32.8k 行代码，由此宣告 ReiserFS 正式退出历史舞台。没想到，一个文件系统刚终结，Linux 内核中的另一大文件系统 bcachefs 又出了“乱子”，
bcachefs 首席开发者 Kent Overstreet 于近日发布了一篇名为《Trouble in the kernel》的长文，透露 Linus 不接受他在 Linux 6.13 中提交的 Bcachefs 拉取请求，给出的理由是“CoC（行为准则）委员会存在未解决的问题”。
这一搁置，Overstreet 表示，这导致 Bcachefs 的未来变得不确定，而且很多事情看起来也不太乐观。
但是他自己也觉得委屈，甚至在长文中列举了不少例子，剑指 Linux 文化和工作方式存在一些问题，其中有些人还用别人的职业生涯以此作为威胁，迫使他们遵守规定......
一时的口舌之快，导致所有的合并请求被拒
bcachefs 是一种高性能的 Linux 文件系统，设计用于提供高效的数据存储与访问能力，该文件系统的设计初衷是与 ZFS 或 Btrfs 等现代文件系统竞争，同时在速度和性能方面与 ext4 和 XFS 相媲美。它是由资深开发者 Kent Oberstreet 创建而成，在 Linux 6.7 内核中获得支持。
仔细想想，Linux 6.7 发布至今也还未到一年的时间，为何现如今 Kent Oberstreet 的合并请求会被 Linus 拒绝？
一切或许与他自己的“火爆”脾气有关。
要知道，在 bcachefs 被正式合并到 Linux 内核之前， Kent Oberstreet 就曾与 Linux 内核开发者们就 “Bcachefs 文件系统驱动程序” 在邮件列表展开了激烈讨论，当时气氛也有些剑拔弩张，好在后来 Linus 亲自 Review 代码，并就相关情况发表自己的看法之后，才得以平息这一争论。
然而，Linus 帮得了一次，帮不了每一次。就在今年 9 月，Kent Oberstreet 在一封主题为“bcachefs：请勿使用 PF_MEMALLOC_NORECLAIM”邮件列表中，怒气冲冲地对 SUSE 的开发者 Michal Hocko 说道：
我们已经在另一个邮件线程中讨论过这个问题。我必须说，我不认为返回 NULL 会使有问题的代码变得更好。为什么？因为我们可以预期，有问题的 NOFAIL 用户不会有一个错误检查路径。即使是有效的 NOFAIL 用户也不会有，因为他们知道他们没有不同于无限重试的恢复路径。
你在问我要讨论和理由的链接，对吧？我还在等那个链接呢。
我不是你的助手，不会被指派去搜索传统档案。如果你需要，自己去找。
无论如何，如果你读了那封邮件，甚至尝试理解里面写了什么，而不是立即大喊大叫地回应，你就会注意到我在这里提出了实际的论点。你可以自由地不同意这些论点，并提出你的论点。你却选择了……
> 是的，够了这种疯狂。
所以我认为你不能这样做。再次……
Michal，如果你认为让进程崩溃是可以接受的错误处理替代方案，那么你就不应该编写内核代码。
你一直在强烈地提出一个接一个的糟糕想法，这对那些真正关心编写可靠软件的人是一种侮辱。
你反对的是内核编程的基本原则。
检查一下你的脑子吧。带着这些垃圾滚蛋。
作为一名担任 Linux 内核工程师已有 15 年多的资深维护者，Kent Overstreet 这种说话的方式让很多人不满，甚至这番言论被视为“人身攻击”。
这封邮件引起了 Linux 内核 CoC 委员会 Shuah Khan 的注意，随即要求 Overstreet 不要使用此类过激的语言，并遵守 Linux 社区行为准则。
没过多久，Overstreet 回应说他已经与 Michal 私下协商好了，并把二人讨论的细节抄送给 CoC 委员会。
然而，Shuah Khan 并没有就此罢休，而是要求 Overstreet 针对这一言论公开道歉并保证以后禁止这种不可接受的行为。
Overstreet：拒绝公开道歉
对此，Overstreet 在博文中称，这只是一次技术讨论的失控，当时的情况是：
文件系统领域的开发者最初非常反对 PF_MEMALLOC_NORECLAIM，但在进一步讨论实际影响，以及查看实际的 GFP_NOFAIL 使用和错误处理路径后，他们似乎开始转变态度。
然而，推动回滚的 mm 维护者并不买账，他说这件事已经在幕后讨论中决定了，并且不愿意进行技术讨论；当被要求提供这些讨论的理据时，他提供了一份决定的电子表格，但没有解释原因。
当 mm 维护者表示他希望直接杀死那些错误使用 GFP_NOFAIL 的进程，而不是让它们返回到缺失的错误处理路径时，Overstreet 在气急之下，才会曝出上述那些脏话，他写道——“我不认为这些言论是恶意的，也不是针对个人的。包括我在内的许多人都陷入了技术争论，过于专注于赢得胜利和推进我们的观点，以至于我们忘记退一步来看看更广阔的前景。确实会发生！毕竟，我们都是凡人。”
Overstreet 透露，他事后也收到了包括 Linus 给他发的邮件，大意就是：“相信我，你不想因为是个混蛋而出名，你最好给那位道歉。”
Overstreet 还提到，其实他之前和 Linus 之间也有过拉锯式讨论（比如代码提交时的争论）。回看今年 10 月，Linus 在合并了实验性 Bcachefs 文件系统的最新一轮修复时，直接犀利地回复道：
我真的受够了，Kent。
这些是昨晚的提交时间。
在你又开始抱怨你是如何修复 Bug 之前，让我提醒你一下你在 big-endian 机器上的构建失败，因为你的补丁在你的树之外没有经过任何测试。
那是上周的事了，我有种强烈的感觉，这次经历完全没有让我们学到任何东西。
我已经拉取了这个，但我在列表中搜索了几条提交信息，却一无所获（好吧，我找到了你的拉取请求，其中明显提到了提交信息的第一行）。
我正在认真考虑停止从你那里拉取，因为我根本看不到你在改进你的模型。 如果你想拥有一棵实验树，你完全可以在主线内核之外拥有一棵。 我已经告诉过你了，但似乎没有什么能让你真正理解。
我曾希望并期待 bcachefs 被主线化能真正帮助开发。但事实并非如此。基本上你仍然是唯一的开发者，没有任何迹象表明这一点会改变，而且你似乎觉得在下一个 RC 版本发布的前一天把别人从未见过的未经测试的东西发给我就可以了。
你是个聪明人。 我觉得我给你的提示已经够多了。 你为什么不坐下来好好想想呢？让我们把话说清楚：你在这里正好有两个选择：
(a) 和别人玩得更好（和 Linux 社区其他人合作）
(b) 带着你的玩具回家（从 Linux 主线中剥离）
这就是选择。
Linus
Overstreet 表示，“但我想特别说明：我们虽然偶尔会互相较劲，但那是因为我们都非常在乎自己的工作，只是对问题的看法不太一样。这种争论其实是有益的，因为我们总能找到共同点，找到前进的办法，也从中学到东西——尽管这些讨论偶尔有点戏剧化。”
不过，他也收到了一些提到“行为准则委员会”（CoC）的邮件，并称「听起来就像提到了某种“魔鬼”。CoC 的处理方式是，只要有匿名投诉被注意到，他们就会要求某人公开道歉，否则就会采取措施」：
我拒绝公开道歉，原因有几个：
这是一个长期积累的问题，已经影响到多个团队和项目，应该认真讨论这个问题；
更广泛的来说，我认为 CoC 委员会本身存在一些问题；
最重要的是，这种事情本该私下解决。
Linus 在六年前反思自己后，上线了 CoC
那么，CoC 到底是什么？
这可以从 Linux 之父 Linus Torvalds 在六年前的一次休假谈起。
一直以来，Linus Torvalds 的火爆脾气在整个社区都是出了名的，无论是内核维护者的代码写不好，还是企业在解决问题上有所拖延、亦或是看一些编程语言不顺眼，他都是无所忌惮地直接开怼。
直到 2018 年，Linus 因为自己弄错了一次内核维护者峰会的日期而在社区引发了大量的讨论，这次错误与争议也让他开始反省自己。当时的他表示，想要向被他言语伤害的人道歉。他称自己需要离开一段时间，需要帮助来更恰当地理解一个人的情绪和反应。
经此次事情后不久，Linux 社区就上线了一个行为准则（Code of Conduct，https://www.kernel.org/doc/html/latest/process/code-of-conduct.html），旨在营造一个开放而热情的环境，为项目和社区的每位参与者创造免受骚扰的体验，无论其年龄、体型、残疾、种族、性别特征、性别认同和性别表达、经验水平、教育、社会经济地位、国籍、外表、种族、宗教，或性认同和性取向。
同时，该准则背后还有一个委员会负责监督与执行。
开发者怒斥 CoC 委员会
此次 Linus 拒绝 Overstreet 所提交的合并请求，只要是因为 CoC 委员会在背后推动。不过，CoC 委员会通过 Shuah 对此情况的处理也让包括 Kent 在内的许多 Linux 内核维护人员对这种高压态势感到失望，同时 CoC 的执行也受到了质疑。
Overstreet 在长文中分享了自己之前的经历，他表示：
在 Plumbers 大会上，一位知名的 CoC 成员兼内核稳定版维护者和我谈了一次话。在这个过程中，他试图让我遵循 CoC 的“流程”，并提到：
1.社区形象很重要；
2.多次暗示“如果我不在了会很可惜”。
他的“形象”说辞，听起来更像是“要让公司满意”。我提到这一点是因为在会上，另一位高层维护者也提过类似话：“Linux 现在是为大公司服务的。”
但我不能认同。Linux 的起步与大公司无关，我 25 年前从邮件列表上学习做工程师，而科技公司只是过客，Linux 会超越它们的生命周期。我们的责任是服务于社区和用户，维系并保护这个备受依赖的工程文化。
更重要的是，不用说，威胁某人的职业生涯来让他们遵守规定并不是一个好方法。
那位 CoC 成员在会上随意辱骂文件系统社区的每个成员，说他们都是混蛋。可这些人其实是英雄：
Matthew Wilcox 是个传奇人物，他完成了 folios 的开发，这大大优化了 4K 页面开销。现代 NVMe 设备的性能需求让这种工作变得必不可少，否则 Linux 可能已经失去在文件系统领域的 relevancy。
Ted T’so 保证了 Linux 用户拥有一个可靠的文件系统。他负责了许多幕后维护工作，比如 e2fsck 的可靠性，是社区里的支柱。
Wedson Almeida Filho 为推动 Rust 文件系统接口做了巨大努力。
在文件系统社区工作虽然压力大，但大家关系很近，争论也只限技术讨论。
如今我看到的却是，一些领导者的行为根本没起到带头作用。
过于强硬的处理方式，会让人不愿参与讨论，甚至滋生一种敷衍文化——因为这样更“安全”，避免卷入激烈争论。
社区不是可以随意替换的零件。我们应当互相关心，而不是简单地“踢掉麻烦制造者”。我编写代码是因为热爱和享受这片社区氛围，而不是为了大公司的利益。
最终，Overstreet 的反驳以及拒绝公开道歉行为，根据行为准则委员会的建议，Linux 基金会技术顾问委员会决定在 Linux 6.13 开发周期内拒绝所有来自 他的合并请求。
针对此举，有开发者评价道：
我不得不站在 CoC 团队这边。Kent 你在 LKML 上的行为简直令人无法接受。在技术争论方面，你可能是对的，也可能不是，但这不是这里的问题。你一次又一次与 Linus 的讨论也是如此，当他希望你遵循与其他人相同的程序时，你完全无视他所说的话，你只是争辩说你的方式更好，你的 FS 比 BTreeFS 更好，这不构成争论。这对你来说可能很难，但你真的需要改进你的行为，否则 bcachefs 本身可能会成为附带损害。
我确信与开源社区的一些成员打交道确实很辛苦，而且是一项不值得羡慕的任务。我确信小封地无处不在。Rust 的人似乎也遇到了类似的问题。不过，我想，我为这个项目做出贡献的原因之一是，我认为它最有可能成为下一代默认文件系统。这是非常需要的。如果它脱离内核，这实际上不会发生，而且传统上脱离内核的文件系统并没有真正做得很好。我想除非您要让一个大型发行版将其用作默认文件系统，那可能只有 Ubuntu 或 RH（也许是 Fedora）。据我所知，即使是 Suse 也无法让 ReisierFS 得到更广泛的采用。最好的做法是让一些压力从这件事中消退。祝一切顺利
对此，你怎么看？
参考：
https://news.itsfoss.com/linux-kernel-bcachefs/
https://www.patreon.com/posts/trouble-in-116412665