xfstests-bld简介

什么是xfstests？

从名字可以推断出，xfstests是一个文件系统回归测试套件，最初，与 XFS 一样，xfstests 仅在 SGI 的 Irix 操作系统上受支持。当 XFS 被移植到 Linux 时，xfstests 也是如此，现在 xfstests 只在 Linux 上被支持。

现在xfstests 被用作所有 Linux 主要文件系统的文件系统回归测试套件：xfs、ext2、ext4、cifs、btrfs、f2fs、reiserfs、gfs、jfs、udf、nfs 和 tmpfs。许多文件系统维护者在将补丁发送给 Linus 之前会运行一整套 xfstests，并且会要求在提交集成之前使用 xfstests 测试任何重大更改。

自己写的文件的文件系统是否需要适配？？？如何做自定义的测试？？？

xfstests 中的单独测试

xfstests 中的测试最初使用三位数字命名。在 2013 年，测试被转移到不同的类别中，具体取决于测试是否用于特定的文件系统、“generic”（意味着它独立于文件系统），还是"shared”（意味着测试不是真正的通用，但很有用）在少数文件系统上）。在此方案中，测试的名称如下：

• List item
• btrfs/126
• generic/013
• ext4/271
• shared/051
• xfs/090
  测试可以属于多个组，例如“auto”、“quick”、“aio”、“prealloc”、“ioctl”和“dangerous”。组中的成员身份可以表明测试的性质。“自动”组表示那些最适合自动测试旋转器的测试。“快速”组中的测试应该完全快速，运行快速组有利于文件系统的冒烟测试。“危险”组是可能导致内核崩溃的测试，因此应小心运行。

其他时候，组成员身份可以指示由测试执行的文件系统功能。这方面的例子包括诸如“aio”、“prealloc”和“ioctl”之类的组。

测试设备

xfstests 测试套件将使用一个或两个块设备；一个名为 TEST 并且必须存在，另一个名为 SCRATCH，是可选的。大多数测试使用 TEST 或 SCRATCH 设备，但是也有一些测试同时使用这两种设备。

SCRATCH 设备由需要使用 SCRATCH 设备的测试重新格式化。个别测试可能不会假定 SCRATCH 设备上存在有效的文件系统。相比之下，TEST 设备永远不会被 xfstests 格式化，并且旨在成为一个长期存在的“固化”的文件系统。

对于大多数 ext4 文件系统配置，TEST 和 SCRATCH 设备应该是 5GB。小于这个值，可能会导致某些测试无法正确运行。大于这个值，测试将需要很长时间才能运行——尤其是那些需要填充文件系统以测试 ENOSPC 处理能力的测试。ext4 有一些文件系统配置（最著名的是 bigalloc_4k），需要 20GB 的测试和暂存设备。

为此，kvm-xfstests 使用五个文件系统设备，/dev/vdb、/dev/vdc、/dev/vdd、/dev/vde 和 /dev/vdf。（/dev/vda 用于根文件系统，/dev/vdg 用于 /results 文件系统。）前两个测试设备 /dev/vdb 和 /dev/vdc 用于 TEST 和 SCRATCH ，分别为标准的、默认的 4k 文件系统配置。/dev/vdd 设备用于与默认的 4k 块 ext4 文件系统不兼容的文件系统配置——例如，1k 块文件系统。由于我们要保持/dev/vdb作为长期文件系统测试文件系统老化，我们使用/dev/vdd代替1k块文件系统，测试运行器将运行mke2fs格式化/dev/vdd之前为该文件系统配置启动 xfstests 运行。为此原因，

/dev/vde 和 /dev/vdf 文件系统是 BIGTEST 和 BIGSCRATCH 磁盘，用于那些需要 20GB TEST 和 SCRATCH 设备的文件系统配置。与 TEST-1K 设备一样，BIGTEST 设备将在为该文件系统配置运行的 xfstests 开始时使用 mke2fs 重新格式化。

gce-xfstests 使用相同的块设备集，尽管 gce-xfstests 使用存储在 GCE 本地 SSD 上的 LVM 的逻辑卷，而不是单独的 virtio 设备。不幸的是，这意味着每次启动 gce-xfstests VM 时都会重新格式化 TEST-4K 设备；因此，我们无法获得针对长期老化的设备测试文件系统的好处。

kvm-xfstests 快速入门说明

1、 确保您的系统上安装了支持 kvm 的 qemu。

apt-get install qemu-kvm
1

2、运行以下命令以安装 xfstests-bld 存储库并下载预编译的测试设备rootfs镜像（root_fs.img），我们在这里使用 32 位测试设备，因为它可以同时支持 32 位和 64 位内核。（也可以自定义编译一个root_fs.img）

git clone https://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git fstests
cd fstests
wget -O test-appliance/root_fs.img https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/root_fs.img.i386
1
2
3

