mirror of
https://github.com/ceph/ceph
synced 2025-02-24 11:37:37 +00:00
The number of cloner threads is set to 4 and it can't be configured. This patch makes the number of cloner threads configurable via the mgr config option "max_concurrent_clones". On an increase in number of cloner threads, it will just spawn the difference of threads between existing number of cloner threads and the new configuration. It will not cancel the running cloner threads. On decrease in number of cloner threads, the cases are as follows. 1. If all cloner threads are waiting for the job: In this case, all threads are notified and required number threads are terminated. 2. If all the cloner threads are processing a job: In this case, the condition is validated for each thread after the current job is finished and the thread is termianted if the condition for required number of cloner threads is not satisified. 3. If few cloner threads are processing and others are waiting: The threads which are waiting are notified to validate the number of threads required. If terminating those doesn't satisfy the required number of threads, the remaining threads are terminated upon completion of existing job. Fixes: https://tracker.ceph.com/issues/46892 Signed-off-by: Kotresh HR <khiremat@redhat.com> |
||
---|---|---|
.. | ||
archs | ||
btrfs | ||
cephfs | ||
client | ||
clusters | ||
config | ||
crontab | ||
debug | ||
distros | ||
erasure-code | ||
libceph | ||
machine_types | ||
mds | ||
mon/bootstrap | ||
msgr | ||
nightlies | ||
objectstore | ||
objectstore_cephfs | ||
overrides | ||
packages | ||
qa_scripts | ||
rbd | ||
releases | ||
rgw_bucket_sharding | ||
rgw_frontend | ||
rgw_pool_type | ||
standalone | ||
suites | ||
tasks | ||
timezone | ||
workunits | ||
.gitignore | ||
.teuthology_branch | ||
CMakeLists.txt | ||
find-used-ports.sh | ||
loopall.sh | ||
Makefile | ||
mypy.ini | ||
README | ||
run_xfstests_qemu.sh | ||
run_xfstests-obsolete.sh | ||
run_xfstests.sh | ||
run-standalone.sh | ||
runallonce.sh | ||
runoncfuse.sh | ||
runonkclient.sh | ||
setup-chroot.sh | ||
test_import.py | ||
tox.ini | ||
valgrind.supp |
ceph-qa-suite ------------- clusters/ - some predefined cluster layouts suites/ - set suite The suites directory has a hierarchical collection of tests. This can be freeform, but generally follows the convention of suites/<test suite name>/<test group>/... A test is described by a yaml fragment. A test can exist as a single .yaml file in the directory tree. For example: suites/foo/one.yaml suites/foo/two.yaml is a simple group of two tests. A directory with a magic '+' file represents a test that combines all other items in the directory into a single yaml fragment. For example: suites/foo/bar/+ suites/foo/bar/a.yaml suites/foo/bar/b.yaml suites/foo/bar/c.yaml is a single test consisting of a + b + c. A directory with a magic '%' file represents a test matrix formed from all other items in the directory. For example, suites/baz/% suites/baz/a.yaml suites/baz/b/b1.yaml suites/baz/b/b2.yaml suites/baz/c.yaml suites/baz/d/d1.yaml suites/baz/d/d2.yaml is a 4-dimensional test matrix. Two dimensions (a, c) are trivial (1 item), so this is really 2x2 = 4 tests, which are a + b1 + c + d1 a + b1 + c + d2 a + b2 + c + d1 a + b2 + c + d2 A directory with a magic '$' file represents a test where one of the other items is chosen randomly. For example, suites/foo/$ suites/foo/a.yaml suites/foo/b.yaml suites/foo/c.yaml is a single test. It will be either a.yaml, b.yaml or c.yaml. This can be used in conjunction with the '%' file in other directories to run a series of tests without causing an unwanted increase in the total number of jobs run. Symlinks are okay. The teuthology code can be found in https://github.com/ceph/teuthology.git