On some systems (virtual machines so far) the device-by-path entry
from udevadm is not always in the same spot so instead actually
look for the right output instead of blindy assuming that its a
specific field in the output.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Reviewed-by: Gary Lowell <gary.lowell@inktank.com>
It's only present in very recent versions of nose, and doesn't provide
much beyond a simple assert.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
Fixes bug 5528
Since it returns all xattrs, it does not take an xattr_name. Also,
add unit tests for the Object xattrs methods.
Signed-off-by: Johannes Erdfelt <johannes@erdfelt.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
We should not send an unbounded number of inc maps to our peers or clients.
In particular, if a peer is not contacted for a while, we may think they
have a very old map (say, 10000 epochs ago) and send thousands of inc maps
when the distribution shifts and we need to peer.
Note that if we do not send enough maps, the peers will make do by
requesting the map from somewhere else (currently the mon). Regardless
of the source, however, we must limit the amount that we speculatively
share as it usually is not needed.
Backport: cuttlefish, bobtail
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Samuel Just <sam.just@inktank.com>
The field is not used or useful since the monitor does not even look
at it (in Monitor::handle_command()). Avoid populating it and the
subsequent confusion for poor developers.
Signed-off-by: Sage Weil <sage@inktank.com>
The PaxosServiceMessage version field is meant for client-coordinated
ordering of messages when switching between monitors (and is rarely
used). Do not fill it with the osdmap epoch lest it be compared to a
pgmap version, which may cause the mon to (near) indefinitely put it on
a wait queue until the pgmap version catches up.
Backport: cuttlefish
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
fixes: #4982fixes: #4983
Reviewed-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Reviewed-by: David Zafman <david.zafman@inktank.com>
This prevents an assert from unexpected scrub results from the previous
scrub on the leader.
Backport: cuttlefish
Signed-off-by: Sage Weil <sage@inktank.com>
Remove locator arg from get_object_context()/find_object_context()
Remove locator from object_info_t but retain encode format
Remove locator from object_info_t dump output
Remove OLOC_BLANK
Signed-off-by: David Zafman <david.zafman@inktank.com>
Parse namespace spec in osd caps and use in is_match()
Add test cases to unit test
feature: #4983 (OSD: namespaces pt 2 (caps))
Signed-off-by: David Zafman <david.zafman@inktank.com>
Add rados_ioctx_namespace_set_key() and librados::IoCtx::namespace_set_key()
Add namespace to admin-daemon operations
Support namespace in osd map command
Add namespace to object_locator_t and hobject_t
Add random namespaces to psim program
Feature: #4982 (OSD: namespaces pt 1 (librados/osd, not caps))
Signed-off-by: David Zafman <david.zafman@inktank.com>
This rarely represents an actual eversion_t as the epoch and seq values are
bumped semi-independently to ensure it is always unique. Break it into
two separate fields to avoid confusion.
Drop now-unused and slightly curious inc() method.
Signed-off-by: Sage Weil <sage@inktank.com>
We need to take PGs whose mapping has not changed in a long time into
account. For them, the pg state will indicate it was clean at the time of
the report, in which case we can use that as a lower-bound on their actual
latest epoch clean. If they are not currently clean (at report time), use
the last_epoch_clean value.
Fixes: #5519
Signed-off-by: Sage Weil <sage@inktank.com>
The mon needs a moderately accurate last_epoch_clean value in order to trim
old osdmaps. To prevent a PG that hasn't peered or received IO in forever
from preventing this, send pg stats at some minimum frequency. This will
increase the pg stat report workload for the mon over an idle pool, but
should be no worse that a cluster that is getting actual IO and sees these
updates from normal stat updates.
This makes the reported update a bit more aggressive/useful in that the epoch
is the last map epoch processed by this PG and not just one that is >= the
currenting interval. Note that the semantics of this field are pretty useless
at this point.
See #5519
Signed-off-by: Sage Weil <sage@inktank.com>
In certain cases the admin may know that it is safe to trim old osdmaps but
a bug or other issue is preventing the Monitor from deciding on its own.
Signed-off-by: Sage Weil <sage@inktank.com>
This particular failure is easily triggered by the crush_ops.sh
workunit. Make it a bit less likely to fail.
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
