ceph osd purge仅清除已标记为out且无PG的OSD元数据，不处理无主对象；真正清理需通过scrub/deep-scrub/repair或手动定位删除，物理擦除设备无效。
ceph osd purge 无法直接清理无主对象
直接执行 ceph osd purge 不会清除“失效无引用的残余无主数据块”。这个命令只用于移除已标记为 out 且完全空闲（无 PG、无数据）的 OSD 元数据记录，它不触碰任何对象级数据。所谓“无主数据块”，本质是未被任何 PG 日志（pg->log_oid）、biginfo_oid 或归置组映射所引用的底层 RADOS 对象，它们游离在 PG 生命周期之外，常规 PG 删除流程不会覆盖到。
真正有效的清理路径只有两种：scrub + deep-scrub + repair，或手动对象扫描
无主对象通常出现在以下场景：PG 被异常中断删除、OSD 强制下线后残留、或早期版本 bug 导致日志与实际对象不一致。Ceph 官方不提供“批量扫描并删光所有孤立对象”的工具，因为这极易误伤——你无法 100% 确认某个对象是否真无引用（比如某 PG 正在 peering 中途失败，其对象可能暂时未被 log 记录）。
-
ceph pg deep-scrub <pgid>是首选：它会读取每个对象的元数据（xattr），比普通 scrub 多校验对象内容哈希，并对比所有副本的一致性；若发现某对象在 primary 上存在、但在所有 replica 上都缺失，且该 PG 已处于active+clean，则说明该对象大概率是“幽灵残留”，此时可配合ceph pg repair <pgid>触发自动修复逻辑——repair 会尝试从健康副本重建缺失对象，若所有副本都缺失，则可能触发对象删除（取决于osd_debug_deep_scrub_randomize和osd_debug_deep_scrub_randomize_ratio配置，但非默认行为） - 更稳妥的做法是先用
rados -p <pool> listomapkeys <objname>或ceph-objectstore-tool --data-path ... --journal-path ... --type bluestore list-objects手动定位可疑对象，再结合ceph pg map <objname>验证其归属 PG 是否还存在；仅当确认 PG 已销毁、且该对象不在任何现存 PG 的 log 或 collection 中时，才用rados -p <pool> rm <objname>删除
为什么不能用 sgdisk/dd 清理 OSD 设备来解决这个问题
这是常见误解。对 OSD 后端设备（如 /dev/nvme0n1）执行 sgdisk --zap-all 或 dd if=/dev/zero of=... bs=1M count=100，只会擦除设备头部元数据（LVM PV label、BlueStore superblock、OSD ID 映射等），但无法识别和删除“无主对象”——因为 BlueStore 将对象以 extent 形式散列写入裸设备，没有中心索引表。这些命令相当于把整本电话簿撕掉封面，但里面成千上万个名字依然印在纸页上，只是你再也查不到它们了。
- 这类操作只适用于彻底退役 OSD 并重用磁盘的场景，不是“清理无主对象”的手段
- 若 OSD 仍在集群中运行，强行 dd 会导致 OSD 崩溃、PG 卡死、甚至引发
inconsistent状态 - 真正需要的是逻辑层清理，而非物理层覆盖
rook-ceph cleanupPolicy 不处理无主对象
cleanupPolicy 的作用范围明确限定在 CRD 删除后的宿主机侧：清空 dataDirHostPath（如 /var/lib/rook）、擦除 OSD 设备上的 BlueStore superblock 和 LVM 结构。它不会连接到运行中的 Ceph 集群去扫描或删除任何 RADOS 对象，无论是否有主。换句话说，它解决的是“集群卸载后磁盘能否复用”，而不是“集群运行中如何回收空间”。
如果你看到磁盘使用率居高不下，但 ceph df 显示 pool usage 正常，那大概率是 BlueStore 内部的 freelist 碎片或 stale omap 条目所致，此时应优先调大 bluestore_cache_size 并触发 ceph-bluestore-tool repair，而不是幻想靠外部策略一键清空。
