風風火火的Linux 之父，Linus Torvalds，他又躍入公衆的視線。
" 打開方式 " 依舊是熟悉的配方——罵人。
我們先來看下 Linus 怒怼的名場面：
你的代碼就是垃圾。
我要把你丢進垃圾郵件一周。
而這一次的 " 受害者 "，是來自谷歌的一位程序員，Steven Rostedt。
而且他并非是随随便便的一位開發者，用網友的話來說 " 也算是大佬了 "。
△圖源："OSC 開源社區 " 評論區
不僅如此，從時間線上來看，雙方已經交鋒了足足有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，網友們也是各抒己見。
有認爲應該抛棄曆史包袱的，有認爲隻是二人設計理念的差距：
△圖源："OSC 開源社區 " 評論區
你覺得呢？
參考鏈接：
[ 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
— 完 —
點這裏關注我，記得标星哦～
一鍵三連「分享」、「點贊」和「在看」
科技前沿進展日日相見 ~
