在 Linux 内核开发中，文件系统（Filesystem）一直被视为对数据正确性与鲁棒性要求极高的核心模块。然而，随着内核代码规模的迅速膨胀、特性（如 Folios 内存页管理）的重构，以及大语言模型（LLM）辅助编写的补丁大量涌入稳定版内核（Stable Kernels），文件系统的回归缺陷（Regressions）呈现出上升趋势。

在近期召开的 2026 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMMBPF 2026）上，Linux ext4 维护者 Ted Ts'o 和 kdevops 贡献者 Chuck Lever 等资深开发者再次将文件系统自动化测试与测试结果集约化推上了核心讨论议题。

本文将首先带来 LSFMMBPF 2026 峰会关于文件系统测试议题的现场报道，接着深入剖析被视作解决该难题重要工具的 kdevops 框架——涵盖其架构设计、使用指南、演进历史、未来规划及其在文件系统测试中的核心优势。

第一部分：LSFMMBPF 2026 峰会现场报道

稳定版内核的退化困境与测试挑战

文件系统开发者聚会讨论文件系统测试不足为奇；多年来，这一直是 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMMBPF）的固定议题，2026 年的峰会也不例外。Ted Ts'o 主持了本次讨论，他抛出了几个不同的议题，包括他观察到的 ext4 在稳定版内核（stable kernels）中退化（regression）日益增多的现象，以及可以采取哪些措施来减少这种情况。与峰会多年来的其他类似议程一样，大家对协作共享测试输入和输出抱有浓厚兴趣，但寻找一种将这些信息集中化的方法至今仍困扰着文件系统社区。

Ts'o 首先指出，他最近注意到稳定版内核中的 ext4 退化问题有所增加。部分原因在于 ext4 开发者一直在开发对 folio 支持等特性；其中一些补丁“有着微妙的依赖项要求，而自动化工具并不一定会捕捉到这些要求”。

他表示，另一个因素是补丁被更频繁地向后移植（backport）到旧内核中，这可能借助了大语言模型（LLM）的帮助。因此，他看到一些新特性被向后移植到了 6.1 和 6.6 稳定版内核中，从而在这些内核中引入了 bug。其中一些 bug 会导致内核在运行 fstests 测试套件的特定测试时崩溃。由于向后移植的补丁有十几个，因此“要真正找出这些问题相当痛苦”。他想知道其他没有选择退出稳定版内核自动化补丁筛选的文件系统是否也遇到了这类问题。

他已经建立了一个测试运行器（test runner），用于监控即将进入稳定版内核的补丁；它会在应用了这些补丁的内核上运行 fstests。然而，他还没有时间去审查结果并将其与基线进行比较以查找退化。这是他可以实现自动化的工作，但目前尚未完成。

Ts'o 表示，只要能在他的测试运行器中使用 fstests 进行测试的文件系统（“绝大多数都可以”），都可以加入进来，针对稳定版内核的候选补丁进行测试。他有能力承载这些测试，并可以通过电子邮件提供报告，以便让更多文件系统能够针对稳定版向后移植补丁进行测试。他还公开寻觅一名 Python 程序员，希望能开发一个程序来对比两次运行的测试输出，从而找出它们之间的退化。

Ts'o 还花了一些时间为其 xfstests-bld 测试工具开发自动化功能。他添加了对执行 Git 二分查找（bisection）的支持，包括内核在运行测试期间崩溃的情况。如果有人感兴趣，他很乐意协助建立该配置。Kdevops 是文件系统开发者可以使用的另一个选择。他推测，由于 LLM 带来的 bug 报告和补丁，测试活动将会大幅增加；“测试是我们保持主导地位的唯一途径”。

测试数据的共享与中央数据库探讨

随后，他邀请与会者分享他们对文件系统测试的想法。一名与会者建议建立一个测试矩阵和测试结果的共享数据库，并提到这个想法以前就曾有人提出过。其他人表示赞同，但也指出用于测试的环境——真实硬件、虚拟机、不同类型的存储等等——使得很难对比不同测试工作的成果。

