这篇是Ceph开发每周谈的第三篇，记录从2015年12月21号到12月27号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
本周综述
这个星期到元旦这段时间是欧美的假期，所以社区也快进入冬眠了。
Scrub 改进
Scrub 可以理解为是后台数据一致性校验的过程，分为浅校验和深校验。前者只会比对元数据部分，而后者会对整个数据块进行 checksum 计算然后比对。目前 Scrub 的最主要问题是对用户的过程太少，现在 Ceph 中的 Scrub 实现还比较原始，提供的接口不够，用户对整个过程一无所知，无法做一些定制化的策略，另一方面，Scrub 跟恢复过程都会侵占珍贵的磁盘带宽，因此精细化调度 Scrub 过程也是目标之一。Scrub 这个改进最先由 Rados PTL Samuel 在 Infernalis 的CDS上提出。但由于来不及做，故没有在 Infernalis 的发布中推出。
在 Jewel 的CDS上，Sam 再次提出这个BP，不过这次的实现则由 Kefu 来负责。在最近的一个实现旨在实现 Scrub API 化，包含了将 Scrub 结果以 omap 的形式持久化，和提供了两个 API 接口供用户来查询最近一次 Scrub 的结果。一个 API 是查询某个 Pool 中所有不一致的 PG，另一个 API 是查询某个 PG 中的所有不一致的 Object。查询一个 Pool 中不一致的 PG 可以用现有的 pg ls 命令来简单实现。查询 PG 中不一致的 objects 则需要利用到持久化的 Scrub 结果。其通过新增加一个 RADOS OP 来从持久化的 omap 中得到该信息。
恢复优化
Ceph 在恢复过程中导致的客户端 IO 挤占几乎被所有的 Ceph 用户所痛恨，如何减少和避免恢复的影响也是邮件列表中最常见的问题之一。这个问题实际上并不是有一个单一的原因，它涉及恢复的类型如处于 Recovery 和 Backfill，优化的方式也比较多，从业务的峰谷时间段调度，或者更佳智能的调度 Recovery IO，甚至减少潜在的恢复带宽。而不同的用户部署形态也会有各异的问题根源和解决方式。最典型的在千兆网络下，网络带宽是恢复的主要瓶颈，而恢复流的压缩传输会极大的帮助这个场景。
当然今天讨论的是在邮件列表里 Wudong 提到的，通过给 PGLog (可以理解为数据库领域的 Redo Log) 增加 offset/len 解决恢复增量数据的问题，其实在今年 4 月份就在 ML 上聊过这个问题，当时也是密集讨论恢复优化的时候。当时提交的一个 PR 初步实现了这个逻辑，但是恢复流程本身是一个牵一发而动全身的事情，而恢复的效率提升也很难去简单衡量，因为不同的场景需要考虑的恢复侧重点会不一样。因此当时考虑到在 PGLog 增加额外参数导致的异常情况太多而没有太大进展。不过这次的讨论 Sage 主动提到可以做退步，当能确认 offset/len 可靠的情况下做增量恢复即可，其它状态可以回退到全量恢复。即使这样，这个问题仍然没有很简单，涉及到不同的复制 Backend 的处理，Truncate 和 Delete 处理，还有涉及的额外部分数据传输与之前全量恢复违背的很多逻辑，也牵涉到底层 ObjectStore 的一些回退机制。总的来说，这个需要在 CDS 大家再次讨论一下整体设计，不过社区的特点是只要获得大家的一致重视，这个工作的进度推展就会比较快。