LWN：9月份LPC上关于folio的一次讨论！

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

A discussion on folios

By Jake Edge
September 22, 2021
LPC
DeepL assisted translation
https://lwn.net/Articles/869942/

在 2021 年 Linux Plumbers 大会几周前的时候，Matthew Wilcox 可能就已经预见到在大会上的会议重点会有很大不同。但是，正如我们在 9 月份初期的报道中讲到的，他的 folio patch set 遇到了一些可以算是意想不到的反对意见，最终没有进入 5.15 的 mainline。他没有在 File Systems microconference 上专门讨论如何使用 folio，而是主持了一个讨论，其中有一部分是关于 folio 的后续可能的发展方向。

Wilcox 首先指出，folio 那些 patch 还没有被合并，他没有从 Linus Torvalds 那里得到明确的指示，"为了使他能接受，我还需要修改些什么"。这个现状是与 Wilcox 当初的预期不太一样的，所以这次会议不打算介绍 "大家需要做什么才能让你的文件系统可以能够更快地开始使用 folio"。他说，"这不是我们的目标"。

[Matthew Wilcox]

相反，倒是应该讨论一下文件系统需要做什么才能在 page cache 中使用更大的 page，这会是非常有用的。这个做法将可以使文件系统的 I/O 更有效率，他说。开发者最应该做的就是把那些仍然使用 buffer heads 的文件系统转换为使用 iomap 进行 I/O，至少对于那些 block-based 文件系统都应该这么做。网络文件系统应该使用 David Howells 的 netfs_lib。在这两种情况中，这些 API 都可以把文件系统与 Wilcox 正在做的大部分工作隔离开来，他笑着说。

这两种 API 都将文件系统与 page cache 隔离开来了，例如，它们在表示大小的时候都使用字节，而不是有多少 page。任何直接使用 page cache 的文件系统都应该考虑要换到 iomap 或 netfs_lib 了。内核中有一些人造的文件系统，比如 procfs，根本不处理 page cache，这类文件系统就不在讨论范围内了，因为我们的重点是关于改进 page cache 的。

buffer head 那种接口有一些功能是当前 iomap 仍然缺乏的。他一直在与文件系统的开发者讨论哪些是必须要添加进来，才能让 block-based 文件系统能够改成使用这套 API。为了支持 fscrypt 和 fs-verity，iomap 就需要增加一些功能。还有 buffer head 方式在 I/O completion path 中可以做一些工作，这些都是 iomap 所缺乏的功能，但并没有 "根本性的问题"，他说。不过，其他工作一样，开发人员的时间是很有限的。

Howells 简要介绍了他正在进行的使 fscrypt 配合网络文件系统来一起工作的开发情况，具体来说就是在这种情况下开始使用 folio。想法是把 fscrypt 和 page cache 的处理代码放到一个单独的库中，供网络文件系统来使用。目前，AFS 和 Ceph 正在使用这种方式。当网络文件系统从服务器上收到加密的数据时，它不应该将其存储在未加密的 page cache 中，但用来保持数据处于加密状态的代码不应该在六个不同的网络文件系统中都复制一份。然而，因为 Torvalds 并没有合并 folio patch set，他的工作就被阻碍在这里了。

Help wanted

Josef Bacik 问文件系统开发者能给 Wilcox 提供哪些帮助。他知道这个需要转移到 iomap 的工作，这也是 Btrfs 一直在持续进行的改动。但他想知道文件系统开发者是否可以采取什么具体措施来给予 Wilcox 支持，"比如是不是要 patch review，是不是要 design review，[…]你希望我们做什么来帮助你完成这些工作？"

[讨论]

Wilcox 说，他不认为在文件系统方面会有很多事情要做。他已经 "跟 XFS 的开发者进行了深入的探讨"，他们帮助修正了他的一些错误观念。他们还帮助找出了他的 iomap 改动中的一些问题。iomap 最初是从 XFS 内部拿出来的，改为了通用部分的代码，他指出。如果要希望使那些在用 buffer head 的文件系统来处理更大的 page，那么他就需要这些文件系统之中的某位开发者提供类似的帮助。但是，人们似乎已经达成共识，正确的做法是尽量减少使用 buffer head，所以可能也就不需要这些帮助了。不过从另一方面来说，Wilcox 觉得他和 XFS 的开发者在转换到 iomap 方面还是需要多帮助其他文件系统的开发者。但是他已经看到了在目前将 Btrfs 的 direct I/O 转换为使用 iomap 的工作中的一些进展，这一切也都在合作进行中了。