# xfstests-bld repo
https://github.com/tytso/xfstests-bld

# rootfs下载地址
https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/
1
2
3
4
5

windows使用wget的方法：https://blog.csdn.net/screaming_color/article/details/79201199

3、在您check out的 xfstests-bld 存储库的顶级目录中，运行make kvm-xfstests，然后将此生成的文件复制到/usr/bin/目录中。这样可以直接运行kvm-xfstests命令而无需将工作目录设置为 kvm-xfstests 所在目录。

make kvm-xfstests
cp kvm-xfstests /user/bin/kvm-xfstests

# cp kvm-xfstests /usr/bin/
1
2
3
4

4、在 fstests/run-fstests/ 目录中，查看“config.kvm”文件并且根据实际需求配置该文件，或者（这是首选）将覆盖（修改）值放入 ~/.config/kvm-xfstests。如果希望日志文件显示本地时区的时间，可能需要覆盖的最常见值是编译内核的位置和首选时区。

TZ=America/New_York
KERNEL=/build/ext4/arch/x86/boot/bzImage
1
2

5、要构建与 kvm-xfstests 一起使用的内核，确保当前路径为你想要使用内核版本的源码路径，执行命令：

kvm-xfstests install-kconfig
kvm-xfstests kbuild
1
2

步骤5是否可以在任意环境编译然后进行拷贝？？
修改vmlinux镜像文件路径，vim run-fstests/config.kvm，修改KERNEL变量路径为步骤5内核代码编路径

6、运行“kvm-xfstests smoke”进行快速测试。或者“kvm-xfstests -g auto”做一个完整的测试。还可以对特定配置运行特定测试，即“kvm-xfstests -c bigalloc_4k generic/013 generic/127”。要运行 shell，请使用“kvm-xfstests shell”

有关详细信息，请参阅完整的kvm-xfstests 文档。

kvm-xfstests.md

kvm-xfstests：使用虚拟化运行 XFSt​​ests

请先阅读kvm-quickstart说明，因为这将使您快速入门。

如果您对 xfstests 不熟悉，您可能还想阅读xfstests 的介绍。

安装

kvm-xfstests 系统由一系列 shell 脚本和一个测试设备虚拟机映像组成。您可以使用 xfstests-bld git 存储库中的构建基础架构构建映像，但如果您刚刚开始，那么如果您下载一个可以在kernel.org上找到的预编译 VM 映像，将会简单得多 。

您会发现一个名为 root_fs.img.i386的 32 位测试设备和一个名为root_fs.img.amd64 的 64 位测试设备 。该文件应作为 root_fs.img 安装在测试设备目录中。

64 位 x86 内核可以同时使用 32 位和 64 位测试设备 VM，因为您可以使用 64 位内核运行 32 位 ELF 二进制文件。然而，事实并非如此。32 位 x86 内核无法运行 64 位 x86 二进制文件。这使得 64 位测试设备更加灵活。此外，如果您使用具有 32 位接口的 64 位内核，它会测试 32 位 compat ioctl 代码路径，否则可能无法获得足够的测试。

如果您想构建自己的测试设备 VM，请参阅 building-rootfs.md。

设置和配置

kvm-xfstests 的配置文件是 run-fstests/config.kvm。您可以直接编辑此文件，但更好的做法是将覆盖值放在 ~/.config/kvm-xfstests 中。

也许要设置的最重要的配置变量是 KERNEL。这应该指向 qemu 将启动以运行测试设备的内核的默认位置（编译内核镜像路径）。通常，这应该是您用于内核开发的主要构建树。如果 kvm-xfstests 从内核构建或源代码树的顶层运行，那里有一个构建的内核，kvm-xfstests 将使用它。否则，它将使用 KERNEL 变量指定的内核。

要构建一个正确配置的内核以与 kvm-xfstests 一起使用，请运行以下命令：

kvm-xfstests install-kconfig [--i386]
1

（如果您希望构建 32 位内核，请添加 --i386 选项。）

默认情况下，test-appliance 使用的暂存盘会自动设置，并存储在 run-fstests 目录中，名称为 vdb、vdc、vdd、…直到 vdg。但是，使用逻辑卷稍微快一些。为此，覆盖 VDB…VDG 变量：

    VG=closure

    VDB=/dev/$VG/test-4k
    VDC=/dev/$VG/scratch
    VDD=/dev/$VG/test-1k
    VDE=/dev/$VG/scratch2
    VDF=/dev/$VG/scratch3
    VDG=/dev/$VG/results
1
2
3
4
5
6
7
8

如果您选择这样做，VDB、VDC、VDD 和 VDG 的逻辑卷应该是 5 GB，而 VDE 和 VDF 应该是 20 GB 的逻辑卷。在尝试运行 kvm-xfstests 之前，设备 VDB 和 VDG 应该有一个使用 mkfs.ext4 命令创建的 ext4 文件系统。

