Hello, Ceph users,
How can I figure out why it is not possible to unprotect a snapshot
in a RBD image? I use this RBD pool for OpenNebula, and somehow there
is a snapshot in one image, which OpenNebula does not see. So I wanted
to delete the snapshot:
# rbd info one/one-1312
rbd image 'one-1312':
size 8 GiB in 2048 objects
order 22 (4 MiB objects)
snapshot_count: 1
id: 6732dccd50fa75
block_name_prefix: rbd_data.6732dccd50fa75
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
op_features:
flags:
create_timestamp: Wed Jun 30 10:41:59 2021
access_timestamp: Wed Jun 30 16:48:30 2021
modify_timestamp: Wed Jun 30 15:52:18 2021
# rbd snap ls one/one-1312
SNAPID NAME SIZE PROTECTED TIMESTAMP
1727 snap 8 GiB yes Wed Jun 30 16:11:39 2021
# rbd snap rm one/one-1312@snap
Removing snap: 0% complete...failed.
rbd: snapshot 'snap' is protected from removal.
2021-07-01 08:33:41.489 7f79c6ffd700 -1 librbd::Operations: snapshot is protected
# rbd snap unprotect one/one-1312@snap
2021-07-01 08:28:40.747 7f3cb6ffd700 -1 librbd::SnapshotUnprotectRequest: cannot
unprotect: at least 1 child(ren) [68ba8e7bace188] in pool 'one'
2021-07-01 08:28:40.749 7f3cb6ffd700 -1 librbd::SnapshotUnprotectRequest: encountered
error: (16) Device or resource busy
2021-07-01 08:28:40.749 7f3cb6ffd700 -1 librbd::SnapshotUnprotectRequest: 0x56522f10e830
should_complete_error: ret_val=-16
rbd: unprotecting snap failed: 2021-07-01 08:28:40.751 7f3cb6ffd700 -1
librbd::SnapshotUnprotectRequest: 0x56522f10e830 should_complete_error: ret_val=-16
As far as I can see neither the snapshot nor the RBD image itself is
used by a running qemu in my cluster. How can I delete the snapshot
or debug the problem further?
This is Ceph 14.2.21 on CentOS (mons are CentOS 8 now, and OSDs are CentOS 7).
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work |
yenya.net - private}>
|
|
http://www.fi.muni.cz/~kas/ GPG: 4096R/A45477D5 |
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. --Larry Wall