Linus vs FUSE

我无法确定 Linus 对人们对他的言语反应过度，或者对他的随机抱怨感到恼怒。人们仍然谈论他对 O_DIRECT 和跳跃猴子 的声明（现在已包含在 open(2) 手册页 中）。最近的骚动是他宣布所有 基于 FUSE 的文件系统都是玩具。

显然，正如 许多 人 指出 的那样，称所有这些系统都是“玩具”并不完全公平。但如果它完全属实，说出来就不会有趣。基于 FUSE 构建了真实的系统（大而快），就像使用 Java、Visual BASIC、Cobol 和我们喜欢嘲笑的每种其他平台/技术构建的系统一样。

我还没有看到 PLFS 在讨论中出现，但我认为值得一提，因为它是一个很好的例子，可以针对对你的工作负载真正重要的情况进行优化。对于那些不熟悉的人来说，PLFS（并行日志结构化文件系统）是 LANL 为他们的大型数千节点集群构建的基于 FUSE 的文件系统，它通过构建一堆中间索引将所有随机 IO 转换为顺序 IO。听起来会是一场灾难，但在实践中，它使他们的工作负载速度提高几个数量级，仅仅是因为它所堆叠的基础并行文件系统对这些工作负载非常糟糕。

无论如何，关于内核与用户空间文件系统，我想提出几点，因为我已经使用 Ceph 客户端使用这两种方法实现了它。冒昧地说

• 你无法在用户空间中做任何事情，而你也不能在内核中做同样的事情。当然，在内核中开发可能更难，但你拥有对系统的无与伦比的访问权限。内核实现中唯一的重大技术劣势是故障隔离：一个有缺陷的基于 FUSE 的文件系统不会将其自身带下来。
• 使用 FUSE 实现起来更容易。至少对于一些基本的东西来说。由于接口的限制，有一些关键问题更难解决。
• 内存管理在内核中更容易。AB 在 他说 时是对的，内存管理和文件系统需要协同工作。问题是，当你不是机器上唯一的租户时，很难将内存管理推送到用户空间。（我怀疑，在大多数使用用户空间文件系统的生产环境中，文件系统要么是唯一的租户，要么被赋予了固定数量的 RAM 来工作。）另一方面，内核 VM 将根据系统所有用户的需求动态应用缓存压力。尝试在用户空间中做到这一点，充其量是非常尴尬的。
• 管理缓存一致性在内核中更容易。有些人不在乎这一点（例如，参见 NFS，或 Linus 提到的“玩具”），但我们关心。这主要是由于 FUSE 接口的限制。你可能可以通过简单地不使用内核 dentry 和页面缓存并完全在用户空间中重新实现它来避免这个问题。这是一种足够简单的方法，但速度慢，并且无法利用多年来投入到核心 Linux VFS 代码中的工作。
• FUSE 可能要承担一部分责任。Jeff Darcy 已经指出，许多 FUSE 的缺点并非源于用户空间存储本身，而是当前接口和内核政治的产物。也许是这样，但这就是我们所处的世界。任何无法在 Linux（或也许 *BSD）上工作的的文件系统都是无关紧要的。而且，值得一提的是，我看到的大多数抱怨内核社区不合作的人甚至没有尝试上游工作；只要你推送的代码不是垃圾，这比你想象的要容易。

对于任何给定的项目来说，哪种方法更好，可能更多的是一个商业决策：技术投资、性能、上市时间、易于部署。但是，如果仅仅从环境的技术限制来看，很难打败内核。

或者，如果你能做到，就同时实现两种方法。这会让这种争论更有趣。