]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
librbd: disallow "rbd trash mv" if image is in a group 62921/head
authorIlya Dryomov <idryomov@gmail.com>
Wed, 16 Apr 2025 11:15:19 +0000 (13:15 +0200)
committerIlya Dryomov <idryomov@gmail.com>
Tue, 22 Apr 2025 18:36:53 +0000 (20:36 +0200)
commit2ae4a57e160f21201b9dfb4c8adb02f2826c7106
tree8d3bc91c529ac213c7e1b23230862627e36bbf62
parent61075e344c18e57b7416072f66c2e335d4d89d75
librbd: disallow "rbd trash mv" if image is in a group

Removing an image that is a member of a group has always been
disallowed.  However, moving an image that is a member of a group to
trash is currently allowed and this is deceptive -- the only reason for
a user to move an image to trash should be the intent to remove it.

More importantly, group APIs operate in terms of image names -- there
are no corresponding variants that would operate in terms of image IDs.
For example, even though internally GroupImageSpec struct stores an
image ID, the public rbd_group_image_info_t struct insists on an image
name.  When rbd_group_image_list() encounters a trashed member image
(i.e. one that doesn't have a name), it just fails with ENOENT and no
listing gets produced at all until the offending image is restored from
trash.  Something like this can be very hard to debug for an average
user, so let's make rbd_trash_move() fail with EMLINK the same way as
rbd_remove() does in this scenario.

The one case where moving a member image to trash makes sense is live
migration where the source image gets trashed to be almost immediately
replaced by the destination image as part of preparing migration.

Fixes: https://tracker.ceph.com/issues/71026
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
PendingReleaseNotes
src/librbd/api/Trash.cc
src/test/pybind/test_rbd.py
src/tools/rbd/action/Trash.cc