There's no need to explicitly close the ioctx. Doing so may cause
problems when the Images using it are destroyed afterwards. Just let
normal cleanup at the end of the block take care of it in the correct
order.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
This simplifies locking by obviating the NULL checks. We no longer
need md_lock to protect these acceses. We can use object_map_lock
instead, to make sure no one reads an object map while its being
updated.
Keep track of whether the object map is enabled for a given snapshot
internally. In each public method, check this state, and automatically
set it correctly when refreshing the object map. During snapshot
removal, unconditionally try to remove the object map object, to
protect against bugs leaking objects, and to be consistent with image
removal.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
add_snap() updates the ImageCtx snapshot metadata in memory, as well
as reading the flags as part of the object map snapshot. Both of these
require holding snap_lock.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
This is another step towards eliminating md_lock from the writeback
path. Almost all the places that use ImageCtx->flags already use
snap_lock, so there's no need to create a new lock. For the others,
add a helper, test_flags() that acquires the lock, similar to
test_features().
This also makes sure we look up flags of the snapshot we're operating
on, instead of those for head.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
A bunch of these used to be here, but were removed when converting to
RWLocks, before RWLocks had is_[w]locked() methods.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
This gets the appropriate locks, and checks the currently open
snapshot instead of head. Looking up features by snap_id prepares us
for future addition or removal of e.g. an object map throughout the
life of an image.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
This was being protected by md_lock, but that has become too coarse
since it is used to prevent writes from proceeding while flushing
caches for a snapshot. With the addition of ObjectMap and
ImageWatcher, writeback could try to acquire md_lock again, leading to
a deadlock.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
Since the post-snap create header update runs asynchrously
in a finalizer callback, it's possible that the snapshot
is not immediately visible. Also, if a proxied snap create
message is replayed, it's possible for the client to receive
a EEXISTS error.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Added a unique client id to announcement messages so that duplicate
lock release / acquired / requested messages can be detected and
ignored by the client. Also fixed an issue processing the result
code for async operations.
Fixes: #10898
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Moved all RPC messages to their own classes to facilitate cleaner
version control and backward compatibility.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Utilize the existing rbd_default_features config option to
control whether or not to enable RBD exclusive locking and
object map features by default. Also added a new option to
the rbd cli to specify the image features when creating images.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
osd: number of degraded objects in EC pool is wrong when there is OSD down(in).
Reviewed-by: Samuel Just <sjust@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
If setting CEPH_BUILD_ROOT, will use that path, otherwise runs
everything from current directory as before.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
The bit vector was not invalidating the bufferlist's CRC, resulting
in peer OSDs rejecting write op due to a mismatched CRC on the
message.
Fixes: #10919
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Correct and restore assert that was removed
Cause by f46b1b473fFixes: #10883
Backport: dumpling, firefly, giant
Signed-off-by: David Zafman <dzafman@redhat.com>
librbd was previously attempting to cast the provided Context to
retrieve the fadvise flags. To eliminate the unsafe cast, now
the fadvise flags are directly passed to the WritebackHandler::read
callback.
Fixes: #10914
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
It is useful to know how big the pg_temp map is. Strictly speaking
this is part of the OSDMap so I'm including it here. It looks like
this:
osdmap e25: 3 osds: 3 up, 3 in; 1 remapped pgs
It might be more user-friendly to put it in a line with the pgmap
somewhere (where other pg counts are included), but it doesn't quite
fit there either. So sticking with where it lives in the data
structure!
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit db06582a06)
Previously, there was a harmless bug where we didn't fill in the
last_epoch_started field for a peer which we are resetting the
last_backfill line for. It's no longer harmless since we use that
as the activation epoch, so if the peer is missing the MIN_SIZE
feature bit, we fill in the last_epoch_started it meant to fill in.
Signed-off-by: Samuel Just <sjust@redhat.com>
It was possible for ImageWatcher to attempt to re-acquire held locks
via context callbacks. This issue affected resizing/flattening when
no work was required and rescheduling a watch upon two successive
failures.
Fixes: #10899
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
