mirror of
https://github.com/ceph/ceph
synced 2024-12-29 15:03:33 +00:00
2142114a2d
When the ESubtreeMap is very large (~5k+ subtrees), the MDS will end up logging only a few events (as bad as 1) per segment as the subtree map dominates the segment size. This test simply creates an artificially large subtree and confirms that other file system activity completes in a timely manner. This is now taking advantage of the minor segments which allows for a normal set of events per log segment (and fewer subtree maps). The test fails on the current main HEAD. Historical note: when I first observed this abberant behavior, the vstart cluster was actually using mds_debug_subtrees = True (the default for every vstart cluster). This caused the MDS to write out the subtree map (for debugging reasons) with every event. When testing the MDS with large subtrees (distributed ephemeral pinning), this caused the MDS to slow to a trickle of operations per second. Despite this unintentional misconfiguration, the problem still exists but the number of auth subtrees must be large for a particlar rank to replicate the behavior. On main HEAD, the creation of 10k files (workload stage) takes ~110 seconds. On this branch, it takes ~30 seconds. Signed-off-by: Patrick Donnelly <pdonnell@redhat.com> |
||
---|---|---|
.. | ||
archs | ||
btrfs | ||
cephfs | ||
client | ||
clusters | ||
config | ||
crontab | ||
debug | ||
distros | ||
erasure-code | ||
libceph | ||
machine_types | ||
mds | ||
mgr_ttl_cache | ||
mon/bootstrap | ||
mon_election | ||
msgr | ||
nightlies | ||
objectstore | ||
objectstore_cephfs | ||
objectstore_debug | ||
overrides | ||
packages | ||
qa_scripts | ||
rbd | ||
releases | ||
rgw | ||
rgw_bucket_sharding | ||
rgw_frontend | ||
rgw_pool_type | ||
standalone | ||
suites | ||
tasks | ||
timezone | ||
workunits | ||
.gitignore | ||
.qa | ||
CMakeLists.txt | ||
find-used-ports.sh | ||
loopall.sh | ||
lsan.supp | ||
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, or a directory whose name ends with '$', represents a test where one of the non-magic items is chosen randomly. For example, both suites/foo/$ suites/foo/a.yaml suites/foo/b.yaml suites/foo/c.yaml and suites/foo$/a.yaml suites/foo$/b.yaml suites/foo$/c.yaml is a single test, either a, b or c. This can be used in conjunction with the '%' file in the same (see below) or other directories to run a series of tests without causing an unwanted increase in the total number of jobs run. Symlinks are okay. One particular use of symlinks is to combine '%' and the latter form of '$' feature. Consider supported_distros directory containing fragments that define os_type and os_version: supported_distros/% supported_distros/centos.yaml supported_distros/rhel.yaml supported_distros/ubuntu.yaml A test that links supported_distros as distros (a name that doesn't end with '$') will be run three times: on centos, rhel and ubuntu. A test that links supported_distros as distros$ will be run just once: either on centos, rhel or ubuntu, chosen randomly. The teuthology code can be found in https://github.com/ceph/teuthology.git