#作者：闫乾苓

一、问题背景

在生产环境中，为避免因误操作导致的永久数据丢失，Ceph RBD 提供了 Trash 功能，允许将镜像“软删除”至回收站，再手动恢复或延迟清理。
Kubernetes 集群中通过 Ceph-CSI 插件动态创建 RBD PVC 时，预期在删除 PVC 后，后端 RBD 镜像应移动到 Trash 而非直接删除。为此，系统设置了如下配置：
ceph config set client.rbd rbd_move_to_trash_on_remove true
并确认所有相关 Ceph 客户端配置已生效：
ceph config dump | grep rbd_move_to_trash_on_remove
client.csi-rbd-node basic rbd_move_to_trash_on_remove true
client.csi-rbd-provisioner basic rbd_move_to_trash_on_remove true
client.rbd basic rbd_move_to_trash_on_remove true

二、实际行为

经多次测试与日志分析发现，即便 rbd_move_to_trash_on_remove=true 已生效，在执行 PVC 删除操作后：

• 对应的 RBD 镜像会短暂进入 Trash；
• 随即被立即永久删除；
• 最终在 Ceph 后端无法找到该镜像，无任何 Trash 留存记录。

该行为显著违背了 Trash 设计初衷，可能对数据安全构成严重隐患。

三、源码分析

CSI RBD 插件删除流程路径（基于 ceph-csi v3.9.x+）：
文件：internal/rbd/rbd_util.go

调用栈概览：

DeleteImage()
└── deleteImage()├── rbdImage.Trash(0)              // 行号约为 699，将镜像移动到 trash└── trashRemoveImage(...)          // 行号约为 710，立即从 trash 中删除

关键代码片段解析：

// 1. 将镜像移动到 Trash
err = rbdImage.Trash(0) // 调用 librbd C API: rbd_trash_move
if err != nil {return err
}// 2. 立即清理 Trash 中的镜像
err = trashRemoveImage(...)

即，CSI 插件显式绕过了配置项 rbd_move_to_trash_on_remove 所定义的软删除行为，而是先主动调用 rbd_trash_move()，再调用 rbd_trash_remove() 彻底删除镜像。
这种行为导致：

• 用户即使启用了 Trash 机制，也无法避免 PVC 删除后数据永久丢失；
• rbd rm 未被调用，但实现效果等同于 rbd rm。

四、分析与推论

1. 为何不直接调用 rbd rm？
   可能出于以下设计意图：
   保证镜像结构一致性（先 trash 再删逻辑清晰）；
   利于插入延迟删除（如后续引入保留时间）；
   与 Ceph API 接口保持兼容性。
2. 为何默认行为是立即删除 Trash 中镜像？
   源代码中并未根据配置 rbd_move_to_trash_on_remove 判断是否保留 Trash 中的镜像，这导致 Trash 机制在 CSI 插件中形同虚设。

五、期望行为与建议优化

1. 理想行为
   当设置 rbd_move_to_trash_on_remove=true 时：

• Ceph-CSI 删除镜像应遵循客户端配置；
• 镜像应进入 Trash 并保留，供后续手动恢复或延迟清理；
• 用户可通过 rbd trash list 查询已删除镜像。

2. 推荐优化方向

• Ceph-CSI 插件层
  在 deleteImage() 中增加配置判断逻辑，按需 skip trashRemoveImage() 调用：

if rbd_move_to_trash_on_remove_enabled {// Only move to trash, do not removereturn nil
}

• 文档更新
  明确说明当前 CSI 插件会直接删除镜像，不受 rbd_move_to_trash_on_remove 控制。
• 提供 CSI 参数控制
  增加如 retainDeletedRBDImages: true 的 StorageClass 参数，使用户可控制 Trash 保留行为。

六、结论

Ceph CSI 插件当前删除 RBD 镜像的实现方式存在与用户预期不符的问题：

• 明显忽略了 Ceph 客户端配置 rbd_move_to_trash_on_remove；
• 尽管镜像短暂进入 Trash，仍立即被永久删除；
• 可能造成误删数据无法恢复，存在严重数据安全隐患。