LWN：分层存储管理，fanotify, FUSE 等等！

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

Hierarchical storage management, fanotify, FUSE, and more

By Jake Edge
July 16, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/981392/

Amir Goldstein 在 2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上领导了一场关于文件系统主题的会议，他介绍了他使用 fanotify 构建 分层存储管理 (hierarchical storage management) (HSM) 系统的项目。这个想法是监控文件访问，以确定何时从非本地存储（例如云存储）上来获取内容。这次会议是对去年 该项目的介绍 （涵盖了他遇到的一些问题）的后续追踪。今年，他向与会者更新了项目的状态和进展，并讨论了一些他想要讨论的其他问题领域。

背景

他首先简要概述了 HSM 的用例以及他的项目如何融入其中。例如，存储在云中的文件对系统来说看起来像是本地的。当访问该文件时，一个 fanotify 监听器会对该事件做出反应，从而使该文件可以在本地访问到。一旦请求的数据被填充到文件中，监听器就可以返回来让访问该文件的程序继续执行。

去年，他描述了一个死锁问题，该问题在某些情况下可能会发生，例如当监听器守护进程在收到文件已被访问的通知后开始向文件写入数据时。为了解决这个问题，他采纳了一些建议，并 将 fsnotify 钩子移到了 VFS 锁之外 (moved the fsnotify hooks outside of the VFS locks)，从而解决了这个问题；这些补丁已合并到 Linux 6.8 中。他发布这些补丁已经有一段时间了，几个开发人员已将它们集成到他们的测试中，包括 kernel-test 机器人；他感谢这些努力，部分原因是机器人发现了一些由于添加了新钩子而导致的性能下降。他能够重构 fsnotify 代码并将其纳入 6.9，从而降低了开销，无论对于他的用例还是其他用户都是如此。

他一直在研究 fanotify 的一些“内容之前事件（pre-content events）”；Goldstein 说，几个开发人员已经审查和测试了该代码。当前代码位于他在 GitHub 上的 "fan_pre_content" 分支 (branch) 中。新的 FAN_PRE_ACCESS 和 FAN_PRE_MODIFY 事件附带了一些新的 FAN_EVENT_INFO_TYPE_RANGE 信息。它描述了受影响的文件范围。在他的也位于 GitHub 上的概念验证 (PoC) 实现中，这些事件允许打开位于网络其他位置的大型文件，例如 Linux tarball，并仅读取其第一部分。

他的分支还增加了 fanotify 返回除 EPERM 之外的错误的能力。目前，监听器只能返回成功或 EPERM，但通过他的更改，可以返回其他错误，例如 EBUSY 和 =ENOSPC=。

未解决的问题

他使用真正的文件系统，例如 Btrfs 或 XFS，作为他的 HSM 的本地存储；当文件未填充时，它们在本地是稀疏文件，因此不占用存储空间。但是，如果 HSM 守护进程未启动，他不想让用户能够访问这些文件。防止这种情况发生的一个想法是使用 HSM 挂载选项进行“受限挂载（moderated mount）”，该选项仅在守护进程运行时允许访问；其他时间进行的访问将导致 EPERM 。他想知道与会者对此是否有想法或意见。

作为他 HSM 工作的一部分，他查看了其他操作系统是怎么做的；Windows 长期以来一直拥有基于 NTFS “重新解析点 (reparse points)” 的 HSM 支持，重新解析点是文件上的持久标记（persistent marks），指明访问它们所需的驱动程序。也许 Linux 可以通过向文件添加某种持久标记来做类似的事情，而不是使用受限挂载的想法。

Josef Bacik 说他不喜欢使用挂载选项的方案，因为选项不能对不同的子卷进行不同的设置；容器可以访问不同的 Btrfs 子卷，这意味着它们都需要以相同的方式对待。Goldstein 建议容器可以使用不同的绑定挂载（bind mount）来挂载子卷，并应用不同的选项，Bacik 同意这种方法可行。

但 Bacik 更喜欢持久标记的想法，部分原因是他遇到了执行通过 fanotify 技术填充的文件时的一些问题。当使用 execve() 执行远程文件时，HSM 没有机会将数据写入文件；在能够完成写入之前， execve() 已经映射了内存，因此任何写入都会返回 ETXTBUSY 错误。Bacik 和 Goldstein 都指出，Btrfs 有一个 ioctl() 命令，可以使用它来避免这个问题，这也是 Bacik 将持久标记功能视为解决问题的方法。但这是一种特定于文件系统的解决方案，Goldstein 希望能够以更通用的方式解决问题。

