LWN：文件系統(tǒng)、測試、以及stable kernel！

關(guān)注了就能看到更多這么棒的文章哦～

Filesystems, testing, and stable trees

By Jake Edge
May 31, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/896523/

在 2022 年 Linux 存儲、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會（LSFMM）的文件系統(tǒng)會議上，Amir Goldstein 主持了一場關(guān)于 stable kernel tree 的討論。這些代碼 tree，尤其是長期支持（LTS, long-term support）版本，是用在各種基于 Linux 的產(chǎn)品里的代碼基礎(chǔ)，但對它們進(jìn)行的文件系統(tǒng)的測試卻很很少。其中部分原因是由于這些測試是供是供文件系統(tǒng)的開發(fā)者使用的，所以穩(wěn)定內(nèi)核的 downstream 的使用者就不是那么容易用起來了。

他之所以對這個問題感興趣，是因為他正在使用 5.10 LTS 內(nèi)核和 XFS 文件系統(tǒng)。他意識到 XFS 在該內(nèi)核中沒有維護(hù)好；在過去兩年多的時間里，只有三個 XFS patch 被 backport 到該版本的內(nèi)核。他說，這背后有一些歷史，盡管會議室里的大多數(shù)人都已經(jīng)知道了。

[Amir Goldstein]

他一直在向 5.10 移植新版本內(nèi)核里的 XFS patch，因為自該內(nèi)核發(fā)布以來，XFS 的 bug fix 可不止三個。在免責(zé)聲明中，他說做這些 backport 是他的責(zé)任，并不建議其他人來做這些工作。他在這個 backport 方面已經(jīng)取得了一些進(jìn)展，并與 Luis Chamberlain 一起做了一些測試。會議上他希望討論 stable kernel 和文件系統(tǒng)的工作流程。

Goldstein 說，穩(wěn)定內(nèi)核之所以存在，一個原因是它可以讓多個組織進(jìn)行合作，"不會有重復(fù)工作"。這只有在 LTS 版本被 "big players" 使用起來時才有效，所以如果這些版本沒有被廣泛使用，那么其價值就會下降。許多發(fā)行版不使用 LTS 內(nèi)核，但也有一些組織在使用。谷歌云就是其中之一，它遵循著 stable kernel 的 release，聽說微軟也在這么做。安卓也在關(guān)注 stable release，但該項目不會使用 XFS。

要想讓 kernel 擁有穩(wěn)定的文件系統(tǒng)，關(guān)鍵是要能夠在上面運(yùn)行 fstests（以前的 xfstests）。這意味著在測試工作、測試套件（test suite）、以及預(yù)期哪些 test 會 pass 哪些會 fail 方面，大家需要合作。Josef Bacik 說，當(dāng)初他在 Red Hat 工作時，在舊內(nèi)核上運(yùn)行最新的 fstests 總是很痛苦，因為它會以各種方式 "爆炸"（出現(xiàn)問題），這很令人討厭。但是，運(yùn)行最新的 fstests 并看到較新的測試失敗的話，就可以幫你指出可能需要 backport 的 patch，"這取決于你愿意承受多大的痛苦"，他說。

Goldstein 說，fstests 主要用于測試 upstream kernel；當(dāng)它們被應(yīng)用于 LTS 內(nèi)核時，"會發(fā)生一些意外情況"，所以要這么做并不是容易的事情。Fstests 對試圖測試 LTS 內(nèi)核的人并不友好，這跟他參與的另一個測試框架–Linux 測試項目（LTP）很不一樣。LTP 里面有一些可以被 Fstests 借鑒的做法，尤其是有一個標(biāo)準(zhǔn)的方法來對 regression test 進(jìn)行標(biāo)注，給出相應(yīng)的 bug fix 的 commit 信息，以及是在哪個版本的內(nèi)核中被 fix 的。這樣一來，如果該測試在另一個內(nèi)核上失敗了，"你就會得到提示"，也許需要對該 commit 進(jìn)行 backport 了，否則的話被測試的內(nèi)核就不會支持這項正在被測試的功能。

LTP 還有一個簡單的腳本，可以在某個 kernel branch 上來運(yùn)行，從而確定它是否包含了標(biāo)注中出現(xiàn)過的 commit，或者是否包含了提及到這些 commit 的后續(xù) commit 的 backport。他說這樣就可以給你一個應(yīng)該可以正常運(yùn)行的 test 的列表，這個列表是針對這個具體的 kernel branch 所定制的。

Ted Ts'o 說，大多數(shù)文件系統(tǒng)都希望讓 stable branch 的開發(fā)者來選擇并移植 fix，不過 XFS 是一個明顯的例外。他說，對于 ext4 來說這個過程可以很好地運(yùn)行起來；大概每隔一年左右會有一個有問題的 ext4 patch 需要從 stable tree 上撤出來，因為它本來就不適合這個 branch。通常情況下，這類 ch 是在 stable review 階段發(fā)現(xiàn)的。