Chuck Lever 表示，kdevops 项目有一个运行 fstests 的结果归档，这可能是一个良好的起点。他还刚了解到，内核网络子系统（netdev）将持续集成（CI）测试结果保存在 patchwork 中，patchwork 能够将数据与被追踪的补丁存储在一起。Netdev 正利用该功能存储其 CI 结果。（更多信息可在 Netdev 补丁自动化基础设施维基页面中找到。）

Ts'o 表示，他曾向 Konstantin Ryabitsev 询问过是否能建立一个用于存放测试结果的邮件列表，并归档在 lore.kernel.org 上。当一年前左右提出该请求时，Ryabitsev 对以这种方式存储自动化测试结果并不太热衷，可能是因为可能会产生海量数据。如果其他人认为这样的邮件列表有价值，Ts'o 表示可以再次提出这一想法。

两名与会者介绍了各自公司用于测试报告的仪表板（dashboards）。Ts'o 建议这类性质的任何开源项目都应该发布到 fstests 邮件列表，因为可能还有其他开发者会使用它们。Lever 表示，开发一个带有可监控仪表板的测试结果中央数据库是每次峰会都会提起的想法。他认为这可能是一个“登月计划”（极其艰难的任务），但也许可以寻求 Linux 基金会的帮助来实现。Ts'o 则认为基金会觉得他们已经通过 KernelCI 项目解决了这个问题，但 KernelCI 的工作并不非常适合文件系统测试。

Ts'o 表示，获取一次性资金来单纯开发一个工具，可能比创建一个类似于 KernelCI 但针对文件系统测试（这需要持续筹集资金来维护）的项目要更容易。他建议，让文件系统开发者对所需的功能达成一致（也许围绕着某人随手写出的原型），可能会促成资金到位，从而打造出一个生产级别的工具版本。“我们应该在会后共同商讨。”

排除文件管理与不稳定测试

Ts'o 还想提出的另一个议题是他正在维护的“测试失败文件”（files of test failures）。它们类似于 fstests 的 expunge（排除）文件（列出不应运行的测试），但是基于测试无法通过的内核版本来分类的。它们涵盖了按文件系统类型划分的失败，以及结合文件系统类型和测试场景的失败；它们记录了在各种长期支持（LTS）内核版本中无法正常运行且可能永远无法在这些版本中运行的测试。

他指出，Linux 发行版往往只是简单地使用与其所用内核相对应的旧版本 fstests。但他不想维护多个版本的 fstests，并认为运行最新测试是有价值的；新版本的 fstests 有时会指出是哪个内核版本修复了某个 bug，这有助于指示有价值的向后移植。运行较新的 fstests 版本确实会在结果中产生更多噪音，因为有更多测试永远不会在（比如）6.1 或 6.6 版本上通过。这就是他维护测试失败文件的原因。

这些文件目前保存在他的测试工具中，但他想知道它们是否应该移到别处并由大家共同维护。他的重点是 ext4，因此这部分在测试失败文件中得到了很好的覆盖。Lever 建议将测试失败信息添加到 fstests 仓库中，但也指出可能会面临要求“修复测试本身而非忽略它们”的反弹。Ts'o 表示，fstests 的维护者已经明确表示他们对追踪“哪个版本修复了什么”不感兴趣。这在一定程度上是有道理的，因为不同的人使用测试的方式不同；Ts me 只追踪 LTS 内核，而发行版则希望追踪自己的内核（其可能与主线 upstream 内核版本有所偏离）。

Christian Brauner 提出了“不稳定”（flaky，即时好时坏）测试的问题。Ts'o 表示，在他的内部版本测试套件框架中，允许将测试标记为 flaky；如果测试失败，它会再运行三次，只有当这三次全部失败时才会报告。他一直打算把这个功能加入到公开版本中，因为这很有用，但一直抽不出时间。

