xfstests保障文件系统稳定性

背景

存储是高风险作业。一旦有文件系统相关问题后，发生内核panic，手机进入ramdump这还影响不算大。如果导致用户文件数据损坏的话，就会造成比较大的影响。

以前对文件系统源码修改后，由于没有一款专门针对文件系统的测试工具，所以只跑mtbf或者kasan的话，文件系统的稳定性问题是无法被有效地发掘的。

现在有了xfstests, 文件系统的稳定性方面可以得到强有力的保障。

xfstests保障文件系统稳定性方面的见证：

1：我这边用xfstests generic/204号case 测试Android Q的手机，发现了该机型f2fs源码的缺陷。该缺陷会导致手机内核panic。

2： xfstests里面有专门针对文件系统的quota, 碎片整理，意外掉电文件系统稳定性等方面的测试case，非常适合手机场景的稳定性测试。

     与此同时，mtbf, kasan并不能像xfstest一样专门针对文件系统各个功能点（前面说的quota,碎片整理等）进行测试。

工具简介 

xfstests是一款可以对文件系统进行稳定性测试的工具，支持对ext4，f2fs等多款文件系统进行测试。

xfstests的介绍：

https://github.com/tytso/xfstests-bld/blob/master/Documentation/what-is-xfstests.md

xfstests在安卓平台上的使用介绍：

https://github.com/tytso/xfstests-bld/blob/master/Documentation/android-xfstests.md

工具使用

xfstests的使用方法：

xfstests有很多配置选项，测试必备的，用户必须手动指定的测试项是-c和-g选项。

-c选项

选择不同的文件系统配置文件进行测试，例如“-c 4k”表明是选择4k配置文件进行测试的。

1) 该选项作用

xfstests测试时，必须首先选择一个文件系统配置文件进行测试。

该配置文件会影响到xfstetes建立测试分区时对应的MKFS_OPTIONS和MOUNT_OPTIONS。

选择不同的配置文件，上面这两个options都不同，从而具体每条case测试时所处的文件系统环境也不同。

2) note 

xfstests测试工具的kvm-xfstests/test-appliance/files/root/fs目录下面列出了各个文件系统测试时可供选择的不同配置文件。

例如对ext4文件系统进行测试时，可选择的配置文件在上面目录的下一级ext4子目录下面。

有些配置文件不适合用来测试手机业务。

从符合手机业务场景需求角度出发，测试ext4文件系统时，可以选择4k，encrypt, fast_commit,quota,metacsum等这些配置文件。

测试f2fs时，目前只有一个default配置文件。

-g选项

选择不同的测试group进行测试，例如“-g auto”表明是选择auto这个group里面的测试case进行测试的。

1) 该选项作用

因为xfstests有很多的测试case，并不是所有的测试case都需要进行测试。所以对每条测试case贴上了一些标签，代表该case属于哪些group。

这样根据测试需求，只选定某个group里面的case进行测试。

详见测试用的kvm-xfstests/test-appliance/root_fs包里面的root/xfstests/tests/{f2fs，ext4，generic}三个子目录下面的group文件。该文件就对每个测试case注明了属于哪些group。

不同group是按照测试功能点进行区分的。比如有quota, log，defrag这3个不同的group，分别对文件系统的quota，断电数据完整性，碎片整理3个不同的功能点进行测试。

2) note

通过查看上面说的group文件，也可以快速辨别出测试case是否适合手机业务场景。

比如看到下面内容：

437 auto quick dax

就知道437号测试case是测试文件系统dax相关的，手机场景并未开启dax。

工具实现

目前的xfstests已经整合到xfstests-bld框架中了。这样使用xfsetests测试Android手机会更加方便。

xfstests-bld的设计思路是为了满足xfstests在虚拟化，Android平台等多个不同业务场景下的测试需求，将xfstest测试工具本身，还有测试所需的最小系统环境都从xfstests中独立出来，做成一个rootfs。

这样再辅助一些外围上满足前面所述的不同业务场景需求的定制化脚本，xfstests-bld就可以做到一套测试集能够兼容测试多个不同的业务场景。

rootfs介绍

上面说的rootfs，里面包含了xfstests能运行起来的最小系统环境，比如有一些测试case会经常用到的ls， chmod，dumpe.f2fs等bin文件。

业务场景如果有特殊需求，需要对其做定制化操作。比如Android手机场景中，需要在手机中chroot到该rootfs提供的系统环境中进行测试，所以需要传递chroot相关的定制需求给rootfs。

rootfs的定制化操作:

https://github.com/tytso/xfstests-bld/blob/master/Documentation/building-rootfs.md

xfstests介绍

xfstests测试工具本身则位于rootfs里面root子目录中，该工具是专门用于实现文件系统自身的稳定性测试。

具体测试时，会碰到比如fio工具版本比较老，导致测试case not run这类问题，需要对xfstests做版本升级和定制化操作，具体操作见下面链接。

xfstests的定制化操作：

https://github.com/tytso/xfstests-bld/blob/master/Documentation/building-xfstests.md

测试case实现

1）总体架构

xfstests的测试case会首先按照具体文件系统的不同，归成几大类。具体见xfstests/tests下面的子目录构成。

这一层次归类中，还有generic和shared. generic代表各个文件系统都需要跑的测试case，shared代表只有部分文件系统需要跑的测试case。

然后具体每个文件系统里面，还有generic里面，会对各个case进行归类分组，每个测试case可以同时属于多个组，详见group文件里面对各个case的标签定义。

2）case脚本实现

每条测试case的工作内容都在其对应的脚本文件里面。

比如generic 022号case，对应的脚本文件在xfstests/tests/generic/022里面。

脚本文件里面的大致实现内容可以分为以下几个部分：

1> case 功能简单描述

2> include一些公共环境变量和公共函数实现

3> 检查手机的文件系统以及整个os配置是否符合测试需求

4> 具体测试工作部署

note:

有些not run的测试case，大多是在上面步骤3>中检查没有通过，所以case无法继续运行。

脚本文件里面调用的公共函数具体实现一般是在xfstests/common/rc里面，其他函数具体实现脚本文件中没有找到的话，都是放在xfstest/common中的。

3）case通过与否的评判标准

Test number $seq is deemed to "pass" when:
(a) no "core" file is created,
(b) the file $seq.notrun is not created,
(c) the exit status is 0, and
(d) the output matches the verified output.

上面这个标准引用自下面的文档

xfstests/README

https://github.com/tytso/xfstests/blob/master/README