Ceph不提供存储池级的物理空间压缩比和读写命中率原生指标，因RADOS层不感知压缩、无本地读缓存机制；压缩比需结合客户端/服务端配置与文件系统压缩状态交叉估算，命中率在纯RADOS场景下无意义。
Ceph 本身不提供存储池级的“物理空间压缩比”和“读写命中率”原生指标。这两个值不是 RADOS 层面直接统计的，必须结合配置、对象属性与外部工具交叉推断。
为什么 ceph osd pool stats 不显示压缩比和命中率
RADOS 是对象存储层，不感知上层是否启用压缩，也不缓存读请求（OSD 无本地读缓存机制）。所谓“压缩比”取决于：① 客户端是否在写入前压缩；② 是否启用了 rbd 或 rgw 的服务端压缩；③ OSD 后端文件系统（如 XFS/ZFS）是否开启透明压缩（非 Ceph 管控）。而“命中率”在纯 RADOS 场景下无意义——所有读都直通 OSD，不存在缓存层级。
常见误判来源：ceph df 显示的 RAW USED 和 STORED 差值常被当作压缩比，但这是逻辑数据量 vs 物理占用量，混杂了副本/纠删码放大、未对齐写、元数据开销等，不能等价于压缩效果。
如何估算 RBD 池的实际压缩比（仅限启用压缩的场景）
前提：你已在 RBD 映像或池级别启用了压缩（例如通过 rbd create --image-feature compression 或 RGW 的 rgw_compression_enabled = true），且后端使用支持压缩的文件系统（如 ZFS、Btrfs）或内核 5.15+ 的 XFS + compress=zstd 挂载选项。
- 确认 OSD 使用的后端文件系统是否启用压缩：
find /var/lib/ceph/osd/ -maxdepth 1 -type d -exec lsblk -f {} \; 2>/dev/null | grep -E "(zstd|lzo|zlib)" - 查看单个 OSD 的实际磁盘用量（绕过 Ceph 抽象）：
du -sh /var/lib/ceph/osd/ceph-<code>0</code>/current/
- 对比该 OSD 上所有对象的逻辑大小总和（需遍历）：
rados -p <code>mypool</code> ls | xargs -I{} rados -p <code>mypool</code> stat {} | awk '{sum += $3} END {print sum}'（注意：此操作极重，生产慎用） - 粗略压缩比 ≈
du -sh结果 ÷rados stat总和（仅适用于单 OSD + 单池测试环境）
RGW 对象存储的压缩比和 GET 命中率怎么查
RGW 在启用 rgw_compression_enabled = true 后，会记录压缩统计到其内部 .rgw.root pool 的 compression_stats 对象中：
- 读取压缩统计：
rados -p .rgw.root get compression_stats - | jq '.'
（需安装jq） - 字段说明：
compressed_bytes是 RGW 实际写入 OSD 的压缩后字节数，uncompressed_bytes是客户端上传原始大小，二者比值即为服务端压缩比 - GET 命中率无法直接获取：RGW 默认不缓存对象内容，但若部署了前端 CDN 或 Nginx 缓存，需查对应代理日志；若启用了
rgw_cache_enabled = true（仅限元数据缓存），则radosgw-admin cache stats可看 key-level 命中，但不反映对象体命中
真正影响性能的“有效命中”其实是客户端和网络层
对于 RBD，Linux 内核的 block 层缓存（page cache）和 QEMU 的 cache=writeback 才是实际生效的读写缓冲；对于 RGW，CDN 或反向代理才是关键。Ceph 自身不做读缓存，所以任何试图从 ceph -s、ceph osd perf 或 ceph daemon osd.<code>X perf dump 中提取“命中率”的做法都会落空。
最容易被忽略的一点：PG 分布不均或 CRUSH 规则导致某些 OSD 负载过高时，osd_op_w_latency 上升会被误认为“缓存失效”，其实只是 I/O 队列堆积——先用 ceph osd df tree 和 ceph osd perf 排查热点，再谈压缩与缓存。
