mirror of
https://github.com/ceph/ceph
synced 2024-12-19 01:46:00 +00:00
ebd0fcd067
* refs/pull/16779/head:
mds: cleanup MDCache::open_snaprealms()
mds: make sure snaptable version > 0
mds: don't consider CEPH_INO_LOST_AND_FOUND as base inode
mds: replace MAX() with std::max()
tools/cephfs: make cephfs-data-scan create snaprealm for base inodes
qa/cephfs: don't run TestSnapshots.test_kill_mdstable on kclient
qa/cephfs: adjust check of 'cephfs-table-tool all show snap' output
mds: don't warn unconnected snaplrealms in cluster log
mds: update CInode/CDentry's first according to global snapshot seq
qa/cephfs: add tests for snapclient cache
qa/cephfs: add tests for snaptable transaction
mds: add asok command that dumps cached snap infos
qa/cephfs: add tests for multimds snapshot
client: don't mark snap directory complete when its dirstat is empty
qa/workunits/snaps: add snaprealm split test
mds: make sure mds has uptodate mdsmap before checking 'allows_snaps'
client: fix incorrect snaprealm when adding caps
qa/workunits/snaps: add hardlink snapshot test
mds: add incompat feature and bump protocol for snapshot changes
mds: detach inode with single hardlink from global snaprealm
mds: record hardlink snaps in inode's snaprealm
mds: attach inode with multiple hardlinks to dummy global snaprealm
mds: cleanup rename code
mds: ensure xlocker has uptodate lock state
mds: simplify SnapRealm::build_snap_{set,trace}
mds: record global last_created/last_destroyed in snaptable
mds: pop projected snaprealm before inode's parent changes
mds: keep isnap lock in sync state
mds: handle mksnap vs resolve_snapname race
mds: cleanup snaprealm past parents open check
mds: rollback snaprealms when rolling back slave request
mds: send updated snaprealms along with slave requests
mds: explict notification for snap update
mds: send snap related messages centrally during mds recovery
mds: synchronize snaptable caches when mds recovers
mds: introduce MDCache::maybe_finish_slave_resolve()
mds: notify all mds about prepared snaptable update
mds: record snaps in old snaprealm when moving inode into new snaprealm
mds: cache snaptable in snapclient
mds: recover snaptable client when mds enters resolve state
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
|
||
|---|---|---|
| .. | ||
| archs | ||
| btrfs | ||
| cephfs | ||
| client | ||
| clusters | ||
| config | ||
| crontab | ||
| debug | ||
| distros | ||
| erasure-code | ||
| libceph | ||
| machine_types | ||
| mds | ||
| mon/bootstrap | ||
| mon_kv_backend | ||
| nightlies | ||
| objectstore | ||
| objectstore_cephfs | ||
| overrides | ||
| packages | ||
| qa_scripts | ||
| rbd | ||
| releases | ||
| rgw_frontend | ||
| rgw_pool_type | ||
| standalone | ||
| suites | ||
| tasks | ||
| timezone | ||
| workunits | ||
| .gitignore | ||
| find-used-ports.sh | ||
| loopall.sh | ||
| Makefile | ||
| README | ||
| run_xfstests_qemu.sh | ||
| run_xfstests-obsolete.sh | ||
| run_xfstests.sh | ||
| run-standalone.sh | ||
| runallonce.sh | ||
| runoncfuse.sh | ||
| runonkclient.sh | ||
| setup-chroot.sh | ||
| tox.ini | ||
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