Users can easily forget this. It makes shutdown potentially block, but if
they have racing callbacks they get what they ask for.
Signed-off-by: Sage Weil <sage@redhat.com>
Add a call so that callers can make sure all queued callbacks have
completed before shutting down the ioctx. This avoids a segv triggered
by the LibRadosWatchNotifyPPTests/LibRadosWatchNotifyPP.WatchNotify2Timeout/1
test due to the ioctx being destroyed when the in-progress callback
does a notify_ack.
Signed-off-by: Sage Weil <sage@redhat.com>
Wait for any digest updates to apply before we scrub the next chunk. This
bounds the number of repops we initiate by the size of the scrub chunk, and
it generally nicer to the cluster.
Signed-off-by: Sage Weil <sage@redhat.com>
Pass the omap data in the struct as an opaque (encoded) bufferlist. This
avoids a decode into an STL map, simplifying the crc calculation. The
win isn't huge (yet) because we still turn it into a map to pass it down
to the ObjectStore method, but that too will change in time.
Signed-off-by: Sage Weil <sage@redhat.com>
Unfortunately it's nontrivial to inject this from the usual
ceph_test_rados_api_* tests which need to run despite thrashing.
Signed-off-by: Sage Weil <sage@redhat.com>
Two things here:
1- Pass the original digest from the source across the wire, if it is
present.
2- Calculate a new digest as we receive it, and record that.
If there is a mismatch, we currently crash; need to turn this into an
EIO, most likely.
Signed-off-by: Sage Weil <sage@redhat.com>
Add a tunable to control this. Returning an EIO instead of garbled data
may not be the best approach in all environments.
Eventually we want to do something better here, like read from a replica
instead.
Signed-off-by: Sage Weil <sage@redhat.com>
If an object is being actively updated, the whole-object digest will
quickly be invalidated. On deep scrub, only record that digest if the
object is a few hours old. Otherwise, we are wasting an IO.
Signed-off-by: Sage Weil <sage@redhat.com>
If we do not have a whole-object digest, record one after a deep scrub.
Note that we make no particular attempt to avoid this on frequently
changing objects where the digest will quickly be invalidated.
Signed-off-by: Sage Weil <sage@redhat.com>
This will only trigger if we choose an auth that is known bad, but that
currently can happen, so compalin here too.
Signed-off-by: Sage Weil <sage@redhat.com>
The digest may just disagree with our best guess 'auth' shard, or it may
also disagree with the recorded oi digest. Clarify which.
Signed-off-by: Sage Weil <sage@redhat.com>
The auth may or may not know that the digest is truly bad. Note that we
can only relate scrub digests to those in oi if the scrub used a seed of
-1; older OSDs use 0.
Signed-off-by: Sage Weil <sage@redhat.com>
0 is a weak initial value for a CRC since it doesn't change with a sequence
of 0 bytes (which are relatively common). -1 is better. Use -1 when
everyone in the acting set supports it.
Signed-off-by: Sage Weil <sage@redhat.com>
When we create an empty object, we have a known digest of -1. In a few
cases, we also know the digest from the op (e.g., writefull). The rest
of the time we invalidate any existing digest.
Signed-off-by: Sage Weil <sage@redhat.com>
Lack of a single space was restricting the proper rendering of an option in
html. Fixes the error.
Signed-off-by: Nilamdyuti Goswami <ngoswami@redhat.com>
The notify completion has exactly one user, the librados caller which
does nothing but take a local (inner) lock and signal a Cond. Do this
in the fast-dispatch context for simplicity.
Notably, this makes the notify completion (and timeout) trigger a
notify2() return (with ETIMEDOUT) even when the finisher queue that
normally delivers notify is busy.. for example with a notify that is
being very slow. In our case, the unit test is doing a sleep(3) to
test timeouts but also prevented the ETIMEDOUT notification from
being delivered to the caller. This patch resolves that.
Signed-off-by: Sage Weil <sage@redhat.com>
