lockdep can't handle recursive locks, resulting in false positive
reports for certain set_val_or_die() calls, like via
md_config_t::parse_argv() passed "-m".
Fixes: #12614
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
The boost mt code uses uninitialized memory for extra randomness,
which is a bad idea in general but more importantly makes valgrind
unhappy. Use /dev/urandom instead.
Unfortunately this introduces a link time dependency.. meh!
Fixes: #12736
Signed-off-by: Sage Weil <sage@redhat.com>
When increasing the pg_num of a pool, an assert would fail since the
calculated pgid seed would be for the pool's new pg_num value instead
of the previous pg_num value.
Fixes: #10399
Backport: infernalis, hammer, firefly
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
With cache disabled, closing the image will result in a flush
which might result in the image being refreshed. If this happens
while the image is set to an invalid snapshot, an error will be
returned while closing the image.
Fixes: #12765
Backport: infernalis
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
We need to wait for cleanup to flush before we destroy the
sequencer or else we get a use-after-free.
Introduced e7bbafa3bf.
Fixes: #12766
Signed-off-by: Sage Weil <sage@redhat.com>
Ignore the profile 'directory' field.
This ensures that we can always find plugins even when teh cluster
is installed across a mix of distros.
Rename the option to have no osd_ (or mon_) prefix since anybody
may use the ec factory/plugin code.
We still hard-code .libs in the unit tests... sigh.
Signed-off-by: Sage Weil <sage@redhat.com>
There is one new plugin (shec). When upgrading a cluster, there
must be a protection against the following scenario:
* the mon are upgraded but not the osd
* a new pool is created using plugin shec
* the osd fail to load the shec plugin because they have not been
upgraded
A feature bit is added : PLUGINS_V3. The monitor will only agree to
create an erasure code profile for the shec plugin if all OSDs
supports PLUGINS_V3. Once such an erasure code profile is stored in the
OSDMap, an OSD can only boot if it supports the PLUGINS_V3 feature,
which means it is able to load the shec plugin.
The monitors will only activate the PLUGINS_V3 feature if all monitors
in the quorum support it. It protects against the following scenario:
* the leader is upgraded the peons are not upgraded
* the leader creates a pool with plugin=shec because all OSD have
the PLUGINS_V3 feature
* the leader goes down and a non upgraded peon becomes the leader
* an old OSD tries to join the cluster
* the new leader will let the OSD boot because it does not contain
the logic that would excluded it
* the old OSD will fail when required to load the plugin shec
This is going to be needed each time new plugins are added, which is
impractical. A more generic plugin upgrade support should be added
instead, as described in http://tracker.ceph.com/issues/7291.
See also 9687150cea for the PLUGINS_V2
implementation.
http://tracker.ceph.com/issues/10887Fixes: #10887
Signed-off-by: Loic Dachary <ldachary@redhat.com>
in boost 1.49, BOOST_SCOPE_EXIT() does not accept capture_tuple,
only `(capture) (capture) ...` is supported.
Signed-off-by: Kefu Chai <kchai@redhat.com>
