Sage Weil [Tue, 18 Sep 2012 21:48:14 +0000 (14:48 -0700)]
mon: make MRoute encoding backwards-compatible
If the target as the NULLROUTE feature, use a new encoding that explicitly
indicates whether a message follows. If the feature is absent, use the
old encoding. The mon is responsible for not trying to send a null reply
if the target does not have the feature.
Alex Elder [Wed, 19 Sep 2012 03:51:10 +0000 (22:51 -0500)]
rbd/copy.sh: fix typo
Or maybe it was a spello, or a thinko, or something. In any case
I'm pretty sure Josh intended to call the function he added in
commit 78d6a60ca, and not the non-existent "test_import_args".
librbd: use generic cls_lock instead of cls_rbd's locking
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
rbd: make --pool/--image args easier to understand for import
There's no need to set the default pool in set_pool_image_name - this
is done later, in a way that doesn't ignore --pool if --dest-pool
is not specified.
This means --pool and --image can be used with import, just like
the rest of the commands. Without this change, --dest and --dest-pool
had to be used, and --pool would be silently ignored for rbd import.
librbd, cls_rbd: close snapshot creation race with old format
If two clients created a snapshot at the same time, the one with the
higher snapshot id might be created first, so the lower snapshot id
would be added to the snapshot context and the snaphot seq would be
set to the lower one.
Instead of allowing this to happen, return -ESTALE if the snapshot id
is lower than the currently stored snapshot sequence number. On the
client side, get a new id and retry if this error is encountered.
Backport: argonaut Signed-off-by: Josh Durgin <josh.durgin@inktank.com> Reviewed-by: Sage Weil <sage@inktank.com>
Josh Durgin [Thu, 30 Aug 2012 00:30:17 +0000 (17:30 -0700)]
doc: clarify rbd man page (esp. layering)
* a clone's size can't be overridden
* note which commands require format 2
* clarify details of copy
* add examples for cloning
* add pool to map example for consistency
* fix a couple warnings and re-sync man page with rst
Josh Durgin [Wed, 29 Aug 2012 00:24:47 +0000 (17:24 -0700)]
librbd: prevent racing clone and snap unprotect
If the following sequence of events occured,
a clone could be created of an unprotected snapshot:
1. A: begin clone - check that snap foo is protected
2. B: rbd unprotect snap foo
3. B: check that all pools have no clones of foo
4. B: unprotect snap foo
5. A: finish creating clone of foo, add it as a child
To stop this from happening, check at the beginning and end of
cloning that the parent snapshot is protected. If it is not,
or checking protection status fails (possibly because the parent
snapshot was removed), remove the clone and return an error.
Sage Weil [Tue, 4 Sep 2012 23:55:08 +0000 (16:55 -0700)]
mon: decay laggy calculations over time
Add a configurable halflife for the laggy probability and duration and
apply it at the time those values are used to adjust the heartbeat grace
period. Both are multiplied together, so it doesn't matter which you
think is being decayed (the probability or the interval).
Sage Weil [Tue, 4 Sep 2012 20:39:23 +0000 (13:39 -0700)]
mon: scale heartbeat grace based on laggy probability, interval
If, based on historical behavior, an observed osd failure is likely to be
due to unresponsiveness and not the daemon stopping, scale the heartbeat
grace period accordingly:
This will avoid fruitlessly marking OSDs down and generating additional
map update overhead when the cluster is overloaded and potentially
struggling to keep up with map updates. See #3045.
Sage Weil [Tue, 4 Sep 2012 20:20:32 +0000 (13:20 -0700)]
mon: check failures in tick
Currently we only trigger a failure on receipt of a failure report. Move
the checks into a helper and check during tick() too, so that we will
trigger failures even when the thresholds are not met at failure report
time. This is rarely true now, but will be true once we locally scale the
grace period.
Sage Weil [Tue, 4 Sep 2012 18:50:30 +0000 (11:50 -0700)]
mon: locally apply osd heartbeat grace to failure checks
Aggregate the failure reports into a single mon 'failed_since' value (the
max, currently), and wait until we have exceeded the grace period to
consider the osd failed.
WARNING: This slightly changes the semantics. Previously, the grace could
be adjusted in the [osd] section. Now, the [osd] option controls when the
failure messages are sent, and the [mon] option controls when it is marked
down, and sane users should set it once in [global].
Sage Weil [Sat, 1 Sep 2012 01:23:20 +0000 (18:23 -0700)]
mon: send 'null' reply to requests we won't reply to
This is a no-op if the client was talking to us, but in the forwarded
request case will clean up the request state (and request message) on the
forwarding monitor. Otherwise, MOSDFailure messages (and probably others)
can accumulate on the non-leader mon indefinitely.
Sage Weil [Tue, 18 Sep 2012 21:38:47 +0000 (14:38 -0700)]
mon: refactor osd failure report tracking
- use structs to track allegedly failed nodes, and reports against them.
- use methods to handle report, and failure threshold logic.
- calculate failed_since based on OSD's reported failed_for duration
This will make it simpler to extend the logic when we add dynamic
grace periods.
Sage Weil [Tue, 28 Aug 2012 03:02:12 +0000 (20:02 -0700)]
mon: adjust or decay laggy probabilities on osd boot
On each osd boot, determine whether the osd was laggy (wrongly marked down)
or newly booted. Either update the laggy probability and interval or
decay the values, as appropriate.
Sage Weil [Tue, 28 Aug 2012 02:57:48 +0000 (19:57 -0700)]
osdmap: include osd_xinfo_t to track laggy probabilities, timestamps
Track information about laggy probabilities for each OSD. That is, the
probability that if it is marked down it is because it is laggy, and
the expected interval over which it will take to recovery if it is laggy.
We store this in the OSDMap because it is not convenient to keep it
elsewhere in the monitor. Yet. When the new mon infrastructure is in
place, there is a bunch of stuff that can be moved out of the OSDMap
'extended' section into other mon data structures.
The command will dump the existing bucket header stats,
and the calculated bucket header stats. If --fix is provided
the bucket stats will be overwritten by the recalculated
stats.
rgw: obj_stat() returns object version (epoch), use it
We now pass the object version returned by obj_stat. We use that
epoch for setting the object version through the index suggestion
mechanism. This was broken by a recent change that switched from
reading the obj stats by (wrongly) calling directly to ioctx->stat()
to calling get_obj_state().
cls_rgw: complete_op() only skip update if epoch is non zero
An update shouldn't be skipped if epoch is zero. We'd see a zero
epoch if we tried to read an object and it didn't exist. That
could happen e.g., when a delete object operation failed to
call the complete earlier, and now we're recalling delete on
the (now non-existent object).
However, note that the zero epoch is racy. We may end up racing
with an object creation. This will be taken care of by a new
rados change that will set the returned object version even if
it didn't exist.
Fixes: #3127
Bad variable scoping made it so that specific variables
weren't initialized between suggested changes iterations.
This specifically affected a case where in a specific
change we had an updated followed by a remove, and the
remove was on a non-existent key (e.g., was already
removed earlier). We ended up re-substracting the
object stats, as the entry wasn't reset between
the iterations (and we didn't read it because the
key didn't exist).
Sage Weil [Wed, 12 Sep 2012 00:12:06 +0000 (17:12 -0700)]
filejournal: do not enforce that bdev size >= osd journal size
If the configure osd journal size is > the block device size, warn, but
do not generate an error and abort startup. This makes it safe to have
a default 'osd journal size' value of, say, 1 GB without fear of breaking
existing clusters with smaller jouranl block devices.
Signed-off-by: Sage Weil <sage@inktank.com> Reviewed-by: Tommi Virtanen <tv@inktank.com>
projects / ceph.git / log