LWN：文件系统、测试、以及stable kernel！

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

Filesystems, testing, and stable trees

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

在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）的文件系统会议上，Amir Goldstein 主持了一场关于 stable kernel tree 的讨论。这些代码 tree，尤其是长期支持（LTS, long-term support）版本，是用在各种基于 Linux 的产品里的代码基础，但对它们进行的文件系统的测试却很很少。其中部分原因是由于这些测试是供是供文件系统的开发者使用的，所以稳定内核的 downstream 的使用者就不是那么容易用起来了。

他之所以对这个问题感兴趣，是因为他正在使用 5.10 LTS 内核和 XFS 文件系统。他意识到 XFS 在该内核中没有维护好；在过去两年多的时间里，只有三个 XFS patch 被 backport 到该版本的内核。他说，这背后有一些历史，尽管会议室里的大多数人都已经知道了。

[Amir Goldstein]

他一直在向 5.10 移植新版本内核里的 XFS patch，因为自该内核发布以来，XFS 的 bug fix 可不止三个。在免责声明中，他说做这些 backport 是他的责任，并不建议其他人来做这些工作。他在这个 backport 方面已经取得了一些进展，并与 Luis Chamberlain 一起做了一些测试。会议上他希望讨论 stable kernel 和文件系统的工作流程。

Goldstein 说，稳定内核之所以存在，一个原因是它可以让多个组织进行合作，"不会有重复工作"。这只有在 LTS 版本被 "big players" 使用起来时才有效，所以如果这些版本没有被广泛使用，那么其价值就会下降。许多发行版不使用 LTS 内核，但也有一些组织在使用。谷歌云就是其中之一，它遵循着 stable kernel 的 release，听说微软也在这么做。安卓也在关注 stable release，但该项目不会使用 XFS。

要想让 kernel 拥有稳定的文件系统，关键是要能够在上面运行 fstests（以前的 xfstests）。这意味着在测试工作、测试套件（test suite）、以及预期哪些 test 会 pass 哪些会 fail 方面，大家需要合作。Josef Bacik 说，当初他在 Red Hat 工作时，在旧内核上运行最新的 fstests 总是很痛苦，因为它会以各种方式 "爆炸"（出现问题），这很令人讨厌。但是，运行最新的 fstests 并看到较新的测试失败的话，就可以帮你指出可能需要 backport 的 patch，"这取决于你愿意承受多大的痛苦"，他说。

Goldstein 说，fstests 主要用于测试 upstream kernel；当它们被应用于 LTS 内核时，"会发生一些意外情况"，所以要这么做并不是容易的事情。Fstests 对试图测试 LTS 内核的人并不友好，这跟他参与的另一个测试框架–Linux 测试项目（LTP）很不一样。LTP 里面有一些可以被 Fstests 借鉴的做法，尤其是有一个标准的方法来对 regression test 进行标注，给出相应的 bug fix 的 commit 信息，以及是在哪个版本的内核中被 fix 的。这样一来，如果该测试在另一个内核上失败了，"你就会得到提示"，也许需要对该 commit 进行 backport 了，否则的话被测试的内核就不会支持这项正在被测试的功能。

LTP 还有一个简单的脚本，可以在某个 kernel branch 上来运行，从而确定它是否包含了标注中出现过的 commit，或者是否包含了提及到这些 commit 的后续 commit 的 backport。他说这样就可以给你一个应该可以正常运行的 test 的列表，这个列表是针对这个具体的 kernel branch 所定制的。

Ted Ts'o 说，大多数文件系统都希望让 stable branch 的开发者来选择并移植 fix，不过 XFS 是一个明显的例外。他说，对于 ext4 来说这个过程可以很好地运行起来；大概每隔一年左右会有一个有问题的 ext4 patch 需要从 stable tree 上撤出来，因为它本来就不适合这个 branch。通常情况下，这类 ch 是在 stable review 阶段发现的。

