LWN：文件系统新增API！

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

New APIs for filesystems

By Jake Edge
May 30, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/975444/

在 Linux 存储、文件系统、内存管理和 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上，关于扩展 statx() 系统调用的讨论经常出现；今年也不例外。Kent Overstreet 在峰会上主导了第一个仅限文件系统的 session，主题是查询具有子卷和快照的文件系统的信息。虽然它被宣传为关于 statx() 添加的讨论，但它广泛地涵盖了现代文件系统所需的众多新 API。

头脑风暴

Overstreet 开始 session 时，认为这将是一场头脑风暴练习，旨在提出对文件系统 API 的补充。他对新功能有一些想法，但希望听取其他与会者的想法，以便收集任务清单。他说，他并不打算独自完成清单上的所有工作，但他会帮助协调。

他开始思考为 bcachefs 实现基于子卷的磁盘计量，这让他意识到需要一种遍历子卷的方法。他提到了之前的一些讨论，其中 Al Viro 提出了一种迭代器 API，它将为每个打开的子卷返回一个文件描述符。“这太疯狂了，也很酷”，Overstreet 说；它也与各种 openat() 风格的接口完美契合。然而，他认为还有更简单的方法。

在 opendir() 中添加一个 flags 参数将允许创建一个标志，用于迭代子卷和子挂载。他最近注意到，子卷和挂载有很多共同点；用户空间开发者希望有办法处理它们，而这将提供这种方法。

他还说，文件上的扩展属性 (xattrs) 也需要某种形式的迭代器接口。这些可以顺利地融入他提出的方案中。他表示，现有的 getdents() 接口“很好很干净”，所以它也可以用于 xattrs。

statx() 中最近添加了 stx_subvol 字段，用于子卷标识符。将需要另一个用于 statx() 的标志来识别文件是否位于快照中。这样，coreutils 默认情况下就可以过滤掉快照。从而在人们浏览文件系统时，他们就不会一遍又一遍地看到相同的文件。

Steve French 提出了一个关于如何在 Linux 上以通用方式列出给定挂载的快照的“初学者问题”。Overstreet 说快照是一种子卷，而“子卷是一个花哨的目录”。这个新的 opendir() 接口可以用于遍历子卷，新的 statx() 标志可以用于检查哪些是快照。

他说，所有由 statfs() 返回的有关已挂载文件系统的信息也应该适用于子卷，“继续坚持子卷和挂载点实际上有很多共同点的主题”。这包括磁盘空间使用情况和已使用 inode 数量等信息。

Dave Chinner 说 XFS 已经有一个基于项目 ID 的类似接口，其中可以将对应于特定项目的目录条目传递给 statfs() ，以检索该项目的特定信息。他说文件系统可以检查传入的目录并根据它决定要报告什么，所以不需要新的系统调用。Overstreet 怀疑，在他们的主目录中键入 df 的用户会期望只获得他们所在的子卷的信息，而不是整个磁盘的信息，正如他们现在所做的那样。他认为新的系统调用是解决此问题的正确方法。

French 说，其他操作系统有一种方法可以简单地从快照中打开文件的版本，而无需实际直接处理整个快照子卷本身。用户可以简单地从给定的快照标识符中打开文件，这很方便，而且在 Linux 上实际上不可行。Overstreet 承认了这个问题，但表示他认为不需要新的系统调用来支持这种情况。使用正在讨论的新接口，用户空间应该能够处理该功能，也许可以使用快照的只读挂载，这样用户就不必直接处理它们。

用户空间问题

但是 Lennart Poettering 说：“作为一个用户空间的人，我发现 opendir() 被视为这种功能的适当接口有点奇怪”。在很多方面，他发现 opendir() 是一个“糟糕的 API”，因为它会提供文件名，但随后你必须打开文件才能获得更多信息，而这些信息并不一定匹配，因为这两个操作之间可能存在竞争。他更希望在枚举事物时获得一个文件描述符，这样状态在两者之间就不会发生变化。

他继续说， opendir() 和子卷之间存在一些其他不匹配。现在，用户空间期望从 readdir() 中获得文件名，这意味着它们不包含斜杠 (“/”) 字符，但子卷路径名确实包含。此外，在 struct dirent 中返回的文件名只能有 255 个字符，这对子卷名称来说太严格了。

最终，Poettering 认为用户空间程序不希望获得文件名，他们想要的是不会在他们眼皮底下发生变化的东西。Jeff Layton 建议转而使用 文件句柄，Poettering 同意这会更好。Christian Brauner 指出 listmount() 系统调用 使用新的 64 位挂载 ID，但没有办法从该挂载 ID 找到对应的文件描述符或句柄。然而，添加起来很容易。