Ts'o 和他的團(tuán)隊一直在努力想識別哪些 XFS patch 應(yīng)該加到 5.15 內(nèi)核上，因為那是谷歌所感興趣的 kernel，使用的是 Greg Kroah-Hartman 和 Sasha Levin 用來挑選該移植的 patch 的那組腳本。做這項工作所花的時間有些長，出乎了他的預(yù)料，部分原因是因為需要時間來明確清楚哪些 fstests 的 case 是應(yīng)該 pass 的，這樣他們才能夠檢測出 backport 是否造成了一些額外的問題。他們一直在使用一個自動測試系統(tǒng)，根據(jù) XFS 維護(hù)者 Darrick Wong 的意見選出了大概 10 種不同的配置。

結(jié)果發(fā)現(xiàn)，有一些 fstests 的 case 必須要合入 "百余個 out-of-tree commit " 時才能 pass，這些 commit 位于 Wong 的個人 fstests tree 中，但尚未進(jìn)入 upstream 倉庫。因此，Ts'o 現(xiàn)在有了自己的 fstests 分支，其中有來自 Wong 的這些必需的 patch。

他打算向 XFS 郵件列表來報告一下他們所做的工作，包括建議添加到 5.15 的 patch 列表。在那之后會需要協(xié)商來確定哪些 test 是應(yīng)該 pass 的。Ts'o 說，還需要弄清楚 XFS 維護(hù)者想要如何進(jìn)行。目前還不清楚這個過程是為 stable 提出 fix 方案并等待 XFS 人員的明確贊同，還是由 XFS 維護(hù)者來明確選擇一組 patch 添加到 stable kernel 里面。他希望能盡快開始這個商討。

Chamberlain 說，在過去，XFS 維護(hù)者已經(jīng)同意他和 Goldstein 可以對 stable kernel 的 XFS patch 進(jìn)行 review。但是，正如 Ts'o 和其他人所指出的，明確建立一個基礎(chǔ)是需要大量不辭辛勞的工作的；它還需要能使用相當(dāng)多的系統(tǒng)，Chamberlain 說?，F(xiàn)在，每個開發(fā)者都在盡最大努力進(jìn)行測試，但社區(qū)需要在 test 工作上進(jìn)行更多的合作；下一次 LSFMM 會議將涵蓋其中的一些內(nèi)容，他說。XFS fix 的候選方案可以發(fā)給他和 Goldstein；他們會把 patch 加到等待測試的隊列中，這將有助于對 patch 是否適合合入給出一些建議。

Jan Kara 通過 Zoom 發(fā)言說，發(fā)行版（包括他在參與的 SUSE）都確實關(guān)心 XFS 的 fix 問題。SUSE 的人使用了 XFS 的 fix，他認(rèn)為 Red Hat 也做了類似的工作。如果這些 fix 沒有在穩(wěn)定版內(nèi)核中出現(xiàn)，那么就會 backport 到企業(yè)版內(nèi)核中，然后進(jìn)行測試。做這些事情所需要的資源是相當(dāng)大的。需要有一些 "至少能看個大概明白" 的開發(fā)人員來查看這些 patch，看看它們是否有意義，如果確有必要的話就做移植工作。然后再加入 "相當(dāng)多的測試"，他說。

Goldstein 談到了他在查看從 5.10 到 5.17 的所有 XFS fix 時創(chuàng)建的一個工具，幫他確認(rèn)了大約 600 個 patch。該工具會使用 public-inbox 的郵件列表檔案來收集所有相關(guān)的 patch，尤其是搜集 cover letter。這使我們更容易看到有哪些依賴關(guān)系以及該選擇哪些 patch。這 "仍然是人工進(jìn)行的工作"，但這個工具是一個很好的助手。

Ts'o 指出，他每隔三到四個月就會使用最新的 LTS 內(nèi)核對 ext4 做一輪測試。實際運(yùn)行測試所需的資源不多；只要花幾美元的谷歌云時間就可以完成運(yùn)行多個配置的 fstests。而開發(fā)人員對 test failure 進(jìn)行分析解釋，以及找出是否有 patch 沒有被自動選擇進(jìn)來但應(yīng)該被選擇，所有這些所花費的時間是最昂貴的部分。

每當(dāng)他做這樣一輪的測試時，他都會發(fā)現(xiàn) 1 到 3 個 patch，需要他手動 backport 并發(fā)送給 stable 開發(fā)者。他不確定其他文件系統(tǒng)維護(hù)者是否也在做類似的測試，但這很有價值。這種測試也不是必須維護(hù)者自己做的，這可能是一個很好的機(jī)會來讓一些新的開發(fā)者加入到文件系統(tǒng)社區(qū)中來。

會議還討論了如何使 fstests 更容易在舊內(nèi)核上運(yùn)行的問題。Steve French 想知道是否需要有 fstests 的 stable branch，從而跟 stable kernel 發(fā)布保持同步。Goldstein 說，對 bug fix 的 commit 以及版本來進(jìn)行標(biāo)注，會對在更多內(nèi)核版本上更容易使用 fstests 更加重要。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～