LWN：運(yùn)行fstests的最好方式！

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

Best practices for fstests

By Jake Edge
June 7, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/897061/

作為當(dāng)天早些時候關(guān)于測試所面臨的挑戰(zhàn)的會議的后續(xù)，Josef Bacik 在 2022 年 Linux 存儲、文件系統(tǒng)、內(nèi)存管理和 BPF 峰會（LSFMM）的存儲和文件系統(tǒng)聯(lián)合會議上主持了關(guān)于測試最佳實(shí)踐的討論。開發(fā)人員可以通過多種方式來合作從而共同改善使用 fstests 和 blktests 的測試環(huán)境，首先，是收集和分享關(guān)于哪些測試預(yù)計會 pass 和 fail。這些信息取決于很多不同的因素，包括內(nèi)核版本和配置，fstest 選項(xiàng)等等。

Existing testing

Bacik 首先簡要介紹了他用于 Btrfs 測試的環(huán)境，可以持續(xù)運(yùn)行 fstests。其中有一個 dashboard 網(wǎng)站，顯示測試的 pass 或 fail，以及哪些配置受到影響。他說："這已經(jīng)非常棒了"；目前已經(jīng)運(yùn)行了一年。

他指出，Luis Chamberlain 在一個循環(huán)中運(yùn)行一千次測試，但 Bacik 的方法是僅僅運(yùn)行一次。在以這種方式運(yùn)行的一年中，他收集了一份清單，其中包括哪些測試是不穩(wěn)定的；然后他修復(fù)了許多不穩(wěn)定的測試，使它們更加可靠。Bacik 說，這兩種測試方式都是有效的，也是都有用的，但他的方法給了他 "最好的回報"，可以滿足他的需求。

Ted Ts'o 說，在尋找 bug 方面，他更信任 fstests，而不是 "完全依賴日常使用 linux-next"；他很少從 linux-next 測試中看到 bug。Fstests "更加吹毛求疵" 一些，所以在 Fstests 上 15%的失敗率通常意味著有真正的 bug，但用戶可能不會遇到，即使是在壓力最大的 production workload 里面也一樣。這也是他不太關(guān)心 fstest 中零散失敗的原因之一。他很想能夠解決他所看到的所有問題，但現(xiàn)實(shí)中這是不可能的；他沒有時間，他的團(tuán)隊(duì)中也沒有足夠的工程師來這樣做。這是一個 "讓人不愉快的現(xiàn)實(shí)"，對于 fstests 的新用戶來說，很難意識到這一點(diǎn)。

同時，Ts'o 說，他有一些文件，在其中列出了他 exclude 的測試，以及 exclude 的原因。并且介紹了測試失敗的原因，這可能是由于 fstests 的 bug 或 ext4 里面一些特殊行為。他想知道應(yīng)該把這些文件提交到什么地方，才能讓其他人可以從這些信息中受益。這些文件在他的 GitHub 倉庫中，但也許把它們添加到 kernel documentation 中并標(biāo)明 "freshness date" 會更有意義。

James Bottomley 詢問了用于測試 linux-next 內(nèi)核的 0day 測試機(jī)器人的情況。Ts'o 說，機(jī)器人只對 ext4 的單一一種配置條件來運(yùn)行 fstests，通常運(yùn)行結(jié)果都是很干凈的。該配置使用了 4KB 塊大小，也是生產(chǎn)系統(tǒng)中最常用的配置，但他總共測試了 12 種配置。Bottomley 建議應(yīng)該更多地使用 0day 機(jī)器人，但是 Ts'o 擔(dān)心不穩(wěn)定的測試會導(dǎo)致大量虛假 regression 被報告出來，"因?yàn)?0day 機(jī)器人剛好運(yùn)氣不好"。但他說，這值得研究一下。

Bacik 說，他希望看到社區(qū) "走向這個新的現(xiàn)實(shí)方式"，能很容易知道什么測試會失敗。例如，他就不知道 ext4 的哪些測試會失敗，所以當(dāng)他做了一個影響 ext4 的改變時，他不知道是否有什么問題是由于這個改變而造成的。Chamberlain 有 kdevops 的一個 exclude 文件，但如果有一個地方可以讓文件系統(tǒng)開發(fā)者獲得這樣的 exclude 文件并根據(jù)需要來進(jìn)行更新，那就更好了。他說，這些文件中列出的測試也可以作為新工程師入職時的練習(xí)，他們可以被要求來研究某個測試失敗是為什么。

Ts'o 說，當(dāng)他有時間做一些 fstests 的開發(fā)時，他會去添加一個運(yùn)行模式來把一個失敗的測試重新運(yùn)行 25 或 100 次，從而得到失敗的百分比。他不想自動去 exclude 一個僅有 15% 失敗率的 test，因?yàn)樗壳安⒉魂P(guān)心這種小概率問題；ext4 開發(fā)者需要這些測試能繼續(xù)運(yùn)行。但也有一些人只是想試著確定他們的 patch 是否破壞了什么功能，所以需要有一種方法來解決這兩種類型的測試。

Omar Sandoval 問，是否應(yīng)該把這些排除列表直接放到 fstests 庫中。Ts'o 說，這個列表都是針對特定的配置環(huán)境的；Chamberlain 對此作了詳細(xì)說明，指出這些 list 會跟內(nèi)核版本、fstests 配置以及用于測試的基礎(chǔ)設(shè)備類型有關(guān)。例如，loopback 文件系統(tǒng)的測試就會有另外的出錯特征。大家討論了是否需要根據(jù)所有不同的因素來管理這個 list。能對描述 fstests 配置的命名達(dá)成一致的話，會有助于使相關(guān)的 exclude list 在各種測試運(yùn)行程序中都可以支持好。

