Option osd_map_message_max_bytes indicates the max bytes of MOSDMap message, not maps count
as osd_map_message_max.
Signed-off-by: haoyixing <haoyixing@kuaishou.com>
* refs/pull/37428/head:
mds: move duplicated inner loop out
mds: try to replicate hot dir to restarted MDS
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Sidharth Anupkrishnan <sanupkri@redhat.com>
* refs/pull/38672/head:
mds: increase the l_mds_openino_backtrace_fetch when fetching the backtrace
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
* refs/pull/38668/head:
osdc: Fix return type of map waiting functions
monc: Use post rather than defer
common/async: Hold lock in constructor of blocked_result
osdc: Don't keep wrapping completion in wait_for_latest_osdmap
neorados: Replace unsafe uses of dispatch with post
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
This prevents the first mgr from being shut down due to lack of
appropriate placements.
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
Signed-off-by: Yuri Weinstein <yweinste@redhat.com>
options passed to vstart.sh via the -o param and bunched on the same
line without line termination between them
hence not being parsed.
ex:
```
cat ./ceph.conf
...
debug_ms=0 debug_objecter=0 bluestore_debug_enforce_settings=ssd
bluestore_block_size=214748364800
...
```
Fixes: https://tracker.ceph.com/issues/48708
Signed-off-by: Mark Kogan <mkogan@redhat.com>
Use a 120s timer to force abort the messenger test which should normally
succeeds in 60s, in order to:
* Fail the make check to print logs about where it is blocking;
* Free the listening IP address for the next make check;
Signed-off-by: Yingxin Cheng <yingxin.cheng@intel.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/37721/head:
test: add tests for new snapshot APIs
pybind/cephfs: python bindings for new snapshot APIs
client: Snapshot cephfs APIs
mds: include snapshot metadata in trace reply to client
mds: include snap metadata on-disk on snapshot creation
mds: include metadata in SnapInfo structure
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
This commit
- alters the structure of the
unit-test section of the Developer Guide
that discusses the tox tool, which is
used to run certain unit tests
- corrects some grammar
- updates the list of locations of tox.ini
files
- This also incorporates N. Cutler's suggestions.
Signed-off-by: Zac Dover <zac.dover@gmail.com>
map<K,V>::value_type is pair<const K, V>, so if we use range-based for
loop when iterating through a map, we should use pair<const K,V> instead
of pair<K,V>, the latter also compiles, but it might create a temporary
object of pair<K,V> from pair<const K,V>. GCC-11 complains at seeing
this:
../src/include/denc.h:1002:21: warning: loop variable ‘e’ of type ‘const T&’ {aka ‘const std::pair<OSDPerfMetricQuery, OSDPerfMetricReport>&’} binds to a tem\
porary constructed from type ‘const std::pair<const OSDPerfMetricQuery, OSDPerfMetricReport>’ [-Wrange-loop-constru
ct]
1002 | for (const T& e : s) {
| ^
this change
* use the value_type of container in `maplike_details<Container>`,
so we can avoid the overhead of creating temporay objects when
encoding a map
* define denc_traits for std::pair<const A, B> as well, so the elements
of a map can be encoded using denc facility
Signed-off-by: Kefu Chai <kchai@redhat.com>
os/bluestore: allow dynamic levels
Reviewed-by: Igor Fedotov <ifedotov@suse.com>
Reviewed-by: Adam Kupczyk <akupczyk@redhat.com>
Reviewed-by: Mark Nelson <mnelson@redhat.com>
A thread that holds the GIL while attempting to acquire a mutex will cause a deadlock
if another thread owns the mutex and is waiting on the GIL. The GIL must not be treated
like an ordinary mutex since it may be preempted at any time or released when doing
blocking I/O. Such deadlocks are severe since they starve all threads from access to the
GIL and therefore prevent any Python code from running until the mgr process is restarted.
Fixes: https://tracker.ceph.com/issues/39264
Signed-off-by: Cory Snyder <csnyder@iland.com>
mgr/dashboard: Use secure cookies to store JWT Token
Reviewed-by: Alfonso Martínez <almartin@redhat.com>
Reviewed-by: Ernesto Puerta <epuertat@redhat.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
E.g.,
(1) recovery_info.copy_subset = [0, 4194304]
(2) copy_subset(fiemap) = [0, 8192]
(3) out_op->data_included.span_of(copy_subset, 0, 4194304) = [0, 8192]
We'll set new_progress.data_recovered_to = 8192 as a result, and
fail to complete the push in one go.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
