LWN：运行fstests的最好方式！

关注了就能看到更多这么棒的文章哦～

Best practices for fstests

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

作为当天早些时候关于测试所面临的挑战的会议的后续，Josef Bacik 在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）的存储和文件系统联合会议上主持了关于测试最佳实践的讨论。开发人员可以通过多种方式来合作从而共同改善使用 fstests 和 blktests 的测试环境，首先，是收集和分享关于哪些测试预计会 pass 和 fail。这些信息取决于很多不同的因素，包括内核版本和配置，fstest 选项等等。

Existing testing

Bacik 首先简要介绍了他用于 Btrfs 测试的环境，可以持续运行 fstests。其中有一个 dashboard 网站，显示测试的 pass 或 fail，以及哪些配置受到影响。他说："这已经非常棒了"；目前已经运行了一年。

他指出，Luis Chamberlain 在一个循环中运行一千次测试，但 Bacik 的方法是仅仅运行一次。在以这种方式运行的一年中，他收集了一份清单，其中包括哪些测试是不稳定的；然后他修复了许多不稳定的测试，使它们更加可靠。Bacik 说，这两种测试方式都是有效的，也是都有用的，但他的方法给了他 "最好的回报"，可以满足他的需求。

Ted Ts'o 说，在寻找 bug 方面，他更信任 fstests，而不是 "完全依赖日常使用 linux-next"；他很少从 linux-next 测试中看到 bug。Fstests "更加吹毛求疵" 一些，所以在 Fstests 上 15%的失败率通常意味着有真正的 bug，但用户可能不会遇到，即使是在压力最大的 production workload 里面也一样。这也是他不太关心 fstest 中零散失败的原因之一。他很想能够解决他所看到的所有问题，但现实中这是不可能的；他没有时间，他的团队中也没有足够的工程师来这样做。这是一个 "让人不愉快的现实"，对于 fstests 的新用户来说，很难意识到这一点。

同时，Ts'o 说，他有一些文件，在其中列出了他 exclude 的测试，以及 exclude 的原因。并且介绍了测试失败的原因，这可能是由于 fstests 的 bug 或 ext4 里面一些特殊行为。他想知道应该把这些文件提交到什么地方，才能让其他人可以从这些信息中受益。这些文件在他的 GitHub 仓库中，但也许把它们添加到 kernel documentation 中并标明 "freshness date" 会更有意义。

James Bottomley 询问了用于测试 linux-next 内核的 0day 测试机器人的情况。Ts'o 说，机器人只对 ext4 的单一一种配置条件来运行 fstests，通常运行结果都是很干净的。该配置使用了 4KB 块大小，也是生产系统中最常用的配置，但他总共测试了 12 种配置。Bottomley 建议应该更多地使用 0day 机器人，但是 Ts'o 担心不稳定的测试会导致大量虚假 regression 被报告出来，"因为 0day 机器人刚好运气不好"。但他说，这值得研究一下。

Bacik 说，他希望看到社区 "走向这个新的现实方式"，能很容易知道什么测试会失败。例如，他就不知道 ext4 的哪些测试会失败，所以当他做了一个影响 ext4 的改变时，他不知道是否有什么问题是由于这个改变而造成的。Chamberlain 有 kdevops 的一个 exclude 文件，但如果有一个地方可以让文件系统开发者获得这样的 exclude 文件并根据需要来进行更新，那就更好了。他说，这些文件中列出的测试也可以作为新工程师入职时的练习，他们可以被要求来研究某个测试失败是为什么。

Ts'o 说，当他有时间做一些 fstests 的开发时，他会去添加一个运行模式来把一个失败的测试重新运行 25 或 100 次，从而得到失败的百分比。他不想自动去 exclude 一个仅有 15% 失败率的 test，因为他目前并不关心这种小概率问题；ext4 开发者需要这些测试能继续运行。但也有一些人只是想试着确定他们的 patch 是否破坏了什么功能，所以需要有一种方法来解决这两种类型的测试。

Omar Sandoval 问，是否应该把这些排除列表直接放到 fstests 库中。Ts'o 说，这个列表都是针对特定的配置环境的；Chamberlain 对此作了详细说明，指出这些 list 会跟内核版本、fstests 配置以及用于测试的基础设备类型有关。例如，loopback 文件系统的测试就会有另外的出错特征。大家讨论了是否需要根据所有不同的因素来管理这个 list。能对描述 fstests 配置的命名达成一致的话，会有助于使相关的 exclude list 在各种测试运行程序中都可以支持好。