Standardization

Chamberlain 認(rèn)為，內(nèi)核配置可以針對測試環(huán)境進(jìn)行標(biāo)準(zhǔn)化，因?yàn)?kdevops 就是在用單一配置，可以用于 KVM 本地或各種云供應(yīng)商情況。Ts'o 說，他的測試運(yùn)行環(huán)境（kvm-xfstests/gce-xfstests）也有一個標(biāo)準(zhǔn)化的配置，所以他和 Chamberlain 應(yīng)該比較一下。但 Ts'o 在構(gòu)建內(nèi)核時仍需要一些其他可選項(xiàng)，例如啟用 KASAN 或 kernel module，這是因?yàn)橥瑫r還要運(yùn)行 blktests ，這些選項(xiàng)是必須的。他說，構(gòu)建 Kconfig 文件的工具應(yīng)該在 test runner 之間先實(shí)現(xiàn)標(biāo)準(zhǔn)化。

Bacik 說，他希望看到文件系統(tǒng)開發(fā)者能不再需要在晚上運(yùn)行測試，或者進(jìn)行 continuous 測試。他目前家里有四個系統(tǒng)都用來做這件事了，但他想讓這些系統(tǒng)停下來，讓 Linux 基金會或其他人來接手做這項(xiàng)工作。Ts'o 認(rèn)為，只要有一個集中的 dashboard 來報告各個開發(fā)者在他們的物理系統(tǒng)或云端系統(tǒng)上的測試結(jié)果，也是朝著正確的方向邁出的一步。能有一個集中的位置可以看到 fstests 的當(dāng)前狀態(tài)就會很有幫助。

一位與會者說，在這種類型的工作中，總是有后續(xù)采取行動來落實(shí)的問題。這個話題在 LSFMM 中經(jīng)常出現(xiàn)，并且討論了一些解決方案的想法，但是沒有什么真正結(jié)果。Christian Brauner 同意，多年來一直缺乏后續(xù)行動。但是 Chamberlain 說，kdevops 是在以前的 LSFMMs 的討論中產(chǎn)生的；他花了很多時間讓它發(fā)揮作用，現(xiàn)在已經(jīng)可以使用了。他沒有使用 Ts'o 的 test runner 的唯一原因是他想針對多個云；gce-xfstests 只針對谷歌云。Kdevops 已經(jīng)支持了 exclude list，Chamberlain 說，他在定期更新。"要想得到一個能在所有云解決方案上工作的內(nèi)核配置，我們還需要做些什么？"

Bacik 表示同意，并指出他曾嘗試過 Ts'o 的解決方案，但當(dāng)時它無法用于 Btrfs，而 kdevops 則可以使用。他采用這個方案是因?yàn)槿绻麤]有社區(qū)對測試基礎(chǔ)設(shè)施的支持的話，他就無法維持 Btrfs 的開發(fā)；他一直在嘗試同時做 test 的管理和 Btrfs 開發(fā)，但并不成功。他希望看到更多的人凝聚在這個解決方案周圍，來解決其中的錯誤和問題，然后把它交給其他人來運(yùn)行，或者資助它在云服務(wù)中運(yùn)行。

Chris Mason 說，Linux 基金會設(shè)立的目標(biāo)并不是直接資助這類工作。相反，他們會把感興趣的公司的資金引到這類項(xiàng)目上來。他說，這應(yīng)該只是一個小問題，就是如何讓那些資助文件系統(tǒng)開發(fā)的公司來簽字承擔(dān)。他說，資金是容易解決的；困難的是如何讓所有人都使用同一套工具。

Ts'o 說，實(shí)際上有兩個困難；另一個困難就是開發(fā)者缺乏時間來分析所發(fā)生的故障。他很樂意給那些運(yùn)行 gce-xfstests 的人提供谷歌云 credit，如果他們能承諾花時間來分析他們發(fā)現(xiàn)的問題的話。Ts'o 說，也許有必要收集一下需求，因?yàn)樗呀?jīng)看了 kdevops，它并沒有解決他的文件系統(tǒng)開發(fā)工作流程的一些關(guān)鍵需求。例如，kvm-xfstests 可以簡單使用他剛剛在筆記本電腦上編譯好的本地 kernel，把它扔進(jìn)虛擬機(jī)，并基于它來運(yùn)行 fstests，但 kdevops 的目標(biāo)是 QA 使用場景，所以不支持這種測試。他認(rèn)為，可以先開始來統(tǒng)一內(nèi)核配置和 exclude list 的處理等工作。

Ts'o 說，可能會有不同的工具被用在不同的使用場景下；本地編譯的內(nèi)核測試場景對他來說很重要。Bacik 同意本地內(nèi)核測試是很關(guān)鍵的，但認(rèn)為 kdevops 應(yīng)該可以添加這種功能。Chamberlain 說，要做到這一點(diǎn)應(yīng)該不難。

Bacik 說，他希望在 9 月都柏林的 Linux Plumbers 會議之前將他的 nightly testing 系統(tǒng)切換到 kdevops 上，屆時現(xiàn)在這些老朋友們將再次聚集在一個房間討論。大家普遍認(rèn)為，在 requirements、kernel-configuration handling、fstests exclude-list handling 等方面的合作將繼續(xù)進(jìn)行，也許可以在 fstests mailinglist 中作為一個討論主題。

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

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