LWN：讨论composefs！

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

Debating composefs

By Jonathan Corbet
February 16, 2023
ChatGPT assisted translation
https://lwn.net/Articles/922851/

去年 12 月，LWN 曾经报道过 Composefs 文件系统，并称针对这些 patch “几乎没有任何反馈”。但是现在情况已经发生了改变。Composfs 是否应该合并已成为一场持续很久的争论话题。讨论的核心问题是 Linux 应该如何支持某些类型的 container workload （容器工作场景）。

Composefs 是一种有趣的文件系统，mount 上来的实例实际上是两个独立部分的组合。其中一个是“对象存储， object store”，这是一个包含了许多有用文件的目录树，文件的名称可能反映了它们的内容的哈希值。对象存储通常都位于自己的只读文件系统上。另一个是“manifest”，可以将人类可读的名称跟对象存储中文件的名字对应起来。Composefs 使用 manifest 来创建对用户可见的文件系统，同时将对象存储隐藏了起来。这样得到的文件系统是只读的。

此机制旨在针对容器来创建系统映像。设计容器时，可以从一个基本的操作系统映像文件开始，然后添加一些包含了该特定容器 workload 所需软件包的 layer。使用 Composefs 的话，对象存储包含所有可能与系统相关的文件，而用于任何一个特定容器的映像的组合则是在 manifest 文件中完成的。这样得到的就是一种更灵活的机制，可以比其他替代方案能更快地挂载系统映像，同时允许使用 fs-verity 来验证对象存储并在系统中的所有容器之间共享。

The v3 discussion

Composefs 的第三版 patch 于一月底发布，其中包含了前几个版本的 review 人员提出的一些改进点。然而，Amir Goldstein 并不完全满意已经完成的工作，他建议开发者（Alexander Larsson 和 Giuseppe Scrivano）不要提出 composefs，而是应该将精力放在改善现有的内核子系统（特别是 overlayfs 和 EROFS 文件系统）上。

之后进行了长时间的关于 composefs 价值（或着说有没有价值）的讨论。目前有两个方案可以在容器使用场景下替代 composefs：

• 在容器启动时，通过创建大量符号链接到目标文件实际所在的位置，从而组装出系统映像。这种方法的启动时间过长，创建成千上万的符号链接时，每一个都需要至少调用一个系统调用，这需要时间。
  

• 给容器提供只读文件系统上的基础映像，然后使用 overlayfs 在其上叠加一个或多个 layer 来创建容器特定的映像。
  

这里的共识似乎是，由于符号链接方法启动时的开销太大，所以不能作为 composefs 的可行的替代品。Goldstein 和其他人认为 overlayfs 方法可能是可行的，尽管可能需要对该文件系统进行一些更改。但是 composefs 的开发者并不那么确定。

Considering overlayfs

Scrivano 表示，目前 Overlayfs 的一个不足之处是，它与 composefs 不同，无法为整个文件系统提供 fs-verity 保护。任何影响 overlay layer 的更改都会绕过该保护。Larsson 描述了一种 Overlayfs 的可以达到这个目的的配置（需要对 Overlayfs 进行一些改进），但对此并不热衷：

然而，我对 Overlayfs 这种方式的主要担心是它有点笨拙和过于复杂。基本上，composefs 方法专注于只读镜像，而 Overlayfs 这种方式仅仅是将一些可以用的上的技术连接在了一起，同时也做了很多其他事情。

他说，Overlayfs 解决方案中的额外复杂性会导致性能损失。用来展示这一点的 benchmark，是创建一个文件系统，然后测量针对整个文件系统执行 “ls -lR”所需的时间。在没有缓存（cold-cache）情况下，Overlayfs 解决方案需要大约四倍的运行时间；在有缓存（warm-cache）情况下，性能差异小很多，但是 composefs 仍然更快。

Goldstein 强烈反对上面对 Overlayfs 解决方案的评判；他还开始了一个关于“ls -lR”基准测试是否有意义的邮件讨论分支。他补充道：“我明白了。composefs 确实针对 ls -lR 进行了专门的优化。现在只需要弄清楚，是否现实生活中真实用户启动容器并执行 ls -lR 而不读取很多文件是不是一个典型场景。”

Dave Chinner 加入了对这个测试的辩护：“cold-cache 性能更加关键，对于生命很短暂的容器以及那些在运行时占用内存空间达到了容器限制的 host 主机，ls -lR 只是一个微型基准测试，演示了 composefs 的 cold-cache 方面的表现比提议的替代方案要好得多。”

他补充说，多年来他一直使用类似的测试来评估文件系统的性能，并从未向任何人证明过。Larsson 同时解释了对这种性能指标（或“关键绩效指标”-KPI）的重视：

我的当前的工作是在汽车行业，他们希望将 workload 移到汽车上的容器里。主要的 KPI 就是冷启动性能，因为整个系统启动需要满足 2 秒这个法律强制要求。在 cloud 中的工作负载里，通常会用到那些声明周期非常短暂的容器，因此启动时间非常重要。实际上，过去几个月我一直在全力投入去优化容器启动性能（可以在即将发布的 podman 4.4 中看到这方面的巨大改进）。

Goldstein 最终接受了这个指标的重要性，并建议可以改进 overlayfs 来提供更好的 cold-cache 性能。Larsson 回答说，如果 overlayfs 可以进行修改来解决性能差距，那么它可能是更好的解决方案；他还对性能差距是否真的可以缩小以及是否有意义添加更多复杂性到 overlayfs 提出了疑问。

这部分讨论的结论是，后续会尝试一些实验来使用 overlayfs 从而确认是否可行。Overlayfs 维护者 Miklos Szeredi 大多数时候没有参加讨论，但简要评论过一些提议改动，认为可能是有意义的。

The EROFS option

然而，在讨论中也多次提到了另一种选择：改进 EROFS 文件系统，来包括 composefs 所提供的功能。EROFS 是用于嵌入式只读操作的文件系统，已经支持了 fs-verity。EROFS 的开发者 Gao Xiang 一再表示，该文件系统可以改进来实现 composefs 提供的功能；实际上，其中许多功能已经作为 Nydus 机制的一部分了。不过，Scrivano 对这个想法提出了质疑：

当然，composefs 很简单，你可以将 composefs 的功能嵌入到 EROFS 中，让 EROFS 在提供类似 manifest 文件的情况下像 composefs 一样运行。但是，这有什么优点呢？将不同的范例合并在一起比拥有一个只做一件事情的独立实现就更好吗？

Gao 认为，composefs 开发人员迟早会想要添加支持存储文件数据（而不仅仅是 manifest metadata），到那时，composefs 将开始看起来更像一个普通的文件系统了。这时可能就不会有那么强烈的依据来说它跟其他文件系统区别对待。

在讨论过程中，针对这个场景也发现了一些 EROFS 的性能缺点，并实现了各种 fix 方案。Jingbo Xu 运行了许多基准测试，来衡量对 EROFS 和 overlayfs 的 patch 的效果，但尚未展示出其他两个选项中的哪一个可以胜过 composefs。不过，这项工作目前还处于早期阶段。

可以想象，这种零散的讨论并没有决定是否合并 composefs 还是将开发工作投入到替代方案。在接下来的几个月中，可能不会得出任何结论。这正是即将到来的 LSFMM/BPF 峰会旨在达成的决定之一；在那个场合下可能会有一次有趣的讨论。

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

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

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