LWN：分布式备份存储文件系统：ngnfs！

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

A distributed filesystem for archival systems: ngnfs

By Jake Edge
June 20, 2025
LSFMM+BPF
Gemini flash translation
https://lwn.net/Articles/1025650/

Zach Brown 在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 上主持了一场关于新型文件系统的会议。该 ngnfs 文件系统并非如其名称可能暗示的“下一代”NFS (网络文件系统)；Brown 表示，直到 Chuck Lever 在一封电子邮件中向他指出这种关联时，他才想到（“我太讨厌命名了”）这一点。相反，它是一个主要存储在离线的巨型数据集的文件系统。

他为 Versity 工作，该公司拥有一套“归档软件栈”，用于存储“包含大量文件且文件内容大多已分层归档到离线存储的超大型数据集”的产品。他说，这意味着没有任何文件内容再保持在线状态，这对文件系统开发者来说是最难以理解的事情。该文件系统是元数据密集型系统，归档代理主要对扩展属性 (xattrs) 进行元数据更改，这些属性描述了文件内容当前的存储位置，包括数据所在的存储层级以及在介质（例如磁带）上的位置等信息。

归档存储层具有“高聚合带宽”，足以淹没任何单个驱动系统的宿主主机。因此，它是一个分布式 POSIX (可移植操作系统接口) 文件系统，例如，“为八台都连接了大量磁带驱动器的机器提供服务”。Brown 说，这就是该文件系统的背景：“大量文件，主要进行元数据流转，但令人恼火的是，随着文件内容的流动，我们需要大量聚合带宽，这样就不是一个节点来完成所有这些工作了。”

他称该文件系统为“引擎文件系统”，并说这个名字来自他开始开发时所用的“下一代”；他使用“ngn”并始终将其发音为“engine”。他说，这让他产生了一个盲点，没有意识到 NFS 嵌入在名称中，他笑着说道。

他使用 GlusterFS、ocfs2 和其他分布式文件系统的经验，使他尝试消除在这些文件系统中观察到的瓶颈。ngnfs 的理念是最大限度地缩短两个必要元素之间的路径：应用程序端点和持久存储端点。许多竞争系统都有大量其他“你需要流经才能完成所有这些工作的额外内容”，例如锁机制；他说，这使得这些系统难以理解和推理。

ngnfs 背后有三个“核心思想”，尽管它们都不是革命性的；Brown 轻笑着说：“这只是我用自己的方式，以一种‘最不糟糕’的方式来解决这组约束条件”。有每个设备一个的用户空间服务器，这样集群中的每个归档设备前面都有一个处理器。服务器之间通过网络协议与网络端点通信。最后，还有一个客户端，“通过在块之间进行读写来构建 POSIX 行为”，这些块由服务器提供。他说，所有这些听起来都应该很熟悉，“但我们构建协议的方式以及客户端获取其块集合时的行为方式，使得这有点不同”。

网络协议非常精简；Git 仓库中“几乎没有什么”。该协议是面向块的，采用小型固定大小的块以及预期的读写操作。写入操作稍微复杂一些，因为它是在所有服务器上进行分布式写入。读写操作具有额外的缓存一致性信息，以便读取方例如可以指定它们也将写入一个块；对于重命名等操作，没有更高级别的锁，因为锁是在块级别。这种缓存一致性协议“某种程度上是它有趣的核心”。

由于服务器端有一个智能端点，它可以帮助客户端做出一些决策。因此，并非所有操作都只是简单的读写；有一些“更丰富的命令，让它（服务器）能够探索这些块并为你做出选择”。他不想深入细节，但块分配是一个需要服务器智能的领域。

对他来说，客户端是最有趣的部分。理解客户端的关键是“我们确保这些块修改安全的方式”。对于大多数内核文件系统，有一个互斥锁 (mutex) 保护一组块，因此那些受保护的块可以被读写，但 ngnfs 已经取消了这些互斥锁。相反，块被组装成事务对象；如果它们正在被修改，客户端对所有块都具有写入权限，因此它们可以在内存中标记为脏；“当其他人需要它们时，它们将作为一个原子写入离开”。读取也使用事务对象，但无需跟踪脏块。

Brown 意识到与会者会立即想到 ABBA 死锁；这就是客户端代码旨在避免的问题。客户端尝试以块遍历顺序获取块访问权限，但该顺序可能会改变，因此客户端的结构是使用尝试锁 (trylocks)，即尝试获取锁，如果无法获取则不阻塞。如果失败，客户端必须回溯并重新获取所需块的访问权限。他说，这样做会有开销，但通过将其本地化到客户端，可以使用块粒度锁定方案，从而避免更广泛的锁定。回写缓存是“这样做的主要动机”；一个经典的例子是解压缩 (untar)，它只是在内存中标记一堆块为脏，然后“你不需要为每个逻辑操作进行往返”。

Josef Bacik 询问 ngnfs 如何处理其元数据密集型工作负载；他看到人们在其他文件系统上处理这类工作负载时遇到了困难，增加了元数据服务器和其他复杂性。Brown 说，这一切都归结为块。文件系统开发者如果将其视为“最笨、最简单的块文件系统，然后用一致性协议把这些块通过网络‘喷洒’出去”，就会觉得很熟悉。这些块包括一切：inode 块、间接块、目录项 (dirent) 块、扩展属性等。

Christian Brauner 问客户端是否已经存在。Brown 说“差不多”；在 Git 仓库中，有一个 debugfs 网络客户端，它包含了一些围绕虚拟文件系统 (VFS) 操作的薄层封装，用于文件创建、重命名等。还有一个执行块 I/O 的服务器。

Jeff Layton 询问了文件锁定，Brown 说目前尚未实现。目前没有这方面的请求，但如果有人请求，将以块为中心的方式完成。他认为，正在使用的应用程序不会争用文件，因此没有真正的锁定需求。“直到它们开始争用，那时你就不得不处理了”，Layton 说，Brown 对此表示认可。

Brauner 询问 ngnfs 是否需要任何 VFS 更改。Brown 说不需要；所有的事务、尝试锁和重试都将在客户端实现中处理。

Brown 在总结时说，除了块粒度争用（这有助于自然地避免需要更高级别的锁定）之外，他对 ngnfs 提供的在线修复可能性最为兴奋。客户端可以执行“不一致读取”，即块可能已过时或正在修改中，但修复过程可以检查服务器上所有可用的内容。如果数据以某种方式不一致，则可以通过比较并交换操作重写整个范围；服务器可能会识别出块已更改，并要求修复操作获取新块。整个修复过程可以在多个客户端上并行进行，以持续确保块保持一致。

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

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

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