Overstreet 说，他计划添加 firmlinks，这是一个 Apple 文件系统 (APFS) 功能，介于硬链接和符号链接之间。它将使用文件句柄和文件系统通用唯一标识符 (UUID) 来标识特定文件。Amir Goldstein 说 overlayfs 也使用这两个 ID 来标识其文件，因此 Overstreet 认为也许该方案应该成为 Linux 文件系统的标准。

然而，文件句柄还有一些缺失的部分。没有系统调用可以从文件句柄查找到文件路径。Goldstein 说这种能力是存在的，但只对目录可靠。“这是因为硬链接带来的麻烦”，Overstreet 说；Goldstein 同意这只是一部分原因，但 Jan Kara 说有些文件系统无法提供这种映射。

Overstreet 说，越来越难以保证 inode 编号的唯一性。关于他 在 LSFMM+BPF 上的提案 session 的大多数讨论都围绕着这个问题及其解决方案展开；它也 在之前的峰会上出现过。基本问题是，更新的文件系统 (Btrfs、bcachefs) 在确保 inode 编号在已挂载文件系统中的所有子卷/快照中保持唯一性方面，存在很多问题，这会让 rsync 和 tar 等工具感到困惑。

他说，64 位 inode 空间太小，无法保证唯一性，但已经使用了各种方案来使事情正常运行。他宁愿不“在马路上踢罐子”，，并认为文件系统开发者需要敦促用户空间开发者“尽早而不是更晚”开始使用文件句柄进行唯一性检测。

inode zero

他注意到最近关于 返回所有 inode 编号为零值的文件系统 的“争吵”，这让许多用户空间工具都出错了。随着时间的推移，这种情况会越来越普遍，因此他想知道是否有意义添加一个挂载选项，该选项会故意报告相同的 inode 编号，以便找出这类问题。Chinner 建议改为 sysctl，Overstreet 同意这是一个更好的选择。

Ted Ts'o 说，为了让用户空间接受使用文件句柄的转变，重要的是将其转变为跨操作系统倡议。许多用户空间工具的维护者希望确保工具能在 macOS 和 BSD 上正常运行。如果它能够达到使用文件句柄“得到更多前瞻性、类 POSIX 文件系统的支持”的程度，那么让足够多的用户空间转换的机会将大大提高，这样就可以在不破坏任何东西的情况下返回 inode 编号 0 了。这仍然是一个需要多年才能完成的工作，这意味着值得花时间尝试，确保它可以不仅在 Linux 上而是在更多平台上广泛地采用。

Overstreet 询问了其他操作系统对文件句柄的支持情况；Chinner 说，任何支持 NFS 的东西都必须具有某种形式的文件句柄支持。Ts'o 同意，但表示其他操作系统可能不会将文件句柄信息导出到用户空间。

Ts'o 说，作为转换过程的一部分，应该创建一份受影响程序的清单。令他“非常震惊”的是，他发现共享库加载器需要唯一的 inode 编号，因为它是通过这种方式来区分不同的库的，而他也是以这种方式发现的。Overstreet 想听听这个故事，但这是一个很长的故事，可能需要更轻松的环境才能讲述，Ts'o 说。

Overstreet 说，这个问题在 20 年后只会变得更糟，到那时，64 位将更难处理众多的 inode。如果为用户空间开发者提供了合适的工具，他们将帮助找到并解决所有问题。但 Poettering 警告说，摆脱对 inode 编号唯一性的依赖将极其困难。例如，它用于确保相同的资源不会被多次加载，因此最好提供直接解决该问题的用户空间 API。

有人讨论了各种方法来尝试向 inode 编号添加信息以解决该问题，但对于所有文件系统来说都没有通用的方法；可以说，文件系统社区还没有就如何做到这一点达成一致意见。Ts'o 问 Poettering，文件句柄（可以处理更多位）是否可以解决他的问题。Poettering 说，“文件句柄很棒”，但查询它们需要不同的权限，而且它们并非在所有文件系统上都实现，所以他仍然需要一个回退方案。

例如，他想知道是否可以为 procfs 文件获取文件句柄，尽管这个问题的答案并不完全清楚。除此之外，他还询问文件句柄的大小是否有限制；Overstreet 说它是一个字符串，所以没有限制。有人提到使用文件句柄的哈希值来创建一个固定长度的值，但会议的最后有点混乱，有多个旁支讨论同时进行。

Brauner 最后说，他最初看到要添加一个选项来为所有 inode 编号返回零的时候感到是个吓人的想法。但他认为这作为一个工具来教育用户空间，让他们知道 inode 编号并不唯一。仍然需要为用户空间提供某种 API 来确定两个文件是否实际上是相同的，但这将在稍后解决——在邮件列表中或可能在未来的峰会上。

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

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

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