LWN：把XFS fix移植回稳定版内核！

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

Backporting XFS fixes to stable

By Jake Edge
June 20, 2023
LSFMM+BPF
ChatGPT assisted translation
https://lwn.net/Articles/934941/

将 fix 移植回稳定版本内核一直在持续不断进行，通常由内核稳定版分支维护者或相关 fix 的开发人员来。然而，由于 XFS 开发社区对处理该文件系统的 stable fix 的过程存在一些不满，因此针对将 XFS 补丁移植回 stable kernel 的流程就形成了一套不同的做法。进行此项工作的三位开发人员 Leah Rumancik、Amir Goldstein 和 Chandan Babu Rajendra，在 2023 年的 Linux 存储、文件系统、内存管理和 BPF 峰会上（Rajendra 通过远程参与）主持了一场全体会议，讨论了这一流程。

Goldstein 首先指出，每位演讲者负责不同的稳定内核；他负责 5.10 版本，Rumancik 负责 5.15 版本，Rajendra 负责 5.4 版本。该会议旨在作为一个研讨案例，因为其他文件系统（和其他子系统）也存在类似的问题。他对内核稳定版分支维护者 Sasha Levin 参加会议表示“非常高兴”，因为这样他可以提供自己的观点。

History

他在幻灯片上展示了一张 XFS 补丁移植回 stable kernel 的示意图（见下图）；该图显示了过去五年的开发情况，线条显示了六个不同稳定内核中每个内核的累积移植数量。他解释说，这基本上是一个时间序列图（time-series plot），他试图将 stable-tree 中的 XFS 活动按这个图来说明。

[XFS 图表]

他说：“我们可以从中看到一些特别的信息。”图表显示，五年前的 XFS 移植回稳定内核处于“OK 时期”，但在水平轴上对应于发布 5.10 内核的“0”座标原点附近，图表的曲线在相当长的时间内保持平缓。图表上还显示，在 4.14 和 4.19 内核对应的“-100”附近，往回移植的数量减缓了；那个时候，XFS 维护者和 stable tree 维护者之间针对 stable patch 的测试流程发生了一些争论。测试过程已经建立，但 Levin 需要一些时间来实施；他还主持了一个关于该问题的会议。

Goldstein 表示，5.10 版本发布后的长时间停滞并不是由于什么重大争议引起的，而是由几个不同的因素组合而成的。那个时候 XFS backport 存在一些问题，他在去年的 LSFMM+BPF 会议上的有关测试和 stable tree 的会议中提到过。Levin 改变了 XFS patch 在进入 stable kernel 之前需要留在 mainline 的时间，从而希望解决这一问题，但真正的问题出在其他地方。

实际上，Levin 无法完全及时地来维护他的测试基础设施、处理 fstests 的改动以及运行测试工作。所有这些工作都占用了太多的时间。他那时还换了一个公司，这也是一个因素。XFS 维护者设定了较高的测试标准，但却没有人来执行这些测试，所以在接下来的两年里没有进行任何 XFS backport 工作，Goldstein 说。

那些使用 5.10 版本的发行版用户中没有任何人意识到他们所使用的“stable kernel”并没有及时获取 XFS 的最新 fix。他说，没有人告诉他们 XFS 是一个得到良好维护的文件系统，不过却处于停滞状态。去年的峰会上，他、Luis Chamberlain、Rumancik 和其他人共同设立了一个新系统，由三位维护者来领导负责各自不同的稳定内核。

5.15 版本的工作由 Rumancik 所在的雇主 Google 支持，而 5.4 版本的维护由 Rajendra 所在的雇主 Oracle 支持；这两个公司都有在这些稳定内核中支持 XFS 的业务需求，Goldstein 说。另一方面，对于 5.10 版本的维护来自社区；他最初开始从事这项工作是因为他所在的雇主 CTERA Networks 有这方面的需求，但现在他是自愿参与这项工作。他还利用社区来获取了 Chamberlain 的 kdevops job 和用于运行测试的机器资源（由三星提供）；如果没有这些资源，他对工作虽然有兴趣，但却无法完成。

