这是Ceph开发每周谈的第六篇文章，记录从16年1月11号到16年1月17号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
上周，AsyncMessenger 合并了一些性能优化的补丁，按照最近的讨论，Jewel 使用 AsyncMessenger 应该有望了。另外，新的 KVStore 借鉴于之前的 NewStore 也已经出现，KVStore 区别于之前的 KeyValueStore，采用更加轻量的实现。同时，由于 BlueStore 采用了用户态文件系统，使得之前 FileStore 非常容易调试的优点丧失，为了仍然能够方便调试，FuseStore 也已经诞生，可以将后端 ObjectStore 以 Fuse 形式挂载到系统上。
BlueStore on SPDK
SPDK 是 Intel 开源的存储性能套件，主要是利用用户态实现传统设备协议栈，使用 UIO 和 PCI 实现对物理设备的访问。由于 BlueStore 实现了用户态文件系统 BlueFS，使得可以直接替换已有的 libaio 方式，而直接使用 nvme 命令发出。但是，SPDK 采用与 Intel DPDK 一样的 Sharding ＋ Polling 模式设计，与 Ceph OSD 的多线程 ＋ Pipeline 相违背，因此需要面向 SPDK 为 Ceph OSD 做大量重构工作。值得庆幸的是，Sam 早在去年就可以在 OSD OP Path 做重构，引入全异步框架，这使得在未来 OSD 会形成 AsyncMessenger ＋ Async OSD ＋ BlueStore 的全新组合。
OSD 流水线模型
目前 OSD 在 IO 请求的处理上采用类似于流水线的方式进行，流水线的每一级可以是单线程，也可以是一个线程池，上下的流水线间一般需要同步。对于线程池模型，针对高速设备，一般可以通过调整线程池内的线程数来解决该级流水线的瓶颈。因此，我们其实更关注单线程流水线。目前还存在这么几个模块为单线程结构：1.写journal；2. 写完journal回调 3. ondisk finish; 4. Apply finish; 5. WBthrottle。通过简化模块1的写journal流程以及自适应压力的设计，因此该部分单线程处理问题不大。模块2的处理逻辑也相对简单，因为压力也不大。模块3和模块4由于需要处理一些回调函数，包括给 Client 的消息回馈和内存的回收，因此其存在一定的瓶颈。解决的办法就是通过将单finisher改成多 finisher，最简单的方法是将某些固定 PG 分配给固定 finisher 处理即可，因为我们需要 PG 内部 OP 的保序。针对模块5，其实也可以按照修改 finisher 的思路进行。不过目前社区在主推bluestore，包括sage本人目前已经将主要精力放在 bluestore 上，其也在 review 一些PR时也提醒不要在 filejournal 和 filestore 上投入太多精力：-）。