Ts'o 和他的团队一直在努力想识别哪些 XFS patch 应该加到 5.15 内核上，因为那是谷歌所感兴趣的 kernel，使用的是 Greg Kroah-Hartman 和 Sasha Levin 用来挑选该移植的 patch 的那组脚本。做这项工作所花的时间有些长，出乎了他的预料，部分原因是因为需要时间来明确清楚哪些 fstests 的 case 是应该 pass 的，这样他们才能够检测出 backport 是否造成了一些额外的问题。他们一直在使用一个自动测试系统，根据 XFS 维护者 Darrick Wong 的意见选出了大概 10 种不同的配置。

结果发现，有一些 fstests 的 case 必须要合入 "百余个 out-of-tree commit " 时才能 pass，这些 commit 位于 Wong 的个人 fstests tree 中，但尚未进入 upstream 仓库。因此，Ts'o 现在有了自己的 fstests 分支，其中有来自 Wong 的这些必需的 patch。

他打算向 XFS 邮件列表来报告一下他们所做的工作，包括建议添加到 5.15 的 patch 列表。在那之后会需要协商来确定哪些 test 是应该 pass 的。Ts'o 说，还需要弄清楚 XFS 维护者想要如何进行。目前还不清楚这个过程是为 stable 提出 fix 方案并等待 XFS 人员的明确赞同，还是由 XFS 维护者来明确选择一组 patch 添加到 stable kernel 里面。他希望能尽快开始这个商讨。

Chamberlain 说，在过去，XFS 维护者已经同意他和 Goldstein 可以对 stable kernel 的 XFS patch 进行 review。但是，正如 Ts'o 和其他人所指出的，明确建立一个基础是需要大量不辞辛劳的工作的；它还需要能使用相当多的系统，Chamberlain 说。现在，每个开发者都在尽最大努力进行测试，但社区需要在 test 工作上进行更多的合作；下一次 LSFMM 会议将涵盖其中的一些内容，他说。XFS fix 的候选方案可以发给他和 Goldstein；他们会把 patch 加到等待测试的队列中，这将有助于对 patch 是否适合合入给出一些建议。

Jan Kara 通过 Zoom 发言说，发行版（包括他在参与的 SUSE）都确实关心 XFS 的 fix 问题。SUSE 的人使用了 XFS 的 fix，他认为 Red Hat 也做了类似的工作。如果这些 fix 没有在稳定版内核中出现，那么就会 backport 到企业版内核中，然后进行测试。做这些事情所需要的资源是相当大的。需要有一些 "至少能看个大概明白" 的开发人员来查看这些 patch，看看它们是否有意义，如果确有必要的话就做移植工作。然后再加入 "相当多的测试"，他说。

Goldstein 谈到了他在查看从 5.10 到 5.17 的所有 XFS fix 时创建的一个工具，帮他确认了大约 600 个 patch。该工具会使用 public-inbox 的邮件列表档案来收集所有相关的 patch，尤其是搜集 cover letter。这使我们更容易看到有哪些依赖关系以及该选择哪些 patch。这 "仍然是人工进行的工作"，但这个工具是一个很好的助手。

Ts'o 指出，他每隔三到四个月就会使用最新的 LTS 内核对 ext4 做一轮测试。实际运行测试所需的资源不多；只要花几美元的谷歌云时间就可以完成运行多个配置的 fstests。而开发人员对 test failure 进行分析解释，以及找出是否有 patch 没有被自动选择进来但应该被选择，所有这些所花费的时间是最昂贵的部分。

每当他做这样一轮的测试时，他都会发现 1 到 3 个 patch，需要他手动 backport 并发送给 stable 开发者。他不确定其他文件系统维护者是否也在做类似的测试，但这很有价值。这种测试也不是必须维护者自己做的，这可能是一个很好的机会来让一些新的开发者加入到文件系统社区中来。

会议还讨论了如何使 fstests 更容易在旧内核上运行的问题。Steve French 想知道是否需要有 fstests 的 stable branch，从而跟 stable kernel 发布保持同步。Goldstein 说，对 bug fix 的 commit 以及版本来进行标注，会对在更多内核版本上更容易使用 fstests 更加重要。

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

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