Bacik 说，他也不算是作为一个 Btrfs 的开发者提出的这个问题，而是从一个内核开发者的角度来问。他说，这类改动往往是由一个人来推动的，尽管很多人都希望在内核中进行这些改动，这个人有时就会有一段时间感到非常艰难。

Ted Ts'o 问道，如果帮着做一些 bencharmk 测试采集，会不会有帮助。Wilcox 说他没有做很多 benchmark，每天都会运行 xfstests 很多次，但 "没有搭建用来做性能测试的环境"。Ts'o 和 Bacik 都说他们都有环境可以做这种性能测试，所以如果 Wilcox 能告诉他们 Git tree 的位置，那么他们就可以定期进行有 folio 和无 folio 的对比测试了。

Ts'o 指出，fscrypt 和 fs-verity 在某种程度上来说是写成了库文件，这样它们就可以更容易地被其他文件系统采用了。但是，这两者组合起来的情况还没有准备好。他曾考虑为来自块设备或网络的文件系统数据的操作（如解密、验证、解压）都提供一种通用的流水线操作（generic pipeline），并且这些操作可以以任意方式组合。

他向 Howells 建议，他正在进行的 fscrypt 来支持网络文件系统的工作的未来版本可以来提供某种能组合这些操作的功能。Howells 介绍了为了使 fscrypt 与一些使用较大 page 的网络文件系统能一起工作所做的工作。Ts'o 说，ext4 也需要这样的工作，这样它才能也转向使用 iomap。他们同意今后有更多合适的人聚在一起的时候继续这个讨论。

Folio future

Wilcox 说，在过去的几天里他和 Kent Overstreet 一直在讨论如何合入 folio 这个改动。Overstreet 说，他认为在过去一周左右的时间里，linux-kernel 邮件列表的讨论已经取得了不少进展。他说，在许多情况下，对 folio 的反对意见在针对 5.15 提出的代码中已经都不存在了。尤其是这些 patch 现在已经不会去触碰匿名页了，当初人们就是比较担心对匿名页的影响，他说。

Overstreet 建议 Wilcox 向 Andrew Morton 咨询一下，了解事情进展如何，因为 Overstreet 认为反对意见主要是关于 folio 今后的走向是什么，而不是当前实际发布的 patch 内容了。除此之外，在当天晚些时候，Overstreet 还向 Torvalds 发布了一个请求，要求重新考虑把 folio patch set 原样合入进来。但事实证明，情况比 Overstreet 认为的要复杂得多。特别是 Johannes Weiner，他强烈反对 folios 这个方向，至少在内存管理方面，他对现有的 patch set 有反对意见，而不仅仅是反对 folio 未来的方向。

Ts'o 说，有人对他说，内存管理的开发者可能都没有仔细看过 folios，直到 pull request 出现才开始重视。这可能是由于 "文化上就期望着 MM 中的改动要么永远无法合入、要么就只需要一天"。他想知道是否有什么好方法可以与这些开发人员一起配合工作，能明确出这种类型的 patch 的 review 流程是什么样的。可能有一个关于子系统作为一个整体如何做决定的流程问题。这将有助于每个人理解如何获得共识会有哪些基本规则。他认为至少在内存管理社区内，还没有针对 folio 达成共识。

Overstreet 说，目前没有人真正致力于解决 "struct page 相关的混乱"，这也许算是问题之一。Wilcox 的工作是社区里最接近于这个目标的。Overstreet 说，但是这个讨论之所以如此有争议，是因为来自不同子系统的状态都在 struct page 中混杂在一起。目前还没有一个真正的总体设计来解决这个问题。

他说，每个人都看到了这里的混乱，但每个人都看到了混乱的不同方面。folio 正在清理其中一部分，但有些人对他们关注的那部分没有被立即清理掉感到不高兴。他认为，一个能够展示最终目标、以及每个部分被清理的目标的整体计划将对解决这些问题有很大帮助。会议到此结束，但显然整体讨论将继续进行。

有兴趣的读者可以在 YouTube 上观看该会议的视频。

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

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

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