整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

投稿或尋求報道 | zhanghy@csdn.net

一套被稱為“下一代”的文件系統，剛被 Linux 主線接受一年半，如今又瀕臨出局邊緣。

前一陣子，在 Linux 內核開發社區中，一場圍繞 Bcachefs 的“流程之爭”愈演愈烈——Linux 之父 Linus Torvalds 再次對 Bcachefs 項目的主要維護者 Kent Overstreet 表達強烈不滿，原因是其在內核 6.16 的候選版本（RC）階段提交了帶有新功能的補丁，這嚴重違背了 Linux 長期以來的開發規則。

經過持續一周的爭議后，Linus Torvalds 最終還是選擇將那段代碼合并，但也對 Bcachefs 給出了一個頗具警示意味的表態：“事情到了這個地步，我都不想再參與了。我們唯一真正達成一致的，大概就是‘我們已經結束了’。”

雷區引爆：RC 階段加入新功能？

要說 Bcachefs 是 Linux 社區最具爭議的文件系統之一，恐怕沒人會反對。

這個項目由 Kent Overstreet 于 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

AI 產品爆發，但你的痛點解決了嗎？

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人

12 大專題分享，洞察趨勢、拆解路徑、對話未來。

立即掃碼領取大會PPT

搶占 AI 產品下一波紅利