The locking and blocking around this was a bit
tricky. Do the simple thing, and pull the
load_store out to Mgr so that it can be safely
done as part of the background_init process (just drop
Mgr::lock across blocking actions).
Signed-off-by: John Spray <john.spray@redhat.com>
The race happes, if a task raises an exception very early.
Then, `self.getter_thread.event` fails as `getter_thread` is
already `None`
Also fix use-before-assignment, as `t0` and `t1` are only defined,
if no exception was raised.
Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
If we are a service daemon, send a MMgrClose on shutdown to clear ourselves
out of the ServiceMap.
Note that this is a best-effort attempt; we don't block shutdown if the
mgr isn't currently available.
Signed-off-by: Sage Weil <sage@redhat.com>
when running those cmds, check if the module do exist
or is disabled already.
also check if the module is enabled already.
Signed-off-by: Gu Zhongyan <guzhongyan@360.cn>
This is a follow-up fix of https://github.com/ceph/ceph/pull/21578,
in which I forget that erasure-coded-pools share the same logic
when determining the async_recovery_targets..
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Performing overflowed log-trim can be a sign of big trouble, e.g.,
the **complete_to** iterator will now point to an invalid position
of the original pg-log list when the trimming is done, and hence
randomly trigger **Segmentation fault**s as below:
```
2018-03-07 17:38:46.109018 7f274a4ed700 -1 *** Caught signal (Segmentation fault) **
1: (()+0xa51f31) [0x7f278290bf31]
2: (()+0xf370) [0x7f277fb4f370]
3: (PrimaryLogPG::recover_got(hobject_t, eversion_t)+0x266) [0x7f2782512786]
4: (PrimaryLogPG::on_local_recover(hobject_t const&, ObjectRecoveryInfo const&, std::shared_ptr<ObjectContext>, bool, ObjectStore::Tran
saction*)+0x2a4) [0x7f278251f3b4]
5: (ReplicatedBackend::handle_push(pg_shard_t, PushOp const&, PushReplyOp*, ObjectStore::Transaction*)+0x2e2) [0x7f2782690f82]
6: (ReplicatedBackend::_do_push(boost::intrusive_ptr<OpRequest>)+0x194) [0x7f2782691224]
7: (ReplicatedBackend::_handle_message(boost::intrusive_ptr<OpRequest>)+0x2f1) [0x7f278269fd41]
8: (PGBackend::handle_message(boost::intrusive_ptr<OpRequest>)+0x50) [0x7f27825c2470]
```
The root cause of why PGs are starting to trim more log entries than
we expect is still lost to me, but setting the trap here should generally
do no harm and hopefully expose the above problem a little bit more offen.
We'll see.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
"ceph fs set cephfs allow_multimds false" is deprecated, and multimds is
enabled by default, so "ceph fs set cephfs max_mds 4" won't fail with
the default settings.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* to pick up the fix of https://svn.boost.org/trac10/ticket/11622
* also the boost::python's library name now includes the version suffix
of python version, so update BuildBoost.cmake accordingly.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Theoretically peers which have a longer list of objects to recover
shall equivalently take a longer time to recover and hence have a
bigger chance to block client ops.
Also, to minimize the risk of data loss, we want to bring those broken
(inconsistent) peers back to normal as soon as possible. Putting them
into the async_recovery_targets queue, however, did quite the oppsite.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
cmake: hide symbols import from other libraries in libcls_*
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
Reviewed-by: Casey Bodley <cbodley@redhat.com>
to silence the warnings like
CMake Warning at CMakeLists.txt:73 (find_package):
By not providing "Findgflags.cmake" in CMAKE_MODULE_PATH this project
has
asked CMake to find a package configuration file provided by "gflags",
but
CMake did not find one.
Could not find a package configuration file provided by "gflags" with
any
of the following names:
gflagsConfig.cmake
gflags-config.cmake
Add the installation prefix of "gflags" to CMAKE_PREFIX_PATH or set
"gflags_DIR" to a directory containing one of the above files. If
"gflags"
provides a separate development package or SDK, be sure it has been
installed.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so they will not be involved when resolving symbols. ld tries to
keep a shared library around even if it fails to load it if it offers
some unique symbols. in that case, the library will not be properly
unloaded, and even worse it will interfere with following dlopen()
calls, because it is marked with NODELETE by dlopen(). if it has some
unresolved symbol and does offer some "unique" symbols required by
the library to be loaded, the library will fail to load, despite the
fact that the "unique" symbol is also offered by the executable.
for more details, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 and
https://sourceware.org/bugzilla/show_bug.cgi?id=14577
Fixes: http://tracker.ceph.com/issues/23517
Signed-off-by: Kefu Chai <kchai@redhat.com>
somehow this was breaking the seeding of thread-local engines on gcc.
we'll have to investigate this further, but for now i'm reverting this
piece to get messengers working again
Fixes: http://tracker.ceph.com/issues/23778
Signed-off-by: Casey Bodley <cbodley@redhat.com>
Updated the dashboard feature list in the documentation to mention
the possibility to list Ceph pools and the RGW users and their buckets.
Signed-off-by: Lenz Grimmer <lgrimmer@suse.com>
