LWN：把文件系统转换为iomap！

关注了就能看到更多这么棒的文章哦～

Converting filesystems to iomap

By Jake Edge
June 27, 2023
LSFMM+BPF
DeepL assisted translation
https://lwn.net/Articles/935934/

Luis Chamberlain 在 2023 年 Linux 存储，文件系统，内存管理和 BPF 峰会上领导了一场围绕 iomap 文档的讨论，iomap 为现代文件系统提供了 block-mapping 接口。人们正在进行将文件系统都转换为使用 iomap 方式，以便留下 buffer head 并更好地支持 folio，因此会议的目的是从那些在进行这种转换的开发人员那里获得关于文档的反馈意见。会议的具体成果之一就是计划将该文档从 KernelNewbies wiki 上的当前位置移动到内核文档中。

Hannes Reinecke 说，iomap 文档中没有明确指明单位，让他感到困惑，是不是应该用字节、扇区、页面或其他单位来说明？此外，还有许多各种操作功能（operation-function）指针，分布在三个不同的 struct *_ops ，需要由文件系统提供，但他不清楚每个指针的目的是做什么。Chamberlain 说，当他开始研究 iomap 时，这些也让他感到困惑，但基本的想法是，有很多不同类型的操作，其中许多都有很多 flag 或 option，所以这五花八门的操作只是为了能拆分成自己的独立功能。另一种方法是使用一个函数但是需要包含大量复杂内容，来处理所有不同的可能性。Reinecke 说，他对所有这些功能都很好，但文档中（尚未）解释所有操作的用途。

Chamberlain 说，这个文档试图讲清楚所有关于将文件系统转换为使用 iomap 所需的内容。有 direct I/O、buffered I/O、file-extent mapping 等。Iomap 提供了一个关于 range 的迭代器，尝试用来替换掉现有的 block-range 操作。但是，正如在前面的 buffer-head 会议中所讨论的那样，iomap 中没有 metadata 操作的 helper 函数。文件系统必须像 XFS 一样实现自己的 metadata 处理，或者继续为这个目的来使用 buffer head。他说向 iomap 添加 helper 是可行的，但可能不是那么有用，因为具有自己的 metadata 操作的文件系统不太可能想要切换到新的方案。

Reinecke 总结了目前对 iomap 的思考。它是新文件系统应该使用的接口，正如在 large-block-size 议题中所讨论的，这将是文件系统支持 block size 大于 page size 的情况的唯一方法。他指出，允许在内核之外配置 buffer head 的 patch set 可能并不真正有用，因为 UEFI 系统需要一个 VFAT 文件系统，而该系统目前需要 buffer head。他有将 VFAT 转换为 iomap 的 patch，目前来说这些 patch 部分能工作，因此该问题可能会不久就解决了。

Reinecke 说，iomap 文档中对于重新设计文件系统给出建议顺序应该改变一下，目前将 direct I/O 作为首先要切换的部分，但他认为应该把它留到最后。Josef Bacik 说，Btrfs 一直在进行切换，它是从 direct I/O 开始，因为更改 buffered I/O 功能的话需要对更多的代码进行重写。他认为 direct I/O 的转换动作在文件系统看来更直接一些。

Ted Ts'o 告诫说，首先在更简单的文件系统上进行转换也可能不是一个正确的途径。Iomap 缺少一些必要的基础设施来减轻该过程的痛苦。metadata 的读写就是一个很好的例子。此外，许多简单的文件系统根本不支持 direct I/O，因此它们无法从那里开始。同时，他们确实需要读写 metadata 的能力，因此要求他们立即转换的话，可能会导致开发人员“尖叫着逃跑”。

Jan Kara 说，iomap 转换工作有两个方面：使用 iomap 来处理 data path，这方面现在已经准备好了，另一方面就是删除 buffer head，这是另一个问题了，需要“给他们一个合理的理由”。重要的是要认识到文件系统不能被强迫着完全转换为 iomap，Reinecke 说。这是最终目标，但可能永远无法实现。Kara 说他已经准备了一些 patch，将 ext2 direct I/O data path 转换为 iomap。这些 patch 还包括一些 VFS 改动，这些改动将使更简单的文件系统的转换变得更容易。更复杂的文件系统，如 ext4，Btrfs 和 XFS，则不需要这些改动，因为它们已经有内部的 helper 函数了。他正在与 Ritesh Harjani 合作，将 ext2 data path 的其余部分转换为 iomap。