在这种新的维护模式出现之前，Goldstein 曾为他的公司进行 backport 工作，但无法进行所需的测试，从而将 fix 程序引入 stable release。公司需要为他们关注的内核提供维护支持，同时也需要为社区中的测试提供资源。这将使得维护"像 5.10 版本这样独立的发布版本"成为了可能。此外还存在一个问题，即谁会负责相对较新的 6.1 LTS 内核的 XFS 维护。

Ad hoc backports

Rumancik 表示，stable tree 的 backport 处理在很大程度上来说是一种临时处理方式。fix 程序的作者有时会将 fix 程序 backport 到需要 fix 的稳定分支中（某些或全部分支），但有时他们可能完全没有这样做。Fixes tag 和/或发送邮件抄送 stable mailing list 都可能是完全依赖作者的意识的。由机器学习系统选择的 AUTOSEL patch 可以填补这一空白，但并非所有 patch 都会被合入。

[Leah Rumancik]
无法干净地合入的 patch 通常就会丢失，因为没有人跟进相关的报告。有些 patch 可能能够被合入，但却没有被人留意，因为缺少某些关键的先决条件。fix 原本是可以做到的，但 patch 却只是被搁置了起来。XFS 的想法是 stable kernel 维护者可以更密切地关注可能适用的 patch；由于他们熟悉 XFS 和特定一个版本的 stable kernel，因此他们可以 backport 并测试这些 fix 程序。他们通常会批量处理一些 fix 程序，通过测试流程来运行它们，然后将其发布到 XFS 邮件列表；如果在几天内没有出现问题，这些 patch 将被发送给整个 stable-kernel 的全体维护者们。

此时，Darrick Wong 通过 Zoom 链接加入会议，向与会者介绍了 Oracle 在"长期支持内核（LTS）"方面的进展。Oracle 过去采用 "经典的 Linux 发行版模式"，也就是选择一个内核作为其企业内核的基础，然后随机地合入一些 patch，并将最终产物发布给客户。近年来，该公司改变了其流程，开始使用 LTS 内核以及其具有的所有的 patch；所有发布出来的稳定内核的 fix 最终都会在企业内核中发布，"在我们有空处理的时候"。

他听说 stable 维护者有一点抱怨，就是很少有公司愿意站出来表示其产品基于 LTS 内核，并愿意为这些内核提供维护和 backport 工作。他重申 Oracle 确实使用了 LTS 内核；他们选择了偶数年的 LTS 版本作为企业内核，并且公司"非常愿意在 "自己具有经验和知识的内核部分来提供开发支持，包括文件系统和存储"，Wong 说。

现在已经达到了这样一个效果：通过将 fix 程序 backport 到其所基于的 upstream stable kernel （而不是经过内部的 bug fix 流程），反而更容易在企业内核中修复问题了。Oracle 致力于确保 LTS 内核保持在近期 "一段时间" 更新过；他听说 LTS 内核的支持窗口可能会缩短，不再是目前的六年周期了，但 Oracle 希望不要减少太多。该公司意识到稳定内核的工作"确实需要相当多的工程师时间以及一些云资源"；他指出 Oracle 是云供应商，因此也可以提供一些资源。

作为上游 XFS 维护者，Wong 表示非常感激这三位 stable 维护者承担了这项任务。他勉强跟得上 mainline kernel 的步伐；事实上，他说他是导致了图表中两年停滞的一个因素，因为当时他忙不过来了。Oracle 内部已经进行了一些讨论，讨论的内容是要不要继续像现在这样为企业内核挑选 patch，还是说更合理的做法是将 XFS 的整个新版本都"强制推入（forklift entire releases）"较旧的内核中。关于最新版本 XFS 的变化，他们通常给出的回答是"哈哈，folios"，这似乎使得通过这种方式更新 XFS 变得太困难了。

Other filesystems

Matthew Wilcox 表示，如果有需要，他可以负责维护一个旧内核的 folio 兼容层。这不仅对 XFS 有好处；如果 ext4 或 Btrfs 想要将新版本移植到旧内核，这些开发人员也应该跟 Wilcox 进行讨论。James Bottomley 表示，这不仅适用于"强制推入"，folio 的改动侵入性非常大，以至于未来通常的 fix 将更难以 backport。如果没有某种兼容层，适用于 folio 内核的 patch 就无法合入较早的非 folio 内核中去，那些 diff 会完全无法找到匹配的地方。

