LWN：The netfslib helper library

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

The netfslib helper library

By Jake Edge
May 16, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894589/

有一个名为 netfslib 的新的网络文件系统 helper 函数库在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）上文件系统会议中有一个主题讨论。David Howells 开发了 netfslib，在一年前被合并到 5.13 中，他主持了这次会议。一些文件系统，如 AFS 和 Ceph，已经在使用 netfslib 提供的一些服务，而另一些则开始上手研究了。

Howells 直接开始介绍 netfslib 和它的一些功能，而没有对该库进行太多的 high-level 介绍。不过，他提出要在会议上讲这个话题的提案邮件中做了一些这方面的介绍：

在 Jeff Layton 的帮助下，我一直在开发一个库（在 fs/netfs/中），从而给网络文件系统提供一些支持功能。我们的想法是将虚拟机接口的常用功能，包括 request splitting、operation retrying、local cachiing、content encryption、bounce buffering 和 compression 都移到一个地方，从而方便各种文件系统来使用这些公共功能。

这也与 folios 主题有关联，因为现在的目的之一就是尽可能多地从文件系统中隐藏掉 folios/page 的概念，而不是提供 persistent iov iterator 来描述它可用的那些 buffer。

Goals

在会议上他说基本目标是将虚拟内存（VM）的处理从网络文件系统中分离出来，放到一个通用库中。该库位于内存管理子系统和文件系统之间，来处理所有的地址空间操作，也许 truncation 除外。所有的 folio 处理代码也将位于这个库中。local caching 也是在库里完成的，这使得 cache 可以更容易地使用多个 page 的 folio。

[David Howells]

Netfslib 会支持内容加密（content encryption），这与传输加密（coontent encryption）不同；客户端可以在本地查看到文件的内容，而服务器不可以，因为内容都是加密过的。这意味着 local cache 中应该只有加密过的文件数据；客户端将在进行读取操作时来解密，在写入操作时再加密。他说，将解密的数据排除在 cache 之外，有助于确保丢失笔记本电脑之后不会被人访问到这些文件内容。

在同一个地方进行所有这些处理，然后让所有网络文件系统访问相同的服务，这样大家就容易一些。为了让内容加密这部分能发挥作用，他必须给 netfslib 增加 buffering 功能，这样它就可以处理读、修改和写这些操作了：它可以向文件服务器发出 read 请求，允许对数据进行修改，然后再写回来。他说，写不一定要使用 page cache 中的数据；该库可以从内存中直接向服务器进行大批量的写操作，然后从内存中删除数据。

他说，该库允许网络文件系统在其代码中摆脱所有关于 page 或 folio 的了解。该库使用了 hook 进行两种操作：异步读和写。这些 hook 被传递给 iov_iter 结构，它指向了使用各种机制所存储的数据，"也许在 bvec 中，也许在 XArray 中，也许在 page cache 中"，文件系统不需要知道是哪种情况。因此，该库可以处理 direct I/O、encrypted direct I/O 和 buffered I/O（可能有 encryption）；所有这些都可以正常工作，他说。

如果网络文件系统要支持内容加密，就必须提供两种功能：对 block 进行加密和解密的功能。目的是让那些希望使用 fscrypt 的文件系统（比如 Ceph 正在研究的这么做），可以简单地将 hook 指向 fscrypt。他说，fscrypt 信息会直接存储在 inode 里面。

除此之外，netfslib 还为 readahead 使用了一个 hook，可以支持那些具有复杂要求的文件系统。他举了 Ceph 的例子，它的文件有 2MB 的 block，这些 block 可能分散在不同的服务器上。readahead hook 可以在队列里放多个 block，可以是来自多个不同服务器的，然后一次性把所有这些 read 请求发出去。他说，这些也可以按顺序来发送，这是 CIFS 文件系统所需要的一个功能；该函数库事实上提供了一些基本的排队服务。

Other support?

Steve French 问压缩功能的支持情况；许多网络文件系统可以对网络数据进行压缩来减少所需的带宽。Howells 说，他正在努力支持这个功能。他说这有点棘手，因为压缩块的 size 通常比 page 或 folio 的 size 大。由于文件系统使用了多种不同的压缩方案，因此可能需要有针对压缩和解压缩分别使用 hook。

Amir Goldstein 问对目录缓存（directory caching）的支持情况。Howells 说，他有一些支持 AFS directory caching 的 patch，但 AFS 目录只是些被来回传递的 blob。他可以考虑增加 directory information caching，也就是从服务器上读取目录条目，并以某种标准格式来存储在本地。

Josef Bacik 问最终的目标是什么：是不是要替代掉 NFS、Ceph、CIFS 等的一堆代码？Howells 同意这是他的目标；Plan 9 文件系统（9P）是另一个目标，也已经有人跟他提到 FUSE 了。Goldstein 说，FUSE 是有价值的，确实应该进行转换。

Bacik 继续说，他想知道这项工作当前的状况。Howells 说，read helper 可以工作了 AFS、Ceph 和 9P 都在使用它们；他有针对 CIFS 的 patch 并经过测试，似乎没有什么性能影响。他正在研究 write helper 程序，除了 truncate 功能的支持外，基本上都可以正常工作了，这是下一步的问题了。write helper 可能会在下一个合并窗口添加到 mainline 上，尽管时间上可能有点紧张。Bacik 问总体目标是否是希望简化代码；Howells 说是的，他已经能够删除大约 8000 行代码。

Chuck Lever 问及对 direct placement of data 的支持情况；这对 CIFS、NFS 和 9P 很重要，所以他想知道 Howells 计划对 RDMA 传输做些什么。Howells 说，他还没有真正研究过这个问题，也没有硬件可以测试，不过他认为他会提出一些方案的。Lever 说，不需要硬件，因为在内核中有两个软件 RDMA 驱动程序，可以配合标准以太网卡一起使用。Howells 说他会研究一下这个问题，Lever 说他愿意来提供帮助；"这并不像你想象的那么糟糕"。Howells 笑着说。"这话我以前听过。"

在聊天中，Layton 说，他看不出 netfslib 有什么理由不能增加 RDMA 支持。Howells 说，当使用 page cache 进行 buffered read&write 操作时，netfslib 会将一个带有 page cache page 的 iov_iter 交给网络文件系统。同样地，direct I/O 读写也只是得到一个 iov_iter。理论上来说，网络文件系统需要去做那些基于这些 page 来完成 RDMA 读写所必须做的工作，他回应道。Layton 对此表示赞同。

Bacik 说，他认为 netfslib 的工作是一个良好的开端，尽管还有一些工作要做，比如 RDMA 和 FUSE 就需要不少时间来加以研究。将网络文件系统转换为使用 netfslib 可能是一个更紧迫的问题。Howells（以及会议室里的其他人）似乎都同意这一点。

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

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

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