这是Ceph开发每周谈的第三十七篇文章，记录从16年8月14号到16年8月20号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
上周 Ceph 并没有太多可述进展
NVME Over Fabric
NVMF 在最近的几次存储会议上无疑是热点，始于今年年初内核 NVMF 的重大进展。作为 Ceph 开发者，其实离 NVMF 还挺远的，NVMF 所抠出来的几十us还填不平 Ceph encode/decode 的沟壑(泪…)。
但是这并不阻碍 cepher 去评估 NVME 在 Ceph 生态圈的可能性。
1、SPDK: Intel SPDK 中用户态 NVME 驱动在 BlueStore 实现是目前 Ceph 离 NVME 热潮最近模块，实际上笔者也在潜移默化推动 Ceph OSD 整个 IO 路径 Sharding/Lock free 化，阻止大家时不时想要堆线程提高并发的思路 :-
2、RDMA: 在半个月前，AsyncMessenger 完成了后端插件化后，不同网络插件的接入变得更加灵活，RDMA 在 AsyncMessenger 的实现已经很近
3、NVME over Fabric Backend: 在目前的 NVMF 链条中，Initiator 是个主要 GAP，众所周知 Mellanox 是 Infiniband/RDMA 的霸主，其垄断和自有 OFED 包几乎让所有 RDMA 开发者为此受伤，每个操作系统发行版不同的 OFED 包，对应不同的驱动，甚至每个发行版里的小版本都有独立的 OFED。而 NVMF 内核实现要在 4.8 以上。不管是 Initiator 还是 Target 端，如何磨平 Mellnaox 的疯狂版本和 NVMF 高高在上的内核是每个 NVMF 用户的痛。笔者深深感到这已经给用户筑起了高高屏障，对于后面再来的 NVMEDirect 路线，实际上我深深怀疑在未来一年，在内核里会出现一次 NVME 路线的大 PK，如同当年 iSCSI 一样(:-)。
4、NVME over IP: 只能说这个在落地目前还只是大家在 YY，但是，有一些厂商已经开始行动，受不了 RDMA 的摧残。
FAST 16 几篇
The Composite-file File System: Decoupling the One-to-one Mapping of Files and Metadata for Better Performance
主要的思路是把多个文件的 inode 合并，这样文件的权限信息，所有者和组信息都一样的可以省略，因为在传统文件系统使用中，大量相关文件的元信息总是一样，如果缓存在同一个 inode 可以大大减小 inode 的缓存量，提高 inode 命中率。
Isotope: Transactional Isolation for Block Storage
实现了一个事务性的块存储接口，传统块接口虽然是强一致性语意，但是在原子性，隔离性上却是只能上层保证，因此两个 inflight ops 如果存在 overlap 是可能损坏的。这篇论文主要讨论实现了基于块接口的事务，其实从某种角度上来讲，是 KeyValue 类似，只是增加了 offset 语意。另外一方面，这个语意实际上跟 SSD 的 FTL 已经非常类似了。
WiscKey: Separating Keys from Values in SSD-Conscious Storage
一般的 key value 数据库通常是将 key 和 value 存放在一起，如 leveldb 这类 LSM 结构。但是这类数据库通常为 HDD 顺序写优化，而 SSD 相对而言有更好的并发度和随机 IO 性能，而写放大也会导致 SSD 损害。而这篇论文的 WiscKey 继承了 LevelDB 实现，但是将 key 和 value 分开存放，Key 仍然像之前一样用 LSM 管理，而 Value 使用 Log 进行 Append Only。这样使得 LSM 的写放大只局限在 Key，同时 LSM 的优点如插入，查询都能继承。挑战主要在 value 和 key 在顺序上的不连续导致顺序查询性能降低，WiscKey 采用了随机预读的方式来解决顺序问题，这样利用了 SSD 的高并发性。
从结果来看，性能能够比传统 LSM 数据库提高很多，这也是预料之中。