Ted Ts'o 表示，这是他希望为 ext4 招募 stable backport 维护者的原因之一，就像 XFS 团队一样。他认为这对于初级开发人员来说是参与内核开发的一种很好的方式，不仅仅是尝试修复 syzbot 的错误。如果有公司希望让员工了解 ext4，将 fix 程序移植到 stable kernel 就是一个非常合适的起点。这对社区来说是一项伟大的服务，比诊断 syzbot crash 更加容易一点；因为有人已经 fix 了这个 bug，所以 backport 只是将这个 fix 程序移植过来。

除此之外，近期在 ext4 的稳定版 backport 方面出现了更多问题，因此他开始认同 XFS 维护者的观点。有时他会忙得无法应对，以至于关键的 bug fix 因为他没有足够的时间来调查而被忽略了。依赖 stable kernel 进行 security fix 的用户可能没有得到他们所期望的结果。

虽然这个峰会可能不是一个适合招募 ext4 stable backport 团队的地方，但他认为与会者可能认识其他对学习文件系统感兴趣的人。这种工作是一个很好的方式。Rumancik 表示，这是一个"一口一口的学习方式，因为你会得到一系列 patch，可以深入研究这个领域"，所以不会太过于压力山大。您还可以关注其他更近期的 stable kernel 中的相应补丁，这也是有帮助的。

Rumancik 继续说，还有一些需要改进的地方，包括更容易确定 stable backport 的候选 patch；她知道每次都抄送 stable mailing list 会有一些让人抗拒，但它确实有助于提醒维护者。此外，开发一个标准的测试程序并加以采用也会很有用；目前对于需要测试多少次 fstests 以及需要测试多少个不同的环境才可以被接受，人们的观点还不一致。

Chamberlain 表示，如果能够看到 AUTOSEL 工具为 XFS 选择的 patch 将会有所帮助。由于来自 XFS 维护者的要求，这些 patch 没有自动被采纳以及合入，但可以作为应该要考虑 backport 的 patch 的来源来作为参考。如果有相关输出内容的话，XFS stable 维护者可以 review 这些 patch。

Rumancik 表示她有兴趣来研究一下。Levin 表示，已经在 KVM 和 x86 子系统代码的部分实施了这个功能；patch 发送时会带有 MANUALSEL tag。他注意到在过去几个月中，这类 patch 的数量已经大幅减少了，可能是因为这些子系统在由于 MANUALSEL patch 的帮助下使得他们更加擅长 tag 自己的 patch 了。因此，已经存在进行此操作的基础设施，Levin 表示。

Chamberlain 问是否可以在其他地方复制这个基础设施进行实验等，但 Levin 警告说，"AUTOSEL 是一堆技术债"。例如，它运行在旧的 Azure 虚拟机上。Chamberlain 和 Levin 计划合作来使基础设施更加容易让更多人接触到。

Bottomley 说还有一个"未解之谜"；Wong 举手表示 Oracle 将协助 LTS 工作，但其他一些在峰会上有代表出席的发行版却没有跟进。其他这些发行版拥有大量的人员团队进行 fix 的 backport；如果能整合这些资源将会带来好处。

Goldstein 表示，在过去的五年中，越来越多的企业发行版开始使用 LTS 内核。他说，Oracle 和 SUSE 都已经切换，只剩下 Red Hat 仍然是唯一一个不基于 LTS 内核的企业发行版。但 Jan Kara 指出，SUSE 仍在使用（非 LTS）5.14 内核，并且会对该内核进行大量 backport。这些 backport 对其他内核，如 5.15 或 5.10，也可能具有价值。Michal Hocko 表示，可以从 SUSE 的 kernel tree 查看已进行的 backport 以及详细信息来说明它们是如何实现的。

此时，会议已经超时，因此 Rumancik 快速回顾了 XFS 采取的方法的一些好处，这些方法可以应用于其他文件系统，比如 ext4。将改动都批量处理并一起进行测试可以提升一些效率；此外，与其他团队成员和它们对其他分支的 backport 来紧密合作，可以使整个过程更加容易。Wong 总结会议时指出，Fixes 标签极大地帮助了了 backport patch 的过程，但给 fstests 添加一个相关的 regression test （回归测试）并指向相关 patch 也是引起注意的另一种方式。

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

欢迎分享、转载及基于现有协议再创作～

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