下一步是切换 metadata 数据的处理，但目前还没有好的方案。Reinecke 说，他一直在与其他人合作，提供 helper 函数，允许文件系统的 request size 小于 page size 的数据传输，并取回一个 folio 和一个 offset 指向数据所在的位置。就他而言，只要他知道从哪里获得他感兴趣的数据，读取 512 字节或整个 page 并不重要。然后，需要确定出一个 sub-page 的要写入的部分。在这些部分准备好之后，就可以解决 metadata path 的切换问题。

Harjani 通过远程链接进来，谈论了他在 ext2 的 buffered I/O 路径上所做的工作。还存在一些未解决的问题，其中一个问题正在由当前在 review 的 sub-page dirty tracker 这组 patch 解决了。另一个问题是 BH_Boundary flag 当前被 ext2 等文件系统使用，它可以具有不连续的 indirect blocks。如果包含 range 的 BIO 被重新排列，则可能导致数据访问模式不是最优方案。该 flag 在 iomap 中不受支持，但可能需要成为 dirty tracking 之后接下来需要解决工作。

Ts'o 说，这个问题实际上只影响使用 V7-Unix 风格的 indirect block 的文件系统，例如，VFAT 就不使用它。现代文件系统改用 extent mapping。因此，这可能是 iomap 可能希望为那些较旧的文件系统（如 ext2，minix 和 UFS）提供更好的性能的一个例子，但是也许不添加该功能的时候性能就足够好了，并且“我们可以忍受那些旧文件系统出现性能下降”。

这是文档应该明确 iomap 仍在开发状态中的另一个原因。最终出现的接口可能与今天的会很不同。文档可能会随着时间的推移而改变，因为人们正在努力使文件系统更容易使用 iomap，但这仍在建设过程中。“我们不应该承诺它会很容易，因为这并不容易……目前来说是这样。

Reinecke 说，对较旧的文件系统的支持，通常仅仅需要能够访问到这种文件系统就行。实际上没有必要确保访问速度。对于像 VFAT 或 ISO CD-ROM 文件系统这样的东西，稍微减慢它们的速度也不会真正被注意到。毕竟，他们从一开始就很慢。因此，他建议不要花很多时间提升这些场景的性能。“如果你很关心的话，可以写一个不同的文件系统”。

Chamberlain 指出，Kara 曾提到 Linux Test Project（LTP）测试套件非常适合用于测试这些类型的改动，但想知道是否还有其他测试集。Kara 说，fstests 中的 direct I/O 测试也可以使用。

Chamberlain 说，Goldwyn Rodrigues 在 locking 方面做了很多工作，需要进入内核，以便 Btrfs 可以不仅仅将 direct I/O 路径转换为 iomap。Rodrigues 远程插话说，这就是他一直在解决的最糟糕的部分，page lock 中出现 extent locking，目前主要是在做这个，尽管有“几个 hack 方式的 patch”。他希望尽快对 patch 进行 review，这可能会为后续的修改带来一些更好的想法。

Kara 向 Harjani 报告说，他刚刚在代码中四处寻找，并不认为 flag BH_Boundary 会是一个大问题。它旨在告诉 block 层文件系统需要提交一个 read 操作，然后才能提交后续的 read，但 iomap 只是返回每个连续的 extent，因此它隐式地处理了这种情况。Kara 说，Harjani 可以忽略边界处理问题，“基本上不会有事”。

Chamberlain 在会议结束时要求与会者，特别是那些正在将文件系统转换为使用 iomap 的人，来仔细看一下 wiki 上的文档。他简单介绍了如何在那里获得编辑权限，并建议开发人员在 wiki 文本本身中直接反馈他们的评论。在一两个内核版本的时间内，就可以提交到 mainline。一位与会者说“越早越好”，其他人也同意，所以张伯伦说他会直接将其发布到邮件列表中以供 review。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～