这是Ceph开发每周谈的第十二篇文章，记录从16年2月22号到16年2月28号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
Jewel 应该会在未来两周内根据测试的结果发布第一个版本，目前在最后两周，大量的改进和 Bug fix 都在陆续合并主线。上周 Ceph Release Team 招募新的成员，负责维护已发布版本的 backport 和迭代。上周 Patric 正式宣布 Ceph Community 开始接受学生的 GSoC 申请。
-
Scrub 持久化和查询 API
上周由 Kefu 完成的 Scrub 持久化和查询实现正式合并到主线，并出现在 Jewel 版本中。该功能主要实现了对集群中不一致数据的管理和维护，在此之前，Scrub 操作的结果仅仅存留在内存和 Monitor 的日志中，并不足以支撑自动化的 Scrub 查询和操作，这个 API 的背后主要实现了将查询结果存到 OSD 中，使得客户端可以通过命令行或者 API 对于过去 Scrub 操作结果的回溯。
Scrub 是 Ceph 用来保护数据一致性的后台例程，主要分为两类，第一种是轻量级 scrub，主要通过对比元数据和 checksum 来完成，第二种是重量级 scrub，通过全量对比数据来得到结果，目前 Scrub 的执行支持按时间和实际业务情况进行调整，同时 Scrub 的 IO 操作也是低优先级来避免业务影响。
-
Jewel 剩余特性总结
从目前来看，Jewel 规划的特性目前还有 CephFS 的 fsck，多命名空间支持没有完全进入主线，RBD 的 Mirror 已经完成了大部分的基础工作，只剩下 mirror daemon 的工作，目前这部分由 Jason 和 Mirantis 主推，可能在 Jewel 进入主线仍有希望，而 RGW 这次完成了绝大部分规划的 BP，RADOS 在这期中主要的亮点是 BlueStore，AsyncMessenger 应该也会在这期去掉试验标签。
上周 Sage 提到 CephFS 的重点仍然是在内核态，ceph-fuse 以其 nfs-ganesha 的客户端实现仍然困难重重并缺少推动力，因此，CephFS 的使用仍需要高版本内核的帮助。
PS:
最后欢迎国内开发者加入贡献有深度的内容