]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
librbd: disallow "rbd trash mv" if image is in a group 62968/head
authorIlya Dryomov <idryomov@gmail.com>
Wed, 16 Apr 2025 11:15:19 +0000 (13:15 +0200)
committerIlya Dryomov <idryomov@gmail.com>
Fri, 25 Apr 2025 07:48:52 +0000 (09:48 +0200)
commitc31ec028c987b647b56401cd1c8d024eba49b872
tree025e6180b758855f335d5aba1bf8a6c2e1f7e262
parent2c2c446c7b2f28057aab2db7458cb821ba825584
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>
(cherry picked from commit 2ae4a57e160f21201b9dfb4c8adb02f2826c7106)

Conflicts:
PendingReleaseNotes [ moved to >=19.2.2 section ]
PendingReleaseNotes
src/librbd/api/Trash.cc
src/test/pybind/test_rbd.py
src/tools/rbd/action/Trash.cc