Standardization

Chamberlain 认为，内核配置可以针对测试环境进行标准化，因为 kdevops 就是在用单一配置，可以用于 KVM 本地或各种云供应商情况。Ts'o 说，他的测试运行环境（kvm-xfstests/gce-xfstests）也有一个标准化的配置，所以他和 Chamberlain 应该比较一下。但 Ts'o 在构建内核时仍需要一些其他可选项，例如启用 KASAN 或 kernel module，这是因为同时还要运行 blktests ，这些选项是必须的。他说，构建 Kconfig 文件的工具应该在 test runner 之间先实现标准化。

Bacik 说，他希望看到文件系统开发者能不再需要在晚上运行测试，或者进行 continuous 测试。他目前家里有四个系统都用来做这件事了，但他想让这些系统停下来，让 Linux 基金会或其他人来接手做这项工作。Ts'o 认为，只要有一个集中的 dashboard 来报告各个开发者在他们的物理系统或云端系统上的测试结果，也是朝着正确的方向迈出的一步。能有一个集中的位置可以看到 fstests 的当前状态就会很有帮助。

一位与会者说，在这种类型的工作中，总是有后续采取行动来落实的问题。这个话题在 LSFMM 中经常出现，并且讨论了一些解决方案的想法，但是没有什么真正结果。Christian Brauner 同意，多年来一直缺乏后续行动。但是 Chamberlain 说，kdevops 是在以前的 LSFMMs 的讨论中产生的；他花了很多时间让它发挥作用，现在已经可以使用了。他没有使用 Ts'o 的 test runner 的唯一原因是他想针对多个云；gce-xfstests 只针对谷歌云。Kdevops 已经支持了 exclude list，Chamberlain 说，他在定期更新。"要想得到一个能在所有云解决方案上工作的内核配置，我们还需要做些什么？"

Bacik 表示同意，并指出他曾尝试过 Ts'o 的解决方案，但当时它无法用于 Btrfs，而 kdevops 则可以使用。他采用这个方案是因为如果没有社区对测试基础设施的支持的话，他就无法维持 Btrfs 的开发；他一直在尝试同时做 test 的管理和 Btrfs 开发，但并不成功。他希望看到更多的人凝聚在这个解决方案周围，来解决其中的错误和问题，然后把它交给其他人来运行，或者资助它在云服务中运行。

Chris Mason 说，Linux 基金会设立的目标并不是直接资助这类工作。相反，他们会把感兴趣的公司的资金引到这类项目上来。他说，这应该只是一个小问题，就是如何让那些资助文件系统开发的公司来签字承担。他说，资金是容易解决的；困难的是如何让所有人都使用同一套工具。

Ts'o 说，实际上有两个困难；另一个困难就是开发者缺乏时间来分析所发生的故障。他很乐意给那些运行 gce-xfstests 的人提供谷歌云 credit，如果他们能承诺花时间来分析他们发现的问题的话。Ts'o 说，也许有必要收集一下需求，因为他已经看了 kdevops，它并没有解决他的文件系统开发工作流程的一些关键需求。例如，kvm-xfstests 可以简单使用他刚刚在笔记本电脑上编译好的本地 kernel，把它扔进虚拟机，并基于它来运行 fstests，但 kdevops 的目标是 QA 使用场景，所以不支持这种测试。他认为，可以先开始来统一内核配置和 exclude list 的处理等工作。

Ts'o 说，可能会有不同的工具被用在不同的使用场景下；本地编译的内核测试场景对他来说很重要。Bacik 同意本地内核测试是很关键的，但认为 kdevops 应该可以添加这种功能。Chamberlain 说，要做到这一点应该不难。

Bacik 说，他希望在 9 月都柏林的 Linux Plumbers 会议之前将他的 nightly testing 系统切换到 kdevops 上，届时现在这些老朋友们将再次聚集在一个房间讨论。大家普遍认为，在 requirements、kernel-configuration handling、fstests exclude-list handling 等方面的合作将继续进行，也许可以在 fstests mailinglist 中作为一个讨论主题。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～