LWN:合入bcachefs!
关注了就能看到更多这么棒的文章哦～
Merging bcachefs
By Jake Edge
June 16, 2023
LSFMM+BPF
DeepL assisted translation
https://lwn.net/Articles/934692/
bcachefs 文件系统及其推送到 upstream 的过程是 bcachefs 的创建者 Kent Overstreet 在 2023 年 Linux 存储、文件系统、内存管理和 BPF 峰会上远程主持的会议的主题。他在前几届峰会上也讨论了 bcachefs，第一次是在 2018 年，还有一次是在去年。这两次讨论中，都有提到将 bcachefs 合并到 mainline 内核中的问题，但到现在仍然没有 merge。不过这一次，Overstreet 似乎比以往任何时候都更接近于真正开始这个过程。
他在演讲开始时指出，他一直在说 bcachefs 差不多已经准备好合并了。“现在我说，我们终于该做这一步了”。他想报告一下这个文件系统的状态，以及为什么它现在已准备好 upstream，但他想利用会议的大部分时间来讨论推到 upstream 的过程。“这是一个巨大的，90，000 行代码的巨兽”它需要 review，所以有必要弄清楚进行 review 如果进行。
他对 bcachefs 的目标是拥有“具有类似于 XFS 的性能，可靠性，可扩展性和健壮性，以及跟得上时代的各种功能”。这是一个很高的标准，bcachefs 还没有达到，但“我认为我们已经走得很远了”。人们在 100TB 文件系统上运行 bcachefs“没有任何问题或投诉”;他正在等待第一个 1PB 文件系统出现。他说，“snapshot 功能的在更大 size 下也可以很好扩展支持”，而 Btrfs 就有这方面的问题，这是根据用户的抱怨来得到的信息。
Status
在过去的一年中已经完成了很多可扩展性方面（scalability）的工作，其中大部分都是需要深入地重写，包括历史可以追溯到 bcache 的一个分配器。有一种新的“写入时无复制”（nocow）模式，并且已实现 snapshot 功能。他说，人们正在使用这个快照功能来备份 MySQL 数据库，这是对该功能稳健性的测试。
[Kent Overstreet]
擦除编码（Erasure coding）是他想在上流式之前进入 bcachefs 的最后一个真正重要的功能。但他认为“是时候在沙子上画一条线了”，所以可以等到今后再说。还有很多工作要做，但“大块功能相关的工作正在减少”，他将能够成为一名维护者，而不必像他在 snapshot 开发时期所做的那样，消失一个月来做具体的开发。
bcachefs 团队正在壮大。Red Hat 的 Brian Foster 在 bug fix 方面做了很多重要工作，Overstreet 说。Eric Sandeen 也帮助吸引了人们对红帽 bcachefs 的兴趣。每两周有一个关于 bcachefs 开发相关的电话会议。Overstreet 说，已经添加了自动化测试的基础设施，它“使我的生活更加轻松”。测试系统需要阴性大约半小时，包括多次运行 fstests 以及 bcachefs 的“非常庞大的测试套件”。
Rust 是他一直在向“任何愿意倾听的人”宣传的语言;他认为“当我们终于有更好的选择时，仍然用 C 编写代码是疯狂的做法”。他喜欢写代码，但不喜欢调试它;用 Rust 编写“就意味着更少需要花时间调试”。他打算在 Rust 中慢慢重写 bcachefs，这将是一个持续十多年的项目，但在 bcachefs 中使用 Rust 的工作已经开始。一些用户空间工具已经在 Rust 中重写了，有人正在考虑将其中一些工作转移到内核中。
Upstreaming
那天早上，他发布了 32 个初始 patch，用来添加 bcachefs 需要的基础设施。他说，这些补丁已经在 review 中。剩下的是他没有发布的 2，500 个补丁，包含 90，000 行代码。他确实也提供了一个指向他的 Git 仓库的链接，这些补丁位于 bcachefs-for-upstream 分支中。然后，他开始讨论如何 review 这些 patch 从而最终合并。
Josef Bacik 说，他认为人们的反应将与去年大致相同。文件系统开发人员“非常高兴”看到 bcachefs 被合并。他不打算 review 文件系统本身的实现，估计所有人都会这样做。正在研究它的人会 review，“相信自己这部分”。“通用的东西是我们需要 review 的”，在这部分 review 之后，这个文件系统的其余代码就可以合并了，至少是他的观点。当然，这最终取决于 Linus Torvalds。
Overstreet 说，他的一个问题是：“我们提供什么给 Linus？”去年，他花了一年时间研究流程和基础设施，组建团队，与红帽合作，组建自动化测试套件等等。Mike Snitzer 远程指出，最近被拒绝的补丁集包含了两个基本上无法 review 的巨大 patch;他将其与构成 bcachefs 的 2，500 个小 patch 进行了对比，指出后者更容易消化。
虽然 Snitzer 不确定让每个人都应该 review 来逐一检查，但这组补丁系列开发过程中的努力程度，让人们更容易信任代码以及开发流程。“你已经完成了繁重的工作，完成了所有这些工作来拆分 patch。Overstreet 表示，要重新构建差不多整个历史记录需要做很多工作，但是大约六个月前，当 Red Hat 注意到一些重大的性能退化时，它就派上了用场。他能够利用这段历史来自动进行 bisect 二分法查找，把性能基本上恢复到了从前的样子。
Bacik 说，Torvalds 是负责合并新文件系统的“维护者”，因此由他决定是否愿意将完整的历史记录拉入 mainline。Bacik 更希望这样做，因为 git 历史“超级有用”，但这不是房间里的人可以决定的。他建议，pull request 更多的是关于完整的历史是否可以接受，如果不能的话，会是什么接受什么样子的。
这里有一个问题，一旦 bcachefs 被合并，除了 Overstreet 之外的任何人都很难处理 bug report，Amir Goldstein 说。在 pull request 中对其进行解释是很重要的。“我想合并并且我有一个团队可以支持这个”。能获得更多帮助是 upstream 之前的标准之一，Overstreet 说。他知道，如果这一切都是一场独角戏的话，他会被 bug 报告给淹没的，他会“发疯，逃到南美去”。Foster 一直在提供“巨大的帮助”，这也是他之所以人为目前可以走到 merge 状态的原因之一。
有些矛盾的是，最近从内核中删除了一些文件系统（例如 ReiserFS），这实际上将使添加新文件系统变得更加容易，Ted Ts'o 说。他记得 Hans Reiser 对他的新文件系统充满热情，并有一个团队来支持它，但多年之后这一切都变得年久失修。内核项目现在有一个流程可以用来在弃用期之后把这个文件系统的支持移除掉。“接受文件系统不意味着永远接受，这使得合并新文件系统变得更加容易”。
他还建议将这组补丁分解为更小、更易于 review 的组合，每个组合都包含少量相关的 patch。这将使人们更容易在一个组合中查看所有 lockdep 相关的改动。这意味着会放宽关于在第一个调用者合并之前不合并基础设施的原则，他赞成。他将修改该准则，从而允许在它包含指向第一个调用者的 Git 树的链接的情况下就可以进行合并。
Overstreet 认为，他当天早些时候发布的初步报告不会有太大争议，除了可能一两个之外，都“会顺利通过”。他指出，Christoph Hellwig 反对 vmalloc_exec() 补丁，尽管 bcachefs 需要该功能，Overstreet 说。自演讲以来，Mike Rapoport 提出了 JIT allocator，这可以根本性地解决问题。
一位远程参与者说，Foster 的经历就表明，这组代码是比较容易上手的。在 bcachefs 合入之后，感兴趣的开发人员将能够跟上来，开始工作，几乎不会有困难。Christian Brauner 要求明确说清楚，如果 Overstreet 不在的时候，还有谁可以介入进来并 merge 补丁。Brauner 指出，NTFS/NTFS3 维护者消失了，尽管有人为该文件系统做出了贡献，但不清楚“谁可以将 patch 推送到 upstream 去”。Overstreet 表示，如果 Foster “愿意挺身而出”的话，他会完全信任他能承担好这个角色。
Brauner 说，他认为 bcachefs 处于“走向上游的绝佳状态”，但他担心内核中的文件系统数量。他高兴地看到，有人努力消除其中一些。今后如果有改动会影响代码库中的所有文件系统，那么相关的改动“很快就会变成痛苦”，在某些情况下，没有人可以审查这些改动。他希望接受文件系统的过程可以变得更加保守。例如，接受 NTFS / NTFS3 是“一个巨大的错误”。Brauner 说，这些都不是针对 bcachefs 的，而是一个更普遍的问题。文件系统的接受和弃用在当天晚些时候的闪电演讲（YouTube 有视频）中被讨论到了。
Darrick Wong 说，他已经开始按照 Ts'o 在 XFS online repair 中的建议去做了实现。他有一系列基础设施 patch，调用者也会不久之后出现。他说服了 Dave Chinner，不光着眼于这个功能的更大图景，也是有必要 review 基础设施部分代码的。这对他很有帮助，因为他可以停止“反复 rebase 和不得不玩 code golf，类似于在 patch set 中上下移动一个 helper 函数的 patch 的先后次序”。他说，把所有这些东西放在一组单独的基础设施 patch 中对他很有好处，尽管它确实引起了 review 人员的一些抱怨，但这种方法也已经有一些先例了。
Overstreet 表示，他并不特别关心他需要合入的 30 个左右“相对简单”的基础设施补丁。他将等待 Acked-by 和 Reviewed-by 标签出现，但如果没有出现的话，那么他将使用人们建议的方法“作为 B 计划”。至此，会议结束。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～