LWN: Linux稳定分支状况以及相应测试

点击上方蓝色字关注我们~

Testing and the stable tree

By Jake Edge
May 28, 2019

---

LSFMM

Sasha Levin在2019 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM)上有一个全员议题，是关于Linux stable tree（Linux稳定分支，通常会维护若干年，持续进行bug fix）的。Levin认为这里主要需要关注的是怎样进行测试。他希望能讨论一下如何进行更多更好的测试，来减少公众对stable tree的担心。

Levin主要强调了stable tree的两个特性：更新过程中的regression（质量退步）在所难免但是stable tree的regression会更少；所有的bug fix都会通过stable tree来发布给用户。他有时候需要找到那些没有被显式标注出来需要stable tree合入的bug fix，此时他使用了机器学习的方式来找到潜在的需要合入stable tree的bug fix patch。这些patch会被他亲自review之后，发到相应的mailing list上去。如果一周内没有人反对的话，这个patch就会被合入stable tree，再经过一周的review之后，就会最终发布给用户。

有人担心stable tree里的更改太多了，加入太多patch的结果，就可能会让stable tree变得不那么稳定了。他非常不同意，因为事实上并不是patch数量超过某个限值之后kernel就会不稳定。稳定性主要还是取决于对这些patch的测试情况。

Levin留意到Darrick Wong和Dave Chinner（他们两人都没有参见今年的LSFMM）都曾经表示对测试方面的一些担心，因此他一直在跟这两位合作来改善stable tree上的XFS和其他文件系统的测试。Luis Chamberlain（此前是Rodriguez）也在开发一个名为oscheck的新工具，能够在各种kernel配置环境下用xfstests来测试stable patches。目前oscheck只是针对XFS测试的，不过Levin很希望能扩展到其他文件系统，然后集成到KernelCI项目里去。

关于测试I/O（或者说存储设备）以及内存管理模块，他暂时也没有什么好方案。blktests框架可以用于测试storage，他还没有深入看过。此外他也从来没有听说过什么内存管理方面的测试。

Michal Hocko觉得Levin所说的那种利用机器学习决策来把那些最新开发出来的内存管理的patch移植到stable kernel上，这种方法不是很好。内存管理模块的开发者通常都会很仔细对patch判断是否适合stable tree，也就是说，Levin再挑一些进来的话，可能会引入风险。

他也认为并没有什么测试来暴露出regression（质量回退）现象；除非你在这些kernel上面测试真实世界里的各种任务，否则不可能暴露出问题。此前已经有过几次事件都是可疑patch被加入stable kernel了，所以他觉得自动选择patch的方案应该不要继续使用了。SUSE就曾经发现stable tree有时候会引入一些稳定性问题，他觉得每个patch一定要经过专家的思考来决定是否合入stable tree。

Levin赞同内存管理模块的开发者在标注哪些patch适合stable kernel这件事情上做的非常不错，去年他只额外增加了26个patch进stable tree。他也认为，用户可以理解stable kernel上有时也会出现一些问题，不过他们更怕的是kernel的大版本升级。只要改动很小的话，用户通常不是太怕。假如开发者只是把那些比较吓人的大改动放到新的kernel版本里面，那么用户就基本不敢升级了。现在还有用户在用2.6.32 kernel。

Rik van Riel问，如果发行版不用stable kernel的话，谁会用呢？Levin提到像Red Hat和SUSE这样的企业级发行版都没用stable kernel，不过Canonical, Andriod和其他一些公司都在用。

Steve French提到，已经有好几个文件系统都在定期进行xfstests测试了，包括ext4, Btrfs，SMB/CIFS。在他看来，可以接受对stable kernel加入更多patch，不过他想要一个机制，能够通知文件系统开发者需要针对某些patch重新运行一次regression test了。这样开发者就可以根据stable tree的维护者提供的分支信息来触发这样的一组测试了。

French还说，虽然文件系统开发者可以接受这样的模式，不过通常他们不知道什么时候stable kernel会发布。Levin觉得有需要的时候他可以延长release前的测试时间。此外现在已经有一些stable候选版本的自动便衣和自动测试了。French提醒，测试SMB/CIFS通常需要7个小时，不清楚ext4和Btrfs的测试时长，不过很可能是差不多量级的。

