整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

投稿或?qū)で髨蟮?| zhanghy@csdn.net

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

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

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

雷區(qū)引爆：RC 階段加入新功能？

要說 Bcachefs 是 Linux 社區(qū)最具爭議的文件系統(tǒng)之一，恐怕沒人會反對。

這個項目由 Kent Overstreet 于 2015 年發(fā)布，初衷是打造一個兼具 Btrfs 靈活性與 ext4 穩(wěn)定性的現(xiàn)代文件系統(tǒng)，具備寫時復(fù)制（COW）、快照、壓縮、校驗等功能，被視作 Btrfs 的有力替代者。過去十年，它一直以外部模塊的形式活躍于社區(qū)，直到 2024 年初，它才終于正式被納入 Linux 6.7 主線內(nèi)核。

但 Bcachefs 的這段主線之路，并不平坦。

Bcachefs 的開發(fā)過程向來“風(fēng)格鮮明”。Kent Overstreet 既是主力代碼撰寫者，也是唯一的核心維護者。他以高強度迭代、極度關(guān)注用戶 Bug 反饋著稱，幾乎親力親為地處理所有問題。正因為如此，Bcachefs 很快積累了一批忠實用戶——尤其是對 Btrfs 曾“翻車”過的開發(fā)者來說。

但在 Linus Torvalds 眼里，這樣的開發(fā)方式，也常常意味著流程不合規(guī)、代碼管理混亂。

本次爭議的導(dǎo)火索來自一個看似不大的功能補?。簀ournal_rewind。

這個功能的設(shè)計目的是允許文件系統(tǒng)回滾到較早的狀態(tài)點，用于極端情況下的數(shù)據(jù)恢復(fù)。雖然該功能尚未完善，Kent Overstreet 也承認目前還存在“較大限制”，但他仍希望能盡早推送到主線，避免用戶在數(shù)據(jù)丟失時束手無策。

于是，Kent Overstreet 便將這個新功能補丁與一些 Bug 的修復(fù)補丁一起打包，提交至 Linux 6.16-rc3 候選階段——問題就在于此。

根據(jù) Linux 內(nèi)核的開發(fā)規(guī)范，新功能代碼只能在合并窗口（merge window）期間提交，而 Linux 6.16 的合并窗口早已經(jīng)關(guān)閉，在 RC 階段只接受 Bug 修復(fù)（pure fixes）。但 Bcachefs 團隊試圖以“提升數(shù)據(jù)安全”為由，為新特性開綠燈，希望繞過這條鐵律。

意料之中，針對這一提交，Linus Torvalds 直言不諱地表達了不滿：“你似乎又忘了‘合并窗口’存在的意義。我們不能因為發(fā)現(xiàn)新問題，就在 RC 階段添加新功能?！贝送?，他還補充說，“所有使用 Bcachefs 的人都應(yīng)該知道，它只是個實驗性文件系統(tǒng)?！?/p>

值得一提的是，除了 Linus Torvalds，一向以穩(wěn)健著稱的 ext4 維護者 Theodore Ts'o 也發(fā)聲對 Kent Overstreet 表達不滿。他指出，在 RC 階段引入如此重大的變更，尤其是在文件系統(tǒng)這種高度依賴數(shù)據(jù)一致性與穩(wěn)定性的核心模塊中，風(fēng)險極高、極易埋雷。Theodore 強調(diào)，內(nèi)核社區(qū)早已就“RC 階段只能提交 Bug 修復(fù)”這一原則達成廣泛共識，而 Linus 的職責(zé)正是維護這條底線——言下之意很明確：沒人可以例外，流程不是兒戲。

Kent 不服：“規(guī)則不是用來死守的”

面對 Linus Torvalds 的指責(zé)，Kent Overstreet 并未示弱。他在郵件中長篇回應(yīng)，核心觀點只有一個：規(guī)則應(yīng)以用戶利益為先，而非無腦死守。

Kent Overstreet 指出，文件系統(tǒng)與 Linux 內(nèi)核其他子模塊不同，其設(shè)計缺陷往往會在用戶生產(chǎn)環(huán)境中造成不可逆損失：“其他模塊崩了大不了重啟，但文件系統(tǒng)出問題可能就是數(shù)據(jù)全無?！?/p>

