The locker (entity_name_t) will be different each time the rbd
command line tool is run, so 'lock remove' is always breaking a lock.
Fixes: #2556
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
* no longer need to wait for watch timeout since #2948 was fixed
* use --format 2 instead of --new-format
* add test_cls_rbd to run-rbd-tests script
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Update the librbd locking api to make more sense:
* Add an optional tag to shared locking
* only make shared vs exclusive different functions in the user-visible api
* return a list of structs instead of a set of pairs
* fix incorrect range checking in the C api
* rename locks to lockers to be consistent with the generic locking class
* rename other_locker parameter to client, to match the list_lockers usage
Fixes: #2952
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reorder the snapdir logic and ctx->at_version adjustments prior to filling
in the object_info_t and user_versions and all that stuff. Adjust
at_version after appending the log entry (so that it points to the next
position/version we will write at.. culminating in the actual user
event).
The user log entry contains the request id, which will be used
by replay ops to put themselves in the correct place in the
waiting_for_commit/ack maps. Thus, the repop needs to be tagged
with the same version as the log entry with the request id.
Thus, the request id bearing log entry should be the last in
the log entry vector.
This should fix#3072, wherein a replay which should wait on
the repop tagged as version '36 will instead wait on '35.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
Instead of just keeping a flat usage info per bucket, we
now maintain a list of categories for which requests
usage is aggregated in. Ops are put in categories based
on their names.
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Otherwise, a pg_temp from a previous peering sequence
(but not a different peering_interval) might leak through
into Active and incorrectly trip the
Active::react(AdvMap&) asserts regarding want_acting.
Those asserts assume that want_acting is either empty or is
a results of recovery completion. In the latter case, the
want_acting set much consist only of elements of up and
acting.
Signed-off-by: Samuel Just <sam.just@inktank.com>
Deep scrub reads the contents of every file from the store and computes
a crc32 digest. The primary compares the digest of all replicas and will
mark the PG inconsistent if any don't match.
OSDs that do not support deep scrub simply perform an ordinary chunky
scrub. Any subset of OSDs that do support deep scrub will have their
digests compared.
Signed-off-by: Mike Ryan <mike.ryan@inktank.com>
Chunky scrub is a more efficient scrub. It blocks writes on a subset of
objects and scrubs those, allowing writes through to the rest of the PG.
The scrub takes longer to complete than a classic scrub, but improves
overall write throughput.
This feature is backward-compatible with classic scrub. If the primary
detects that any replica does not have the chunky scrub feature, it
falls back to the less efficient classic scrub.
Signed-off-by: Mike Ryan <mike.ryan@inktank.com>
The 'pool=default' in the default crush maps is confusing wrt rados pools.
'root' makes more sense given that we are talking about hierarchies/trees.
Signed-off-by: Sage Weil <sage@inktank.com>
