【Ceph RADOS】Recovery、Backfill 与 Scrub：修复路径、reservation 机制与 mClock QoS 边界
内容提要
本文解析Ceph中恢复、回填和深度清理三种机制的差异：恢复由日志驱动修复缺失对象，回填用于全量对象拷贝，清理则校验数据一致性。文章还讨论了mClock调度器对恢复流量的控制边界、异步恢复机制，以及恢复速度与前台延迟之间的权衡，并指出mClock无法控制块设备层的I/O带宽。
延伸解读
恢复、回填与清理：别混淆三个旋钮
文章强调，recovery、backfill 和 scrub 是三种不同的机制，触发条件、数据来源和并发限制各异。混淆它们会导致调错参数，例如把 backfill 当 recovery 去调 osd_recovery_max_active，或指望 scrub 自动修复数据。理解差异是正确配置限速和调度策略的前提。
mClock 的边界：它管不到块设备层
mClock 调度器只控制 OSD op queue 内的调度，不控制 BlockDevice 层的 aio 带宽。因此，即使设置了 recovery 的 mClock 份额，磁盘 I/O 仍可能被 recovery 占满。文章指出，RocksDB compaction、deferred_finisher 的裸盘 aio 等都不受 mClock 控制，需要与 osd_max_backfills 等参数正交调优。
恢复速度与前台延迟的权衡
文章呈现了两种对立观点：快速恢复派强调缩短 double fault 窗口，保护前台派则优先保证客户端延迟稳定。官方建议在维护窗口切换 mClock profile，而非在生产高峰期修改限速参数。这反映了工程判断，而非单一基准测试结论。
异步恢复与可观测性缺口
异步恢复（async recovery）旨在减少对 missing 对象的同步阻塞写，但代价是双重故障窗口更复杂。文章指出，目前缺乏全集群 recovery 进度百分比视图，运维需手动聚合 ceph pg dump 数据，这影响对 double fault 风险窗口的实时估计。
Q&A
Ceph中recovery、backfill和scrub有什么区别？
Recovery是日志驱动的修复，只修复缺失或分歧的对象；Backfill是全量对象拷贝，用于日志无法覆盖差异的情况；Scrub是主动校验数据一致性，分浅清理和深度清理。
Ceph中recovery的触发条件和执行流程是什么？
Recovery在PG peering后，根据PG log中的pg_missing_t记录，Primary向对端OSD发起push/pull操作，修复缺失对象，完成后PG转为active+clean。
Ceph中backfill在什么情况下触发？
Backfill在PG log无法覆盖分歧时触发，例如新OSD加入、OSD长时间宕机导致日志截断、调整副本数等。
Ceph中deep scrub的作用是什么？
Deep scrub读取对象数据，触发BlueStore的checksum验证，并在副本间比对数据hash，用于发现静默数据损坏。
Ceph中mClock调度器能控制哪些I/O？
mClock控制进入OSD op queue的带标签操作的调度，包括recovery、backfill、scrub等，但不控制RocksDB compaction、deferred_finisher的裸盘aio以及已在途的BlockDevice aio。
Ceph中如何调整恢复速度以平衡前台延迟？
可以通过调整osd_recovery_max_active、osd_max_backfills等参数，或使用mClock profile（如high_recovery_ops）在维护窗口加快恢复，但需注意对前台延迟的影响。
Ceph中async recovery是什么？
Async recovery是异步恢复机制，将log-based recovery的修复操作放到与live acting set带外的路径，减少对missing对象的同步阻塞写，从而降低慢请求。
Ceph中reservation机制的作用是什么？
Reservation机制是分布式槽位协议，用于限制recovery和backfill的并发，防止环形等待，通过local和remote槽位申请实现。
