这是Ceph开发每周谈的第三十三篇文章，记录从16年7月17号到16年7月24号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
上周综述
Percona 开始尝试基于 Ceph 做上层感知的分布式 MySQL 集群，使用 Ceph 提供的快照，备份和 HA 功能来解决分布式数据库的底层存储问题(https://www.percona.com/blog/2016/07/13/using-ceph-mysql/)。
Datacentred(一家英国的公有云服务商)宣布使用 Ceph 作为存储后端(http://www.datacentred.co.uk/technology/ceph/)。
Ceph 在上周的 Docker 使得允许部署在 Kubernetes 上(https://github.com/ceph/ceph-docker/pull/318)。
Encode/Decode 序列化优化
上周 SanDisk Allen 抛出了针对目前广泛使用在代码中的 encode/decode 框架优化，通过显式的调用对应结构的 encode/decode 来避免额外的前缀。比如每次 encode 需要预先存储长度和键值对个数。另外，在 decode 的时候并不真正的得到一个对应的结构，而只是获得一个引用结构，比如 (key, offset, length, blob_id) 这四元组。这样使得避免大量的 copy 操作来构成一个 std::map。
CephFS 快照现状
最近 CephFS 的前任 PTL 重新梳理了目前的 CephFS 快照实现，决定重新把 CephFS 快照功能的稳定化作为目标。
目前 CephFS 的快照非常高效，因为它仅仅会创建一条快照纪录而不会做任何其他事情，比如创建一个快照 “/1/2/3/foo”，客户端仅仅发出了创建 /1/2/3/foo/.snaps 目录。但是这个也造成了你必须先删除快照，才能删除 “/1/2/3/foo”。因此，Greg 提出 .snap 是不是要另外放置。
目前的主要问题是快照在多 MDS 场景下还有实现问题。同时，CephFS 在快照后的硬链接也比较麻烦。因为文件系统快照本身并不是一个标准程度很高的协议，不同的文件系统对于快照的定义，使用都会有一些区别。
Greg 也在 ceph-devel 上提出了一些解决的思路。