运行 kvm-xfstests

kvm-xfstests shell脚本在run-fstests目录下，它被设计成与当前工作目录一起运行在run-fstests目录下。为了方便起见，xfstests-bld 顶层目录中的 Makefile 将创建一个 kvm-xfstests shell 脚本，可以将其复制到您的 PATH 中一个方便的目录中。此 shell 脚本将设置 KVM_XFSTESTS_DIR 环境变量，以便可以找到辅助文件，然后运行 ​​run-fstests/kvm-xfstests shell 脚本。

请运行“kvm-xfstests help”以获得可用命令行语法的快速摘要。并未记录所有可用的命令行选项；一些更专业的选项需要您阅读 The Fine Source — 特别是在 run-fstests/util/parse_cli 中的辅助脚本文件中。

运行文件系统测试
在测试设备中运行测试的 kvm-xfstests 命令的一般形式是：

 kvm-xfstests [-c <cfg>] [-g <group>]|[<tests>] ...
1

默认情况下默认为全部，这将运行以下配置：“4k”、“1k”、“ext3”、“nojournal”、“ext3conv”、“dioread_nolock”、“data_journal”、“inline”、“bigalloc_4k”和“ bigalloc_1k”。如果要运行所有可能的文件系统配置的子集，则可以指定单个配置或逗号分隔列表。

可以通过“-g”或通过一个或多个特定的 xfstests 子测试（例如，“generic/068”）使用 xfstests 组指定测试。您将使用的最常见的测试组是“自动”，它运行适合在自动测试运行中使用的所有测试，以及“快速”，它运行为快速冒烟测试设计的测试子集。

为了方便开发人员，“kvm-xfstests smoke”是“kvm-xfstests -c 4k -g quick”的简写，它仅使用 4k 块文件系统配置运行测试的快速子集。此外，“kvm-xfstests full”是“kvm-xfstests -g auto”的缩写，它使用大量文件系统配置运行所有测试。这将需要相当长的时间，因此最好连夜运行。（或者最好使用 gce-xfstests 运行全套测试。）

运行交互式 shell

命令“kvm-xfstests shell”将允许您检查测试环境或手动运行测试，方法是启动测试内核并请求测试设备 VM 启动交互式 shell。

当您退出 VM 时，对根分区的任何更改都将被还原。如果您想永久修改 root_fs.img 组件，您可以改为运行“kvm-xfstests maint”。

您可以通过查看 /root/test-env 文件中设置的环境变量来手动运行测试（当您启动交互式 shell 时，该文件会自动获取）。然后，您可以设置 FSTESTCFG 和 FSTESTSET 来控制要运行的测试，然后运行测试运行器脚本 /root/runtests.sh。例如：

    % kvm-xfstests shell
    # FSTESTCFG="4k encrypt"
    # FSTESTSET="generic/001 generic/002 ext4/001"
    # /root/runtests.sh
    ...
1
2
3
4
5

要停止 VM，您可以运行“poweroff”命令，但关闭 VM 的更快方法是使用命令序列“Ca x”（即，Control-a 后跟字符“x”）。

本地调试端口

当 kvm-xfstests 运行时，您可以远程登录到许多 TCP 端口（绑定到本地主机）。端口 7500、7501 和 7502 将在测试运行时将您连接到 shell 提示（如果您想检查 /proc/slabinfo，启用跟踪等）。您还可以将这些端口与“kvm-xfstests”结合使用shell" 如果你想要额外的窗口使用 ftrace 捕获跟踪。

您还可以在端口 7498 上访问 qemu 监视器，并且可以在本地主机端口 7499 上使用远程 gdb 调试内核。只需运行“gdb /path/to/vmlinux”，然后使用命令“target remote localhost:7499”。

使用远程 gdb 的专业提示：临时将“EXTRA_CFLAGS += -O0”添加到 fs/{ext4,jbd2}/Makefile，并使用通过“kvm-xfstests install-kconfig --debug”启用调试功能的内核配置很有帮助”。此外，您可能需要在 $HOME/.gdbinit 中添加“add-auto-load-safe-path /path/to”行，其中 /path/to 是包含已编译 vmlinux 可执行文件的目录。有关详细信息，请参阅 内核源代码中的Documentation/dev-tools/gdb-kernel-debugging.rst 。

日志文件

默认情况下，当测试结果保存在 run-fstests 目录中时，文件名为 log…

get-results 命令将汇总日志文件的输出。它以日志文件的名称作为参数；如果未指定日志文件，则 get-results 命令将显示最新日志文件的摘要。

xfstests实战

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

从配置文件来看，当前仅支持标准文件系统测试配置文件，要测试自定义文件系统，存在一定的适配工作量。

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。

https://leavatail.hatenablog.com/entry/2022/02/27/120000