他進一步解釋道，此次的 journal_rewind 只是一段約 70 行的小補丁，本質(zhì)就是讓日志回滾時倒序執(zhí)行覆蓋操作而非增量更新，主要用來搶救可能丟失的數(shù)據(jù)。

有開發(fā)者提出建議：“要么等到下一個合并窗口期再合并？”但 Kent Overstreet 提到，很多用戶根本不具備從 Git 編譯內(nèi)核的能力，而 RC 版本在各大發(fā)行版中是自動打包的：“我們不想再等 3 個月，這可能是用戶在數(shù)據(jù)崩潰和恢復(fù)之間的關(guān)鍵差異。”

對于社區(qū)反復(fù)強調(diào)“合并窗口就是規(guī)則”的觀點，Kent Overstreet 也沒有退讓：“規(guī)矩當(dāng)然有存在的必要，但有時候，也需要判斷力和常識。”

同時，他還強調(diào)自己才是 Bcachefs 的負責(zé)人，每天處理來自用戶的 Bug 報告、跟蹤哪些東西正常哪些有問題的人是他，不是別人，也不是 Linus?！斑@種對每一行補丁的‘微管理’行為，只是在制造沖突和戲劇性。”

Linus沉默合并，但留下“分手預(yù)警”

這場爭議持續(xù)了近一周，最終以 Linus Torvalds 將這段代碼合并作為收尾。

上周四晚上，或許是考慮到這項功能對數(shù)據(jù)恢復(fù)具有潛在價值，Linus Torvalds 在沒有任何額外說明的情況下，還是把Bcachefs 合并請求整合進了主線內(nèi)核。

不過，在另一封與 Bcachefs 相關(guān)的郵件中，Linus Torvalds 寫道：

“我已經(jīng)合并了這部分內(nèi)容，但正如我們上次討論的那樣，我認為我們會在 Linux 6.17 的合并窗口‘分道揚鑣’。你已經(jīng)明確表示，我連對任何 Bug 修復(fù)提出質(zhì)疑的資格都沒有，只能什么都合并。坦白講，在這種情況下，我真的不太愿意繼續(xù)參與。而我們唯一真正達成一致的，大概就是——‘我們已經(jīng)結(jié)束了’?！?/blockquote>

至于這對 Bcachefs 意味著什么，還有待觀察。Linus Torvalds 是否會直接將 Bcachefs 踢出主線？還是只是會更嚴(yán)格地執(zhí)行“候選階段只允許修復(fù)，不得添加新功能”的內(nèi)核開發(fā)規(guī)范？現(xiàn)在還無法確定。

面對 Linus Torvalds 和 Kent Overstreet 之間的這場爭論，社區(qū)內(nèi)的開發(fā)者也演變成了兩個陣營：

● 支持 Linus Torvalds：“我沒有和 Linus 共事過，所以無法評論他的語氣。但與其說‘我不喜歡現(xiàn)在的做法’，不如在內(nèi)核內(nèi)部聚集支持者，共同商討出一個具體的解決方案，明確需要修改哪些內(nèi)容以及如何修改，并最終制定一份正式的提案，列出所有支持者的名字，這樣會更有用。如果我是管理層，有人跟我說‘我不知道具體怎么做，但可以改一些東西’，我只會覺得他們是在挑事。”

● 支持 Kent Overstreet：“我實在不明白 Linus 生氣的點是什么。Kent 說得對，Linus 有時候真是想當(dāng)然，而不是根據(jù)具體情況來考慮問題。Kent 的 Bcachefs 實際上是第一個添加到 Linux 內(nèi)核的、具有意義重大的新功能，卻因為“流程”而受到如此多的阻力。過去Linux 內(nèi)核是如何引入其他新功能的？如果按照這個新流程，添加一個新文件系統(tǒng)需要的時間可能是幾十年，而不是幾年。”

那么，你對于此次事件的看法又是什么呢？

參考鏈接：https://www.phoronix.com/news/Bcachefs-One-Week-Later-Merge

AI 產(chǎn)品爆發(fā)，但你的痛點解決了嗎？

2025 全球產(chǎn)品經(jīng)理大會

8 月 15–16 日

北京·威斯汀酒店

互聯(lián)網(wǎng)大廠、AI 創(chuàng)業(yè)公司、ToB/ToC 實戰(zhàn)一線的產(chǎn)品人

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

立即掃碼領(lǐng)取大會PPT

搶占 AI 產(chǎn)品下一波紅利