xfstests文件系统测试

测试目的

用xfstests工具测试手机文件系统目的有两个

1：保障项目组提的性能优化changes不会对文件系统的稳定性产生不良影响。

2：用xfstests工具来尽可能地多发掘一些潜在的手机文件系统稳定性问题。

测试对象

xfstests测试工具测试的是Android底层内核里面的文件系统（比如ext4, f2fs等）功能完整性，还有内核的整体稳定性和健壮性。

测试时，会用chroot的方式，替换掉Android用户态涉及的所有程序，用自己定制的根文件系统环境进行测试。

所以xfstests不会测试Android用户态的东西，只会测试底层内核。

测试前的准备工作

1：测试主机环境：ubuntu。

 待测试手机cpu必须是arm64架构的，并且可以在Ubuntu端进行adb root && adb shell登录成功。

2：下载xfstests测试工具

把网盘的xfstests-bld.tgz下载到Ubuntu主机端并解压。

3：下载高版本的fastboot和mke2fs工具，并替换主机现有的fastboot和mke2fs工具。原因如下：

  1)：xfstests测试中，要用到fastboot工具。现有的fastboot工具如果版本低的话，可能不支持f2fs文件系统的测试工作。

  2)：xfstests测试中，fastboot工具需要用到mke2fs工具进行格式化userdata分区。所以主机现有的mke2fs工具也要被替换。

4：为了测试手机文件系统数据稳定性（目前碎片整理和文件系统fsync优化均需要测试），开发人员还要对测试手机做下面changes的适配工作。

    add kernel config item for xfstests

    http://gerrit.pt.XXX.cn/#/c/XXX

    适配完后，测试带相关change重打包，刷机后即可进行数据稳定性测试了。

   适配change原因：

  1）数据稳定性测试项对应的是generic里面的带有log标签的测试case集，该测试集需要对应手机内核开启dm-flakey, dm-log-writes, sysvipc这三个特性配置，而很多手机内核缺省并未开启这些特性配置。

  2）上面change是对XXX-Q手机新增了数据稳定性测试项目所需要的这3个内核特性配置。

测试方法

1：测试方法

手机上带性能changes和不带性能优化changes两个安卓rom各进行一次xfstests的测试工作。

1> Ubuntu主机上输入如下测试命令，开始进行对手机进行xfstests测试工作。

cd xfstests-bld && ./android-xfstests.sh -c XXX -g auto

 备注：

 a) XXX选取

 ext4文件系统里面，XXX为4k

 f2fs文件系统里面，XXX为f2fs.

 b) -g选项说明

 -g选项后面可以跟auto组，也可以跟quota等其他功能组。

 c) 单测某条case的操作方法

 ./android-xfstests.sh -c XXX generic/001

执行上面命令，可对xfstests的generic/001号case单独进行测试。

2> 终端屏幕最后输出：

........

logfile in XXX

........

如见上面成功输出"logfile in"字眼，则代表测试成功结束。

测试结束后，带优化changes和不带优化changes的各自测试log都会保存在kvm-xfstests/logs/log.XXXX里面.

2：测试结果梳理

上面的log.XXX最后会输出如下的测试结果：

Run: f2fs/001 generic/001 .....

Not run: generic/018 generic/034 .....

Failed XXX of YYY tests

Passed all 21 tests

Run代表总共运行了多少测试case，Not run代表没有运行的测试case（多半是测试工具太旧或者手机内核不支持某方面的功能特性）

Failed XXX 代表有多少case 测试失败了，Passed代表有多少case测试成功了。

3：测试数据提供

测试人员需要提供给开发人员的信息：

1）要对带优化changes和不带优化changes输出的上面测试结果进行比对，把比对差异提供给研发人员作分析定位，以此来发掘优化changes是否对文件系统稳定性有无不良影响。

2）xfstests测试过程中，会导致手机宕机的测试case 要第一时间提供给开发人员做稳定性问题发掘分析。还有带优化changes和不带优化changes各自生成的log.XXX也要提供给开发人员，

以便以后有助于bsp组那边对文件系统稳定性做进一步地问题发掘工作。

4：failed case原因定位

1）基本定位

对于测试失败的case，可以结合上面的log.XXX文件，case自身的脚本文件，case本身的期望输出结果文件和实际输出结果文件来定位测试失败原因。

以generic测试项中的失败case原因定位为例：

case自身的脚本文件位于手机/data/xfstests-chroot/root/xfstests/tests/generic/XXX中。

期望输出结果文件位于手机的/data/xfstests-chroot/root/xfstests/tests/generic/XXX.out中。

实际输出结果文件位于手机的/data/xfstests-results/f2fs/results-default/generic/{XXX.full和XXX.full.bad}中。（XXX为测试case编号）

2）特殊定位

测试过程中会出现意外终止现象，多半是由于手机内核出现崩溃了。这时需要调查测试失败的原因，看看是否是手机文件系统bug导致的。

可以等手机重启完毕后，查看/sys/fs/pstore/console-ramoops-0文件，来定位内核崩溃的原因。