Ts'o 表示，大家各自都拥有针对不同内核版本的 expunge 文件版本，因此如果能把它们整合在一起就太好了。他建议，既然 fstests 不是合适的地方，也许内核本身会是个合适的去处。至此，讨论渐渐收尾，会议随之结束。

第二部分：深度解析 kdevops 自动化测试框架

在峰会讨论中，Chuck Lever 提到了 kdevops 框架，指出它所积累的 fstests 测试结果归档是实现集中化测试的优良起点。那么，kdevops 究竟是一个怎样的工具？它又是如何解决上述测试难题的？

一、 什么是 kdevops？

传统的 Linux 内核开发和测试环境配置极为繁琐：开发者需要手动配置虚拟化环境、安装缺失的依赖库、编译特定分支的内核、挂载测试块设备，并独立配置各类测试套件。

kdevops 的核心目标是将现代 DevOps 的最佳实践引入 Linux 内核开发。它并不企图替代现有的内核测试套件（如 fstests、blktests 或 selftests），而是作为一层自动化编排与部署基础设施，将底层的虚拟机开辟、依赖安装、内核编译部署以及测试套件的运行与结果比对全部统一起来。

二、 kdevops 的核心架构

kdevops 采用了内核开发者极其熟悉的配置界面与现代基础设施即代码（IaC）工具栈相结合的分层架构：

    +-----------------------------------------------------------+
    |                    Developer Interface                    |
    |               (Kconfig: make menuconfig)                  |
    +-----------------------------------------------------------+
                                  |
                                  v
    +-----------------------------------------------------------+
    |               Provisioning (Terraform / Libvirt)          |
    |             Local KVM / AWS / GCP / OpenStack             |
    +-----------------------------------------------------------+
                                  |
                                  v
    +-----------------------------------------------------------+
    |                   Configuration (Ansible)                 |
    |      Setup Node -> Compile Kernel -> Install Harness      |
    +-----------------------------------------------------------+
                                  |
                                  v
    +-----------------------------------------------------------+
    |                      Workflows Engine                     |
    |       fstests  |  blktests  |  mmtests  |  selftests      |
    +-----------------------------------------------------------+

1. 配置层（Kconfig / make menuconfig）：

   借用了 Linux 内核原生的 Kconfig 配置系统。开发者只需输入 make menuconfig，即可在熟悉的终端图形界面中勾选所需测试的内核版本、测试套件类型、目标文件系统（XFS/ext4/Btrfs 等）以及 底层 Hypervisor 引擎。

2. 基础设施编排层（Provisioning）：

    

   • Libguestfs / Libvirt / KVM：用于本地快速构建和管理测试虚拟机。

   • Terraform：用于公有云（AWS、GCP、Oracle Cloud 等）资源的自动化批量开辟。

3. 配置管理与部署层（Configuration Management）：

   由 Ansible 驱动。Ansible Playbooks 负责打通 SSH 免密连接、安装编译依赖、克隆内核源码、编译安装新内核、格式化逻辑卷以及部署目标测试套件。

4. 工作流与测试套件集成（Workflows）：

   集成了多种内核测试工作流，包含 fstests、blktests、mmtests、selftests 等，并具备测试结果对比与退化（Regression）报告提取能力。

三、 kdevops 的使用指南

在满足基本虚拟化支持的环境中，使用 kdevops 执行一次全自动测试的工作流极其简洁：

1. 初始化与配置：

    

   git clone https://github.com/linux-kdevops/kdevops.git
   cd kdevops
   make menuconfig
   # 在图形界面中勾选目标环境（如 Local KVM）、测试套件（如 fstests）以及文件系统（如 ext4）
   

2. 一键开辟测试节点：

    

   make
   # 自动调用 Libvirt/Terraform 启动虚拟机，并使用 Ansible 完成内核编译与测试环境搭建
   

3. 运行测试与结果分析：

    

   make fstests          # 在目标节点触发 fstests 测试流程
   make fstests-baseline # 保存当前测试状态作为基线 (Baseline)
   make fstests-results  # 收集、解析测试输出，自动对比基线生成退化分析
   

