LWN：推动 Lustre 文件系统进入上游！

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

Getting Lustre upstream

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

Lustre 文件系统历史悠久，其中一部分与 Linux 有交集。它于 2013 年被加入到 staging 树（staging tree）中，但由于进展缓慢以及开发模式与内核不兼容，于 2018 年被移出 staging。然而，Lustre 可能正在努力回到内核中。在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 的文件系统专题会议上，Timothy Day 和 James Simmons 领导了一场关于如何将 Lustre 引入主线 (mainline) 的讨论。

Day 首先概述了 Lustre，称其为“高性能并行文件系统”。它通常被用于那些拥有大量 GPU、需要持续馈送数据（例如人工智能 AI 工作负载），以及需要对高性能计算 (HPC) 工作负载记录检查点 (checkpointing) 的系统。文件被分割成多个块，存储在不同的服务器上。客户端和服务器的实现都运行在内核中，这与 NFS 类似。在过去的十年甚至更长时间里，网络传输和磁盘格式一直“相当稳定”，“变化甚微”；Lustre 在不同版本之间具有良好的互操作性，不像过去那样服务器和客户端必须使用相同版本。

他表示，上游化项目（upstreaming project）到目前为止已经进行了很长时间。客户端的一个分支被添加到 staging 树并驻留了大约五年，之后“它被移除了，主要原因是进展不足”。它“不适合”内核，因为大多数开发者都在树外版本（out-of-tree version）上工作，而不是 staging 树中的版本。

但“真正进入上游的梦想仍在继续”。自从被移出后，已经有 1000 多个补丁旨在让代码为进入内核做好准备；其中大约 600 个来自 Neil Brown，200 个来自 Simmons。Simmons 说，自 staging 移除以来，进入树外代码仓库的补丁中，大约有三分之一与上游化目标有关，其中许多是非合并变更集 (non-merge changeset)。

Day 说，最大的问题是该项目如何从其树外开发模式转变为以内核上游仓库为基础的模式。目前的状况是“一个巨大的文件系统，为了兼容各种内核版本而被 `#ifdef` 宏定义搞得一团糟”。下一个阶段目前正在进行中，预计将在未来一年左右完成，即是将兼容性代码从核心文件系统代码中分离出来；目标是最终为这些部分建立两个独立的开发树。核心文件系统开发树将进入内核开发树，而兼容性代码（旨在支持使用旧内核的客户）将继续存在于 Lustre 仓库中。

另一个需要关注的领域是开发流程的改变，以便更好地与内核开发融合。Lustre 项目不使用邮件列表；它使用 Gerrit 实例。“我们必须弄清楚如何适应。”Simmons 说，有些开发者完全是 Gerrit 导向的，有些则可以适应邮件列表；“我们必须弄清楚如何取悦这两类受众”。

Amir Goldstein 表示，唯一的实际要求是项目在合并前将补丁发布到邮件列表一次；没有义务在列表上进行补丁审查。Simmons 说，自从 Lustre 被从 staging 移除以来，他和 Brown 一直维护一个 Git 仓库；它保持同步并更新到较新的内核。他说，所有补丁都发布到 lustre-devel 邮件列表和一个 Patchwork 实例，因此所有历史记录都是公开的，可供评论或批评。

Josef Bacik 询问了 Lustre 在 staging 树中时出了什么问题。从他的角度来看，Lustre 已经存在了很长时间，没有迹象表明它可能被放弃，那么为什么它没有跳入主线的 `fs/` 目录呢？Simmons 说，该项目通常在任何给定时间都有几个不同的功能正在开发中，但负责 staging 树的 Greg Kroah-Hartman 不希望有任何不是清理性补丁的提交。因此，staging 版本越来越落后于树外代码。Bacik 说这对他来说说得通；“那就像是让你注定失败”。

Christian Brauner 表示，他希望为合并新文件系统制定一个“更精简的模型”，即由文件系统社区集体决定是否进行合并。社区最近“被‘任何人都可以提交文件系统供包含’的做法严重灼伤了，然后它进入上游，我们不得不处理所有的后果”。作为一名 VFS 维护者，他不想成为那个做决定的人，但合并一个新的文件系统“会给整个社区带来负担”，因此这应该是一个共同的决定。

Bacik 重申，没有人担心 Lustre 开发者会消失，但还有其他担忧。例如，Lustre 必须普遍使用 folio，并且正在使用“所有现代技术”，这一点很重要；他说，他这样说有点傻，因为 Btrfs 仍然只完成了一半。Simmons 说，Lustre 开发者完全同意；目前有人正在进行 folio 转换。在峰会上，他与 Day 一直在与 David Howells 讨论使用他的 netfs 库。

Jeff Layton 询问计划是否是同时合并客户端和服务器。Simmons 说，大多数人只要求合并客户端，而且客户端的代码库进展较慢。客户端“每月有几百个补丁，服务器的补丁量是客户端的三到四倍”，这使得跟上内核的步伐变得更加困难。Layton 说：“小步前进是好的”，不过 Day 指出，如果没有内核中的服务器代码，测试 Lustre 会更困难。

Ted Ts'o 表示，他一直推动只合并客户端的原因是服务器与 ext4 “关系非常密切”。服务器需要大量 ext4 符号，而且“需要弄清楚如何处理”。这会影响 ext4 的开发，但其他更改，例如重写 jbd2 日志层使其不再需要 buffer heads 的计划，也可能因为包含 Lustre 服务器而变得复杂，他说。

Simmons 询问在 Lustre 进入上游之前，是否可以将补丁发布到 linux-fsdevel 邮件列表，以便内核开发者可以开始熟悉代码。Bacik 说这说得通，但他不会真正深入研究 Lustre 的内部；他更关心使用的接口以及 Lustre 代码是否会给内核文件系统社区带来维护问题。Goldstein 建议建立一个 Lustre 专用邮件列表，但 Simmons 指出 lustre-devel 已经存在并且正在归档；Brauner 建议将其添加到 lore.kernel.org。

Goldstein 说，目的是当 Linus Torvalds 收到新文件系统的 pull 请求时，他能够看到代码在此之前已经公开发布。Ts'o 说，如果 Git 开发树在 git.kernel.org 上有一个镜像，也会有所帮助。Bacik 说，他认为试图在合并时保留所有现有 Git 历史记录可能是一个徒劳的尝试，尽管这取决于 Torvalds；他建议改为创建一个 git.kernel.org 归档树，人们可以查阅合并版本之前的历史记录。

Ts'o 说，鉴于 Lustre 旨在实现高性能，支持大型 folio 将非常重要。Simmons 说，有人正在为此努力，而且这对项目很重要；计划是先获得 folio 支持，然后添加大型 folio。Matthew Wilcox 说这很好，只要面向页的 API（page-oriented API）正在被转换。其中许多 API 正在慢慢消失，因此 Lustre 开发者需要确保文件系统在这些移除之前完成转换。

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

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

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