这是Ceph开发每周谈的第一篇文章，记录从15年12月7号到12月13号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
最近一直是老美的假期时间，部分开发者甚至从感恩节一直休息到元旦。社区的几个主力开发者都处于磨工状态，最近的Pull Request一直处于狂热的Bug Fix阶段，Sage 一直忙于PR的测试和修修补补。其实社区已经有一段时间没有BigBang特性进来了，因为大家都在准备手头的大块头，冲刺Jewel版本。Jewel将会像Firefly一样，拥入大量新特性的版本，大家做好期待吧。
Journal 合并改进尝试
众所周知 Ceph 的 Journal 和 Data 存在 Double Write 的问题，但是在实际 SSD 场景下，小 IO 请求(4KB)放大往往达到 2.5 倍，其中的原因是客户端来的一个请求，OSD 会形成一个事务然后写入 Journal。由于 Ceph 采用Direct IO，故4KB的io在加入一些元数据会增长到接近6KB，在Direct IO要求的数据对齐后，会再加入接近2k的padding，最终会形成8k一个事务写入 Journal，因此在小 IO 场景下形成的写放大非常严重。上周的 Journal 改进通过将多个事物进行合并，而后共同使用一个padding，因此在journal层面减少写放大。但是由于该逻辑的引入，使得写journal的逻辑变得复杂，故该逻辑比较适合中速的设备（如sata ssd），不适合高速设备 Pcie SSD。
RDMA/Infiniband 现状
大概每个月都会有 Infiniband 爱好者发邮件问社区 Ceph 对于 RDMA/Infiniband 的状况。恰好笔者过去两年有大量时间花在 Ceph 网络模块上，这次也简单介绍一下这部分近况。Ceph 在14年前都只有一个以线程模型实现的网络库，消耗大量CPU切换和内存消耗，在14年中笔者和来自CohortFS/Mellanox 的开发者差不多同时进行了新网络库的实现，后者使用了Mellanox的Accelio库(一个处于Heavy development的网络实现)。大概在14年下旬，在邮件列表和一次在线视频会议上讨论了两个实现，因为笔者是基于原有的应用协议改写实现(完全兼容原有协议)，因此首先合并入主干。大概在年底基于Accelio的方案(XIO)也进入主线，用来试验支持RDMA。
由于Ceph的网络库存在大量的模块依赖和黑魔法，从去年底到今年年中，笔者的网络库才通过了所有QA测试并稳定下来，在Jewel版本应该会替换原有实现。而XIO方案由于涉及上游Accelio的依赖，在过去的半年多时间里没有太大的进展，仅仅停留在跑通IO上。笔者并没有参与到这个实现的开发中，但深知这个模块由于不兼容原有协议，深深地踩入了Ceph的网络黑魔法中。大概在今年中，笔者与Sage Weil沟通并开始着手实现基于ibverbs 的传输协议插件。
NewStore 进展
熟悉 Ceph 存储引擎的开发者肯定对目前的FileStore，KeyValueStore和NewStore有所了解，NewStore是基于KeyValueDB(Metadata)加上FileSystem(Data)的实现，希望拥有成熟文件系统对于数据的空间管理，又拥有KeyValueDB对于元数据高效查询的优势。但在实际的开发过程中碰到众多问题，不能在通用场景下获得超越FileStore的显著性能。
在上个月，Sage Weil发帖宣告实在忍受不了XFS和RocksDB带来的协作问题，忍受不了带来的额外元数据IO，宣布自己将一捅到底，直接实现一个简单用户态伪文件系统(BlueFS)，将RocksDB基于此运行。让我们期待这个全新的BlueStore(NewStore的替身)的未来！