Goldstein 说，他的代码树中有两个不同版本的 PoC 代码（其中一些在 他的 HSM wiki 中描述；一个使用 inode 上的可驱逐标记（evictable mark）来标记已完全填充的文件，而另一个使用扩展属性 (xattr) 实现一种持久标记的形式。fanotify 已经有先例在 "security.fanotify" 命名空间中使用受保护的 xattr，因此他添加了一个 "mark" xattr。

然而，Jan Kara 不赞成将持久标记作为 xattr。他不确定谁将拥有该标记；如果有多个 HSM 实现，内核将如何决定对给定文件使用哪个？Goldstein 说，对于 Windows，重新解析点包含一个标识符，用于指定需要为该文件使用哪个存储驱动程序。Kara 说这可以工作，尽管让 VFS 代码在 xattr 中四处查找有点难看。

execve()

谈话又回到了 execve() 问题，Bacik 说他还有另一种解决方案，他怀疑很多人会更讨厌它。他的雇主 Meta 希望能够执行可能不在本地存在的二进制文件，因此添加一个持久标记来告诉系统调用 用户模式辅助程序 (usermode helper) 来填充文件就会使这成为可能；他表示，它根本不会使用 fanotify。Bacik 微笑着说，他忽略了来自 Christian Brauner 的背景中的尖叫声。Kara 建议使用一个新的系统调用，Bacik 认为这可能是“更可接受的解决方案”。

Brauner 要求更多关于正在解决的问题的澄清，该问题围绕着对可写内存进行执行映射的限制。Aleksa Sarai 说，需要写入文件的内容才能填充它，但 execve() 要使用的内存位于私有映射中，因此它不能在以后被填充。Bacik 说，用户模式辅助程序可以绕过这个问题。

Brauner 说他最担心的是用户模式辅助程序功能不能感知命名空间，这会带来安全性和其他影响。以它为基础的 API 对未来的可扩展性和可维护性有很大的影响，这也让他担心。Bacik 同意，但他说用户模式辅助程序是由内核端发起的，因此他认为它可能更容易被接受，比起允许 fanotify 监听器从用户空间发起来说。Brauner 建议，查看可用性和安全性角度应该有助于确定哪种方法更好。

但还有更深层次的问题，Goldstein 说。一旦文件被 execve() 打开，它就会被标记为“拒绝写入”，因此其他任何东西都无法成功打开该文件。他说，绕过这个问题，同时仍然通过 VFS 层，将破坏该层的一些基本部分。通过 Btrfs ioctl() 命令写入文件可以工作，新的绕过 VFS 的系统调用也可以工作，但使用 write() 填充文件将无法工作。

FUSE

接下来，Goldstein 指出，可以使用 FUSE 而不是 fanotify，它更加灵活，但它要求所有 I/O 流量都通过 FUSE 守护进程。这不像人们想要的那么好，这就是为什么他一直在与其他人合作 FUSE 直通 (FUSE passthrough)。因此，FUSE 可能是通往 HSM 解决方案的另一条路径。

Bacik 说，他不确定要走哪条路，但他会调查这两条路。“我在这两匹马身上都下了赌注”，Goldstein 笑着说。Ted Ts'o 指出，Dan Rosenberg 一直在研究 FUSE BPF 文件系统 (FUSE BPF filesystem)，该文件系统的目标是让 Android 能够对可执行文件进行增量加载；“所以在这个领域实际上还有其他一些工作正在进行”。Goldstein 说，FUSE 直通刚刚合并到 Linux 6.9 中，它部分基于 Android 补丁。计划是在 FUSE 直通功能稳定后将 BPF 部分加入。

Bacik 说，FUSE 对于 Android 来说很有意义，但对于 Meta 来说则不然，至少对于 Meta 的某些用途来说。如果 FUSE 守护进程崩溃，应用程序就会突然在生产环境中崩溃；fanotify 解决方案更加可以实现自我完整性。Goldstein 说，对于“大部分直通文件系统”，fanotify 解决方案可能更好——“如果我们能使其工作”，他笑着说，此时会议时间到了。

会议的 YouTube 视频 (YouTube video) 和 Goldstein 的 幻灯片 (slides) 都已发布。

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

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

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