通过 Fscache 和 Ceph 的初步印象

我们很高兴能够突出社区的开发工作（有很多优秀的工作！）。但当我们的社区开发者有勇气直接与社区分享他们的辛勤工作时，就更好了。最近，Milosz Tanski 一直在努力将 Ceph 和 fscache 的魔力结合起来，以帮助 CephFS 走向成功。结果是两个项目的出色工作，以及比松鼠能想到的更好的缓存，请继续阅读以了解详情！

当我接触到 Ceph 时，我立刻想到我会用得上它。
在 Adfin，我们开发了一个分布式关系（类似）数据库
专门用于存储关于我们
行业（广告）的大量时间序列数据。原始数据库将数据存储在本地并
在节点之间进行平衡，但使用 Ceph 将使我们能够
将数据存储容量与计算容量分离。在
我们之前从未真正考虑过使用网络文件系统，因为许多
要么性能欠佳，要么存在 SPOF（单点故障）。
Ceph 处理数据存储和条带化的方式解决了我们的
吞吐量和持久性要求。

CephFS 作为内核的一部分有很多优势。页面
缓存和高度优化的 IO 系统本身就投入了多年的努力
，并且尝试使用 libcephfs 复制它们将是一项艰巨的任务。添加 fscache 支持的动机
是解决如果我们切换到 Ceph 时必须做出的一个权衡；
延迟。由于现在我们的 IO 路径将不会命中本地
磁盘，而是通过网络传输许多较小的
。借助 Sage 指导我了解 MDS

和 CephFS 元数据内部工作原理，我能够很快地启动并运行
初始实现。花费大量时间
阅读 NFS 和 CIFS 代码库，以了解它们如何使用
fscache。大约一个月后，我能够对简单的
工作负载进行一些测试。
我最大的挑战来自于更复杂的工作负载，并且

大部分归结为内核中的并发性。内核和 Ceph 中有很多
同时发生的事情，例如
并发打开/关闭、MDS 消息（撤销
我们的 CACHE 功能）、从 fscache 后端读取和写入以及
撤销缓存的页面。更糟糕的是，并发错误
只会在某些工作负载中出现，有时在运行
几天后，并且很难重现。当事情变得糟糕时…
你的节点会崩溃，或者更糟，陷入忙碌的死循环。最终，我能够解决
这些问题，但这比获得
初始实现（时间长 3 倍）。最终，我能够
建立一个关于正在发生的事情的心理模型。这需要大量的阅读
内核锁定文档、阅读代码、烦扰他人
（Sage、David、Yan）以及撞墙。
fscache 添加到 Cephfs 帮助我们恢复了通过

通过本地缓存来控制延迟的大部分损失。一个不错的副作用是我
一开始没有考虑的是减少了发送到 OSD 的网络流量
。当你的客户端只有 1 千兆连接时
很容易使他们的网络连接饱和。
这是我对内核所做的第一个重大更改。

并且，由于我的更改触及了几个地方（cephfs、fscache 和
cachesfilesd），我最后的大部分工作实际上是
协调不同树之间的更改，以便最终
将其上游到主线。这并不是抱怨，实际上是
与我所做的工作有关。最终，这让我对
内核开发过程有了认识。
我认为 fscache 子系统也受益于这项工作。

David Howells，fscache 的维护者，解决了许多
作为我错误报告、测试和一些补丁的结果而产生的问题。
所有支持 fscache 的文件系统（9p、nfs、samba）都
从这项工作中受益，并且在高度并发的
工作负载中更加稳定。
我们总是很高兴听到我们的用户关于他们正在进行的项目。

如果您有任何与 Ceph 相关的开发、实际实施或任何可能与 Ceph 有关的其他内容，我们也很乐意听取您的意见！请联系我们的 社区团队 并告诉我们。感谢 Milosz 以及我们所有的 Ceph 开发者。

scuttlemonkey 结束