存储架构

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

微信扫一扫,分享到朋友圈

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

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搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

阅读原文...


微信扫一扫,分享到朋友圈

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

Avatar

阿里出行局: 输了战役,赢了战争

上一篇

这大概是今年介绍云原生最清晰明了的文章!

下一篇

评论已经被关闭。

插入图片

热门分类

往期推荐

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

长按储存图像,分享给朋友