When using the presets for compatibility (i.e., based on version), do not
touch the straw behavior, as it does not affect mapping or compatibility.
However, make a point of setting it by default and for optimal.
For most users, this means that they will not see any change unless they
explicitly enable the new behavior, or switch to default or optimal
tunables. The idea is that if they touched it, they shouldn't be
too surprised by the subsequent data movement.
Signed-off-by: Sage Weil <sage@redhat.com>
The straw bucket was originally tested with uniform weights and with a
few more complicated patterns, like a stair step (1,2,3,4,5,6,7,8,9). And
it worked!
However, it does not behave with a pattern like
1, 2, 2, 3, 3, 4, 4
Strangely, it does behave with
1, 1, 2, 2, 3, 3, 4, 4
and more usefully it does behave with
1, 2, 2.001, 3, 3.001, 4, 4.001
That is, the logic that explicitly copes with weights that are duplicates
is broken.
The fix is to simply remove the special handling for duplicate weights --
it isn't necessary and doesn't work correctly anyway.
Add a test that compares the mapping result of [1, 2, 2, 3, 3, ...] with
[1, 2, 2.001, 3, 3.001, ...] and verifies that the difference is small.
With the fix, we get .00012, whereas the original implementation gets
.015.
Note that this changes the straw bucket scalar *precalculated* values that
are encoded with the map, and only when the admin opts into the new behavior.
Backport: giant, firefly
Signed-off-by: Sage Weil <sage@redhat.com>
The presence of a 0-weight item in a straw bucket should have no effect
on the placement of other items. Add a test validating that and fix
crush_calc_straw() to fix the distortion.
Note that this effects the *precalculation* of the straw bucket inputs and
does not effect the actually mapping process given a compiled or encoded
CRUSH map, and only when straw_calc_version == 1 (i.e., the admin opted in
to the new behavior).
Backport: giant, firefly
Signed-off-by: Sage Weil <sage@redhat.com>
Stick with bobtail tunables where it affects compatibility. Use v1 of
straw_calc, though, since that does not, and we want the best for new
clusters.
Signed-off-by: Sage Weil <sage@redhat.com>
The crushtool --reweight function triggers a fresh calculation of bucket
weights so that they are always the sum of the item weights. In the
straw bucket case, the weights were updated but the corresponding straw
scalers were not being recalculated. The result is that there was not
effect on placement in adjusted buckets until the next time a bucket item's
weight was adjusted.
Backport: giant, firefly
Signed-off-by: Sage Weil <sage@redhat.com>
It is not enough to git submodule update on a existing git clone: if the
URL of the repository has been changed, the
git submodule sync
command must be called to synchronizes submodules' remote URL
configuration setting to the value specified in .gitmodules.
http://tracker.ceph.com/issues/10173Fixes: #10173
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Point his addresses at Red Hat now, but revert the Inktank->Redhat mappings
so we have more historical accuracy.
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
* a non-zero CEPH_LOCKDEP brings ceph down because g_lockdep_ceph_ctx
is still being constructed when dout_impl() dereferences it.
* fix a typo in comment.
* remove dead code.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
Fixes: #10103
Backport: firefly, giant
This turned up after fixing #9973. Earlier we also didn't create the
subuser in this case, but we didn't really read the subuser info when it
was authenticating. Now we do that as required, so we end up failing the
authentication. This only applies to cases where a subuser was created
using 'user create', and not the 'subuser create' command.
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
