The gcc version of this is smart enough to handle any alignment
issues that exist and *should* generate the fastest code that is
general and correct.
On x86_64 this performs identically for the uint64_t
microbenchmark.
Suggested-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Sage Weil <sage@redhat.com>
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>
* we do not persist current hit set using get_hit_set_current_object()
anymore, instead we always append current hitset into archive even
!hitset.is_full(), see fbd9c15. so it's not necessary to remove the
current hitset object before putting it to disk.
Signed-off-by: Kefu Chai <kchai@redhat.com>
allow "ceph osd pool set $pool use_gmt_hitset <true|1>" as long as
the cluster supports gmt hitset.
Fixes: #9732
Signed-off-by: Kefu Chai <kchai@redhat.com>
* bump the encoding version of pg_hit_set_info_t to 2, so we can
tell if the corresponding hit_set is named using localtime or
GMT
* bump the encoding version of pg_pool_t to 20, so we can know
if a pool is using GMT to name the hit_set archive or not. and
we can tell if current cluster allows OSDs not support GMT
mode or not.
* add an option named `osd_pool_use_gmt_hitset`. if enabled,
the cluster will try to use GMT mode when creating a new pool
if all the the up OSDs support GMT mode. if any of the
pools in the cluster is using GMT mode, then only OSDs
supporting GMT mode are allowed to join the cluster.
Fixes: #9732
Signed-off-by: Kefu Chai <kchai@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>
