通过 S3 接口删除 Ceph RGW 对象后，ceph df 使用率不立即减少的原因详解
在使用 Ceph 的对象网关（RGW）通过 S3 接口删除大量对象时，删除操作会立即返回成功（因为 bucket index 中的对象条目已被移除或标记为删除），但底层实际数据（存储在 data pool 中的 RADOS 对象）并不会立即被删除 。这导致 ceph df 显示的 pool 使用率（RAW USED 或 STORED/USED）不会立刻下降。
主要原因：RGW 的垃圾回收（Garbage Collection，简称 GC）机制
-
删除过程：
- S3 DELETE 操作首先从 bucket index（通常在
.rgw.buckets.indexpool）中移除对象条目（或在启用版本控制时添加 delete marker）。 - 底层实际数据对象（head/tail 对象，可能还有 shadow 对象或 multipart 残留）变为"孤儿对象"（orphaned）。
- 这些孤儿对象被添加到 RGW 的 垃圾回收队列 （存储在
.rgw.gcpool 中）。
- S3 DELETE 操作首先从 bucket index（通常在
-
空间回收过程：
- RGW 的垃圾回收是一个异步后台进程，由 RGW daemon 定期运行。
- 它会从 GC 队列中取出条目，实际删除对应的 RADOS 数据对象，从而释放空间。
- 这个过程不是实时的，而是延迟执行，以避免删除操作对前台性能造成太大影响。
-
为什么延迟：
- 默认配置下，GC 有最小等待时间（
rgw_gc_obj_min_wait，默认 2 小时 = 7200 秒），防止误删最近可能被覆盖的对象。 - GC 处理周期（
rgw_gc_processor_period，默认 1 小时）和最大处理对象数（rgw_gc_max_objs，默认 32）等参数限制了速度。 - 大量删除时，GC 队列会积累大量条目，需要时间逐步处理。
- 默认配置下，GC 有最小等待时间（
相关配置参数（可在最新版本如 Tentacle v20.2.x 中查看/调整）
| 参数 | 默认值 | 作用 | 建议（大量删除场景） |
|---|---|---|---|
| rgw_gc_obj_min_wait | 7200 秒 | 对象删除后最小等待时间才进入 GC 可删除 | 可降低到 300-600 秒加速 |
| rgw_gc_processor_period | 3600 秒 | GC 处理线程启动间隔 | 降低到 600-1200 秒 |
| rgw_gc_processor_max_time | 3600 秒 | 单次 GC 处理最大时间 | 适当增加 |
| rgw_gc_max_objs | 32 | GC 队列中单次最大处理条目数 | 增加到 1000+（慎重，集群负载大时） |
| rgw_gc_max_concurrent_io | 10 | GC 并发 IO 数 | 增加以加速 |
如何检查和加速空间回收
- 查看 GC 队列：
radosgw-admin gc list # 查看待处理条目
radosgw-admin gc list --include-all # 包括已过期条目-
手动触发 GC 处理（推荐在低峰期操作）：
radosgw-admin gc process # 处理一批条目
radosgw-admin gc process --include-all # 强制处理所有（包括未到等待时间的）-
大量删除后，可多次运行此命令加速清理。
-
监控 RGW 配置：
ceph daemon client.rgw.<hostname> config show | grep gc- 查看 pool 实际对象（确认 shadow 对象等残留）：
rados -p <data_pool> ls | grep __shadow注意事项
- 大量删除场景：如果删除非常频繁或量大，建议提前调整上述 GC 参数，或部署专用 RGW 实例仅处理 GC（禁用客户端请求）。
- 最新版本优化：在 Tentacle (v20.2.x) 等版本中，GC 机制已更成熟，但核心仍是异步。
- ceph df 显示 ：
STORED：逻辑存储数据量。USED/RAW USED：实际原始占用（包括副本、EC 开销、未回收垃圾）。- 删除后，只有 GC 完成实际删除，RAW USED 才会下降。
一句话总结 ：S3 删除仅移除索引条目，实际数据依赖 RGW 的异步垃圾回收进程清理，因此 ceph df 使用率不会立即减少。通常等待几小时或手动触发 GC 即可看到空间释放。如果删除量极大，建议优化 GC 配置或分批操作以避免队列积压。