风风火火的 Linux 之父，Linus Torvalds，他又跃入公众的视线。“打开方式”依旧是熟悉的配方 —— 骂人。
我们先来看下 Linus 怒怼的名场面：
你的代码就是垃圾。
我要把你丢进垃圾邮件一周。
而这一次的“受害者”，是来自谷歌的一位程序员，Steven Rostedt。而且他并非是随随便便的一位开发者，用网友的话来说“也算是大佬了”。
不仅如此，从时间线上来看，双方已经交锋了足足有 4 天之久…… 那么这到底是怎么一回事？
一个“inodes”，吵了四天
这场激辩是发生在 Linux 内核邮件列表。
Steven 起初是发了个帖子，主题是关于 eventfs（事件文件系统）的补丁。
具体而言，就是想探讨一下 inodes（索引节点）是否应该保持唯一性的问题。
（注：inodes 是 Linux 文件系统中的一个核心概念。它是一个数据结构，用于存储文件或目录的元数据，而不是文件的实际内容。）
Steven 认为：
Linus 之前建议在 eventfs 中使用相同的 inode 来简化 getdents () 的实现，这意味着所有文件和目录都将使用相同的 inode。
然而，这种做法后来被发现会导致“find”命令出现问题，因为目录和文件的 inode 相同。
Linus 随后发现在 64 位机器上，eventfs_inode 结构中存在一个由于对齐而产生的空洞，可以用来存储目录的 inode，这解决了目录的问题，但文件仍然保留了自己的 inode。
在 Steven 看来，由于 tar 命令依赖于 inode 来确定文件的唯一性，这种做法会破坏 tar 命令的功能：
目前，tar 命令在 tracefs（事件文件系统的一个变体）中已经出现问题，因为它显示所有文件的大小为零，导致 tar 不复制任何内容。
除此之外，Steven 也给出了自己想到的解决办法 —— 建议将 VFS 层的 get_next_ino () 函数复制到 tracefs 的 tracefs_get_next_ino () 函数中，并添加一个“files”参数。
这样，当创建 eventfs 目录时，就可以预先知道所需的 inode 数量。tracefs_get_next_ino () 将返回一个新的 inode，并预留下一个“files”个 inode 供调用者使用。
当创建文件的 inode 时，其 inode 将是其父目录的 inode 加上在该目录文件数组中的索引，从而为每个文件提供一个唯一的 inode。
然而，如此提案却被 Linus 强烈反对。
Linus 的核心观点是“inode 已经不再是唯一的描述符，我们不应该继续依赖于这种旧有的机制”。
不过对于 Linus 的回复，Steven 并没有买账，他坚持认为：
所有的文件和目录应该有唯一的 inode，这样做可以对文件系统的某些方面起到简化的作用。
然而在几轮探讨过后，Linus 就坐不住了，随即就出现了刚才怒怼的名场面：
不要把事情变得那么复杂。
你没有充分理解这些函数的用途和必要性
你的代码就是垃圾。
双方似乎都是各执己见，来来回回博弈了良久，从 1 月 26 日一直 battle 到了 1 月 29 日……
不过戏剧性的一点是，Linus 在争吵之余，后来还发布了 Linux 内核 6.8-rc2 版本。
他希望这个版本能够解决之前版本中发现的问题，并鼓励用户进行测试。
并非第一次公开“交锋”
其实在此之前，Steven 也曾在 2020 年初之际，在一场活动演讲中，公开与 Linus“交锋”过。
他甚至直接将演讲的主题定位“Arguing with Linus Torvalds”，内容依旧是围绕着如何让 Linux 效率得到改善而做出的建议。
不过对于这次最新的 battle，网友们也是各抒己见。
有认为应该抛弃历史包袱的，有认为只是二人设计理念的差距：
你觉得呢？
参考链接：
[1]https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04208.html
[2]https://www.youtube.com/watch?v=0pHImHVrI2I
[3]https://mp.weixin.qq.com/s/S0R_5OBSiSbDnl1-U6I4wg
本文来自微信公众号：量子位 （ID：QbitAI），作者：金磊
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。