Ted Ts'o觉得还是要加强自动化处理。例如他目前是先看到stable release-candidate的通知邮件，然后自己手动下载编译kernel。等这些步骤完成之后，测试就很简单了，他有9个虚拟机来运行2到3个小时完成测试。然后需要人工来检查测试结果。如果全部都自动化了，或者能雇人来做这部分工作，那就不是什么问题了。自动化是最有可能的方案了。

Levin又提及了一下Chamberlain做的oscheck工具。Ext4和oscheck结合会很有用。他们也都希望能确定后续流程如何让更多文件系统也加入进来。只要对ext4等文件系统分别确定一个“例外清单”就可以了（例如xfstests就不需要运行）。这个例外清单还会随着bug fix、新功能等的开发进程而变化。Levin认为Chamberlain的oscheck能很好的处理这些情况。

Chris Mason好奇为什么Intel的O-Day automated testing没有用在这里呢？而要创建一个新的工具来做类似的事情？Levin支出Intel工具的代码只是部分开放的，所以他主要在跟完全open source的KernelCI合作，希望能最终集成进去。Chamberlain支出0-Day自动测试已经包含了xfstests，不过它不是很容易支持刚才提到的“例外清单”。

Levin认为目前看来，运行测试的资源并不缺乏。例如KernelCI既有资金，也有资源能进行测试。自动测试就更加便宜了，不过还是需要有专家来审查代码的，而在内核某些模块里找到有空的人来review代码是一件很难的事情。内存管理模块就是如此。所以能有自动测试来保证至少这个stable candidate版本是能工作的，也就很有价值了。

Mel Gorman觉得很难提出满足这种需求的测试方案。关于内存管理模块，一轮基本测试就需要一到两天，而更详细一点的测试需要三到四天，最完整的测试（严格意义上说还是不够完整的）就需要两周左右的时间了。这些测试还需要很多CPU时间，虽然他们都是全自动测试的。Levin觉得3天左右的测试时长还是可以接受的。

Gorman说，内存管理子系统这边很多错误会表现成performance问题，因此需要用各种方法来测试performance。因此测试结果的微小差别都需要注意，不像其他模块的测试集里只需要简单关注pass或者fail。完整的MMTests就需要三周的时间。Levin认为如果有方法能简单判断出来当前版本的质量回退“不大”，那就可以发布出去让用户开始使用了。

回到文件系统测试的话题，Ts'o认为管理“例外清单”会是一件很头痛的事情，不像是Chamberlain一个人能解决的问题。这些文件还需要有各种清晰的注释来讲清楚为什么这个case要被跳过。做这种测试就需要持续不断的投入人力了。Chamberlain也赞同，他目前只处理了XFS，需要其他人来处理其他文件系统的“例外清单”。与会者也讨论了一下是应该用一个白名单还是黑名单。Ts'o认为如果用白名单的话，人们忙起来就不会记得更新这个清单了，新的test case就可能迟迟没有加入这个测试。用黑名单的话，因为新的test case会报出错误，这个通常会引起大家注意，因此名单会更新的更加及时。French认为非常有必要能既有白名单又有黑名单。此外还需要能测试各种不同的kernel configurations。Levin提醒大家，既要用黑白名单，又要加上各种kernel configuration的组合，对每个kernel版本来说要测试的组合就太多了。没有人会直接在生产系统里使用Linus Torvalds发布的内核，除了在他们自己的laptop上做实验的时候。Amir Goldstein从其他测试项目上（例如Linux Test Project, LTP）得来的经验是测试程序本身也会有bug。LTP会标注它所能支持的最小kernel版本，不过仍然会碰到一些意料之外的错误。Chamberlain介绍了他的方法，就是先运行所有test case，然后记录一下哪些fail了、原因是什么。不过Ts'o认为这可能不是一个对所有情况都适用的方法，例如在某些kernel config情况下xfstests可能会让kernel crash，还有的情况是某些test case在一些特殊config（例如1KB的block size）情况下运行时间会过长。所以“例外清单”里面的每一项都需要详细记录。

因为时间差不多到了，Levin没法继续讲了，他本来想能跟参会者多了解一下大家都有些什么测试能愿意加入KernelCI的。只要能加入KernelCI的测试框架，stable team就能够让release candidate（待发布版本）进行更好的测试，在发布前检测出是否有质量回退。

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～