四、 kdevops 的发展历史

• 初创阶段（2019 年前后）：由知名内核开发者 Luis Chamberlain (mcgrof) 发起，旨在解决 fstests 测试套件配置门槛极高、环境变量复杂且难以跨团队复现的问题。

• 成熟与扩展阶段（2020 – 2023 年）：全面引入 Ansible 与 Terraform，脱离了早期依赖本地临时 Bash 脚本的局限，开始支持公有云大规模并行测试以及 PCIe 直通（Pass-through）等高级硬件特性。得到了来自 XFS、Btrfs 等社区核心维护者（如 Amir Goldstein、Chandan Babu 等）的广泛贡献。

• 深耕 CI 与云原生（2024 年至今）：逐步演进为内核连续集成（CI）的核心基础设施。在峰会上，以 Chuck Lever 为代表的开发者正推动 kdevops 与 GitHub Actions、Patchwork 进行打通，为内核代码审查提供自动化测试支持。

五、 在测试文件系统方面，kdevops 的独特优势

结合 LSFMMBPF 2026 上 Ted Ts'o 提到的测试痛点，kdevops 在文件系统测试领域展现出了极高的实用价值：

1. 极大降低 fstests 的部署门槛

   fstests 的配置极其复杂（需要手动划分 TEST_DEV、SCRATCH_DEV、配置高精度定时器与 loopback 拓扑）。kdevops 将这些最佳实践封装为 Kconfig 选项与 Ansible Roles，大幅简化了环境搭建步骤。

2. 多节点与复杂挂载场景的开箱即用

   文件系统测试常需要多盘拓扑（如 Btrfs RAID）、NVMe 直通、基于 Sparse 文件构建的 Loopback 逻辑盘或 RDMA/NFS 网络挂载。kdevops 能通过配置自动完成这些复杂块设备和网络拓扑的组装。

3. 高效的基线（Baseline）管理与退化检测

   文件系统测试耗时较长且往往伴随历史遗留的已知失败项（Known Failures）。kdevops 具备内建的基线比对机制（make fstests-baseline），在评估新补丁或 Backport 变更时，能自动排除干扰用例（Flaky tests），精确捕获新引入的崩溃或退化。

4. 测试环境的高度可复现性（本地与公有云一致）

   开发者可以在本地 KVM 上对单用例进行调试，也可以一键将相同的配置通过 Terraform 镜像推送到公有云上开展上百个节点的并发测试，彻底解决了“在我机器上能跑通”的搭建差异问题。

六、 kdevops 的未来展望

面对 LLM 代码生成带来的补丁激增以及稳定内核退化频发的现状，kdevops 正朝着以下方向演进：

1. 深度融入内核邮件列表与 CI 流程：实现针对 Patchwork 或 lore.kernel.org 邮件列表补丁的自动触发机制，在代码合并前拦截潜藏的文件系统 Bug。

2. 建立跨社区共享的测试结果数据库：正如 Lever 和 Ts'o 在峰会上传达的构想，依托 kdevops 收集并结构化存储各厂商的测试日志与排除列表（Expunge files），打破测试数据孤岛。

3. 智能化二分查找与错误归因：结合 Ted Ts'o 在 xfstests-bld 中实现的 Git 二分查找机制，kdevops 将进一步集成崩溃状态下的自动化 Bisect 能力，缩短定位 Bug 责任提交（Commit）的时间周期。

结语

LSFMMBPF 2026 峰会的讨论再次印证了一个共识：面对日益复杂的内核变更与快速迭代的稳定版补丁，唯有高精度的自动化测试才能保障文件系统的绝对数据安全。

以 kdevops 为代表的现代化基础设施工具，不仅正在消除传统文件系统测试（如 fstests）的门槛，更为未来的分布式内核 CI 和自动化回归检测奠定了坚实的技术基石。