通过 S3 接口删除 Ceph RGW 对象后，ceph df 使用率不立即减少的原因详解

在使用 Ceph 的对象网关（RGW）通过 S3 接口删除大量对象时，删除操作会立即返回成功（因为 bucket index 中的对象条目已被移除或标记为删除），但底层实际数据（存储在 data pool 中的 RADOS 对象）并不会立即被删除。这导致 ceph df 显示的 pool 使用率（RAW USED 或 STORED/USED）不会立刻下降。

主要原因：RGW 的垃圾回收（Garbage Collection，简称 GC）机制

• 删除过程：

  1. S3 DELETE 操作首先从 bucket index（通常在 .rgw.buckets.index pool）中移除对象条目（或在启用版本控制时添加 delete marker）。
  2. 底层实际数据对象（head/tail 对象，可能还有 shadow 对象或 multipart 残留）变为“孤儿对象”（orphaned）。
  3. 这些孤儿对象被添加到 RGW 的 垃圾回收队列（存储在 .rgw.gc pool 中）。

• 空间回收过程：

  • 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 队列会积累大量条目，需要时间逐步处理。

相关配置参数（可在最新版本如 Tentacle v20.2.x 中查看/调整）

如何检查和加速空间回收

1. 查看 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 对象等残留）：

1. 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 配置或分批操作以避免队列积压。