这是Ceph开发每周谈的第二十九篇文章，记录从16年6月20号到16年6月26号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
上周由于 master 分支 qa 失败，大部分合并进程暂停转而修复主线。
-
RBD Cache Inconsistence
RBD Cache 是 Ceph RBD 在客户端侧实现的客户端缓存，这个 Bug 实际上已经存在非常久远，非常有趣的是，最近在我们内部的产品一次一致性压力测试中，因为对接其他云平台测试不小心打开了 rbd cache，在压测时发现严重的不一致现象。经过一段时间排查，才发现原来打开了 rbd cache 导致。这才意识到 rbd cache 实际上存在比较严重的一致性问题。而之前，因为 rbd cache 的丑陋和低效，我们是一直是关闭 rbd cache。
在跟社区沟通以后，了解到社区也是近期在 CephFS 侧发现这个问题，因此这个问题同时影响了 RBD Cache 和 CephFS 打开 Cache 的场景，简单来说，这个问题是由于在大块读时，ObjectCacher 模块读后端计算的 offset/length 错误导致的。在大块场景较容易复现。
这个问题也暴露 Ceph 社区在关键测试上的压力和覆盖度不足，这也是 Ceph 商业公司需要做的。这个 Bug 意味着所有 Ceph 云平台需要迅速关闭所有 VM 的 RBD Cache。
-
切换到 CMake
社区最近在推动 CMake 在 Ceph 的计划，实际上这个进程已经持续了大半年，CMake 更加高效和清晰，过去的 autotools 实际上已经让整个项目的构建充满 Tricky。Sage 在近日也正式宣布了 Ceph 项目开始切换为 CMake 方式。
简单介绍下 CMake，CMake是个开源的跨平台自动化建构系统，它用配置文件控制建构过程（build process）的方式和 Unix 的 Make 相似，只是 CMake 的配置文件取名为CMakeLists.txt。Cmake并不直接建构出最终的软件，而是产生标准的中间文件（如Unix的Makefile），然后再依一般的建构方式使用。这使得熟悉某个集成开发环境（IDE）的开发者可以用标准的方式建构他的软件，这种可以使用各平台的原生建构系统的能力是CMake和SCons等其他类似系统的区别之处。CMake可以编译源代码、制做目标程序、还可以用任意的顺序建构可执行文件。CMake支持in-place建构（二进档和源代码在同一个目录树中）和out-of-place建构（二进档在别的目录里），因此可以很容易从同一个源代码目录树中建构出多个二进档。CMake也支持静态与动态程序库的建构。“CMake”这个名字是”cross platform make”的缩写。虽然名字中含有”make”，但是CMake和Unix上常见的“make”系统是分开的。
最后欢迎国内开发者加入贡献有深度的内容