]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
crushtool: new cli tests for the vary-r tunable
authorSage Weil <sage@inktank.com>
Tue, 4 Feb 2014 23:59:22 +0000 (15:59 -0800)
committerSage Weil <sage@inktank.com>
Tue, 11 Feb 2014 19:11:25 +0000 (11:11 -0800)
commit37f840b499da1d39f74bfb057cf2b92ef4e84dc6
tree913c0aebb08bffc34ccec4c80d89999abacf55c1
parente88f843c99c0a45390f71c2a5e53a52305c041fd
crushtool: new cli tests for the vary-r tunable

These illustrate the variation in mapping results as the vary_r tunable
is adjusted.  Note:

1- For the vary_r=0 case, we have several inputs that map to only a single
output:

      rule 3 (delltestrule) num_rep 4 result size == 1:\t27/1024 (esc)
      rule 3 (delltestrule) num_rep 4 result size == 2:\t997/1024 (esc)

This is the behavior we are fixing.  For all of the other values of
vary_r, we get 2 outputs for all inputs.

2- If we use vary_r 1, which is likely the most efficient computation,
we get lots of inputs that change.  By setting larger values of vary_r,
we can trade a bit of extra computation to get a mapping that is more
similar to the legacy behavior. This is useful for legacy clusters:

    $ for f in `seq 1 4` ; do diff -u test-map-vary-r-0.t test-map-vary-r-$f.t | grep -c -- +  ; done
    3030
    1629
    645
    228

The crushmap here comes from a user who was seeing a bad mapping for certain
pgs after some OSDs were reweighted by utilization.

Signed-off-by: Sage Weil <sage@inktank.com>
src/test/cli/crushtool/test-map-vary-r-0.t [new file with mode: 0644]
src/test/cli/crushtool/test-map-vary-r-1.t [new file with mode: 0644]
src/test/cli/crushtool/test-map-vary-r-2.t [new file with mode: 0644]
src/test/cli/crushtool/test-map-vary-r-3.t [new file with mode: 0644]
src/test/cli/crushtool/test-map-vary-r-4.t [new file with mode: 0644]
src/test/cli/crushtool/test-map-vary-r.crushmap [new file with mode: 0644]