LWN: storage testing杂谈

Storage testing

By Jake Edge

May 28, 2019

LSFMM

在2019 Linux Storage, Filesystem, and Memory-Management Summit上，Ted Ts'o组织了一个专注于Storage testing方法的讨论。他介绍了他使用blktests来验证的一些经验。他其实一直持续在他的自动测试平台里添加更多的test case，blktests就是其中之一。因此他也希望大家交流一下各自都有什么样的存储测试方案。

Ts'o近期在做两方面的测试：NFS测试，以及blktests。Google近期在给客户推荐具有NFS功能的云服务，因此他（作为Google员工）开始着手研究NFS的测试。这个过程中，他找到了NFS wiki page上一段介绍如何用xfstests来进行NFS测试的文章，非常有帮助，详细介绍了测试环境，以及xfstest进行NFS测试中各种可能碰到的问题。非常推荐大家一读，也建议各个文件系统的开发者都可以参照着写一些类似步骤来推广自己的文件系统测试。此外他近期也在调查一个问题，看起来像是xfstests里面的ext4测试失败，但其实最终 运行blktests 查出来是SCSI的multiqueue (mq，多队列）代码里的问题。他很希望今后能更容易的区分是文件系统问题，还是块设备层问题，因此他把blktests集成到自己的test suites里面了。这个过程中他意识到blktests其实还是很年轻的工具，他碰到的一些问题，很快都在新版本里面得到了改善。而他看到的blktests最大的问题是：每个test的结果是否成功，不是很清晰。他列举了一些测试结果他认为是失败了，不过他也不是块设备层的专家，所以不是非常确定。有一些测试失败是因为lockdep，也就是kernel的问题，不过其他的测试失败可能就是他的环境问题了。总之很难轻松得出结论。

举例来说，NVMe测试，总是对NVMe的版本很敏感。有些测试，只有在他用到的最新版本的nvme-cli工具之后才能pass。这个版本的nvme-cli甚至还没有正式发布。此外，测试中也需要一些特定的kernel configuration，没有文档详细列出来。Blktests需要某些kernel功能编译成Module形式，否则测试就会fail。他不断的试错之后，最终确认出来有38个module是必须的。

Ts'o计划把他的kernel configuration文件合入xfstests的代码里面，这样其他用户就能利用这个版本来省些时间了，不过肯定会需要持续维护这个文件。相信会对blktests发展新用户会很有帮助。现在，他的测试环境还是比较杂乱，计划很快会清理干净，至少已经能让大多数的blktests都pass了。

kernel开发者很希望有更多的人和自动测试环境来跑blktests，这样能节省kernel开发者的时间。因此需要想办法减少人们跑blktests的障碍。就像现在Ts'o有了一个能正常跑blktests的image之后，他就可以给其他测试者来测试他们自己的patch了，这样Ts'o的时间可以剩下来不少。

Ric Wheeler问道，这个测试中有多少种类型的设备经过测试？Ts'o介绍说NVMe和SCSI blktests大多数情况下是用loopback模式测试的。也有一些测试使用了虚拟设备，可以在VM（虚拟机）里运行测试。Wheeler认为还是需要测试真正的设备，而不光是测试虚拟机的虚拟外设，毕竟行为还是不完全一致的。Ts'o表示赞同，能有更多设备来做测试当然更好，不过创造这样的条件还是挺难的，他是在笔记本上运行的测试，肯定不希望损害自己笔记本硬盘的寿命。

Blktests的维护者Omar Sandoval介绍说，blktests的目的是测试软件，而不是硬件，所以很多测试是用loopback模式测试的。有些测试确实需要真实硬件，其他的测试在没有真实硬件的情况下来退而求其次的使用虚拟机的虚拟设备，或者loopback模式测试。Wheeler认为这样的话，驱动程序并没有真正被测试到。Chris Mason认为这里的核心想法是尽量减少每个人的测试障碍，确保他们的代码改动没有影响块设备层代码的核心部分。他更建议用0-day开发模式，就是每个人提交的代码改动如果导致测试fail了，就应该马上得到通知。这样maintainer（维护者）就不需要叫每一位提交代码的开发者都要自己运行测试了。

Ts'o也认为确实应该有一些核心的测试集应该按照这个0-day模式来时刻运行，发现问题。不过目前他的test需要18-20小时才能完成，这个对0-Day模式来说没法接受。可能应该挑选一些基本的test case更加合理。他的计划是请提交ext4 patch的开发者都自己先跑过这个18-20小时的测试，否则他不会考虑合入他们的patch。

Wheeler觉得可以再加一些device-mapper（译者注：就是把一个设备映射成另一个设备供文件系统使用，类似一个抽象层，常用于加密磁盘的场景）测试到blktests里。Sandoval提到device-mapper开发者确实有计划添加test case，不过暂时还没有好。Damien Le Moal也赞同需要device-mapper的test，应该可以很容易把一个普通块设备映射成device-mapper设备来跑普通的test case即可，这里其实是一个test配置环境的问题，而不是要开发一组新的test case。只要针对这些各种测试对象，有一组标准测试环境，那就够了。

Ts'o这边对ext4加密以及NFSv3都有一些类似需求，会需要先配置好相应的测试环境，才能让blktests开始运行起来。这里有个值得思考的问题，这些配置应该让blktests来做呢，还是做一个wrapper script来包装调用blktests？xftests采用的就是wrapper script的方式，可能blktests也可以类似处理。重点是要确保不需要每个开发者都自己摸索一遍怎么设置环境，能用最简单的方法让测试运行起来。Le Moal此前也做过一些类似事情，摸索了一遍怎么搭建环境并记录下来。他希望能把大家的工作综合起来看看是否有什么共同的地方，能节省大家时间。

搭建user-space环境的复杂性也是一个讨论话题。Luis Chamberlain在他的oscheck项目里，需要处理各种 Linux 发行版，各种应用的版本依赖等。他是利用Ansible来管理这一部分。

Ts'o介绍了他的方法，他使用了chroot()方式进入一个Debian环境，准备好所有他需要的东西。这个方法他在各个环境下都试过，包括Android设备上。有些环境下面需要运行blktests，但是Bash版本太老无法运行blktests，他的方案是全部都用chroot()之后的环境里的bash等工具。这样也让他能使用自己编译生成的dmsetup和nvme-cli等命令，而不是使用系统自带的旧版本。

Ts'o直接使用Google Compute Engine来做自己的测试，而Chamberlain想要使用其他的云服务（例如Microsoft Azure），或者其他操作系统环境（例如Windows，macOS）。他计划利用Vagrant（一个利用了 ruby 和virtualbox的虚拟机环境管理维护软件）来解决这个问题，也希望有人参与进来一起试试这个方向。Ts'o认为只要有个chroot()环境，大多数问题都能解决。此外还有一些小问题需要用VM或者测试设备来解决。对他来说，只要KVM能用，就足够了，不过其他人确实也有不同的需求，所以有不同的解决方式也很正常。