【Ceph RADOS】BlueStore 读路径：onode、blob、缓存与 checksum 失败模式
内容提要
本文深入解析Ceph BlueStore的读路径，涵盖onode缓存查找、extent_map展开、blob解引用及BlockDevice读取，并详述解压与checksum验证流程。重点探讨2Q缓存算法如何抵抗扫描污染，以及checksum失败时的分层处理与检测边界。同时讨论压缩数据读取的性能瓶颈和缓存设计中的争议点。
延伸解读
读路径排障：先分清元数据面还是数据面
文章强调，读路径性能问题需先区分是元数据面（onode缓存未命中、RocksDB读取）还是数据面（数据缓存未命中、aio_read）瓶颈。若混淆，可能调错参数，如误调bluestore_cache_meta_ratio或rocksdb配置。建议通过perf dump观察缓存命中率，并结合compaction和scrub窗口分析P99延迟，避免笼统归因于“OSD慢”。
2Q缓存：对抗扫描污染的设计逻辑
BlueStore数据缓存采用2Q算法而非LRU，核心目的是防止deep scrub、backfill等顺序扫描流量污染热点数据。2Q通过冷区（A1in）和幽灵标识（A1out）区分首次访问与复访，使扫描流量主要影响冷区。文章指出，这是机制对齐，但未提供替换算法的A/B测试数据，读者不应假设具体命中率提升。
checksum失败：分层处理与检测边界
checksum失败后，BlueStore返回EIO，副本池尝试从其他OSD读取，EC池则重建。但文章强调，checksum失败不等于自动修复，deep scrub发现不一致后常需显式ceph pg repair。检测边界方面，未被读取且未到deep scrub周期的对象可能长期无感，默认周期约7天，冷数据损坏发现窗口与此同量级。
压缩数据缓存：解压后存储的取舍
BlueStore默认缓存解压后的数据，避免重复解压，但会按逻辑大小占用内存，高压缩比对象可能使缓存覆盖不足。文章指出，内存紧缺的高密度OSD可考虑缓存压缩字节，但Squid默认行为以源码为准。调优前需确认实际缓存内容，避免按物理占用估算覆盖率。
Q&A
Ceph BlueStore 读路径中，onode 缓存未命中时会发生什么？
当 onode 缓存未命中时，BlueStore 会从 RocksDB 读取 onode 元数据，具体路径为：先查 MemTable，再查 RocksDB block cache，最后从 BlueFS 上的 SST 文件读取。读取后反序列化 bluestore_onode_t 并插入缓存。
BlueStore 数据缓存为什么使用 2Q 算法而不是 LRU？
因为 2Q 算法能有效抵抗扫描污染（scan pollution）。在 Ceph OSD 中，deep scrub、backfill、recovery 等操作会顺序读取大量对象，如果使用纯 LRU，这些冷数据会挤掉前台热对象的缓存，导致命中率下降。2Q 算法将首次访问的页放入冷区（A1in），只有再次访问的页才升入热区（Am），从而保护热点数据。
BlueStore 读取压缩数据时，checksum 验证和解压的顺序是怎样的？
BlueStore 读取压缩数据时，先对从裸盘读出的压缩字节进行 checksum 验证，验证通过后再解压。解压后的数据存入数据缓存，这样第二次读取同一 blob 时无需重复解压。
BlueStore 中 checksum 验证失败后，系统会如何处理？
checksum 验证失败后，BlueStore 会向上返回 EIO 并记录错误日志。对于副本池，PrimaryLogPG 会尝试从其他 acting OSD 读取数据，成功则服务读请求并触发修复；对于 EC 池，ECBackend 会用其余分片重建数据并写回坏分片。如果冗余不足，客户端读操作会失败并返回 EIO。
BlueStore 读路径中，哪些因素会导致读性能下降？
读性能下降的主要因素包括：onode 缓存未命中导致 RocksDB 读取延迟；数据缓存未命中导致 aio_read 延迟；RocksDB compaction 干扰，与 onode/omap 读争抢 BlueFS 带宽；extent 碎片化导致一次逻辑读拆成多次随机 aio。
BlueStore 与 FileStore 在缓存机制上有什么主要区别？
FileStore 依赖内核页缓存，而 BlueStore 绕过 VFS，使用自管理的 onode cache 和 2Q 数据缓存。BlueStore 的缓存策略可以预期地应对 scrub/recovery 扫描，不与主机其他进程争抢 page cache，且 DIRECT I/O 语义清晰。但内核页缓存的 readahead 对顺序读更省心，BlueStore 需要自研预读机制。
BlueStore 中静默数据损坏的检测边界是什么？
静默数据损坏的检测依赖读操作或 deep scrub。如果对象从未被读取且未轮到 deep scrub，即使盘上发生比特翻转，客户端和集群健康状态也可能暂时无感。默认 osd_deep_scrub_interval 约为 7 天，因此冷数据的发现窗口上界与此同量级。
