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>
If the format argument to a command sent to the admin socket is not
among the supported formats ( json, json-pretty, xml, xml-pretty ) the
new_formatter function will return null and the AdminSocketHook::call
function must fall back to a sensible default.
The CephContextHook::call and HelpHook::call failed to do that and a
malformed format argument would cause the mon to crash. A check is added
to each of them and fallback to json-pretty if the format is not
recognized.
To further protect AdminSocketHook::call implementations from similar
problems the format argument is checked immediately after accepting the
command in AdminSocket::do_accept and replaced with json-pretty if it is
not known.
A test case is added for both CephContextHook::call and HelpHook::call
to demonstrate the problem exists and is fixed by the patch.
Three other instances of unsafe calls to new_formatter were found and
a fallback to json-pretty was added. All other calls have been audited
and appear to be safe.
http://tracker.ceph.com/issues/7378fixes#7378
Backport: emperor, dumpling
Signed-off-by: Loic Dachary <loic@dachary.org>
Explain why people should be using the "raw" image format for RBD
volumes created for use by QEMU: using any other format adds only
overhead, but no extra value (since RBDs are also CoW and
thin-provisioned), plus the Qcow2 storage driver is not migration safe
when caching is enabled, whereas the RBD driver is.
Also, fix a minor glitch in the example qemu-img commands ("-f rbd"
and "-O rbd" should really be "-f raw" and "-O raw").
Finally, drop the "-f" option altogether on qemu-img commands where it
makes no sense (info and resize).
Signed-off-by: Florian Haas <florian@hastexo.com>
A few places were not checking the return values of commands, since
they could not fail before timeouts were added.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Some functions could not previously return errors, but they had an
int return value, which can now receive ETIMEDOUT.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
This makes it possible to test timeouts reliably by delaying certain
messages effectively forever, but still being able to e.g. connect and
authenticate to the monitors.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
This captures almost all operations from librados other than mon_commands().
Get the values for the timeouts from the Objecter constructor, so only
librados uses them.
Add C_Cancel_*_Op, finish_*_op(), and *_op_cancel() for each type of
operation, to mirror those for Op. Create a callback and schedule it
in the existing timer thread if the timeouts are specified.
Fixes: #6507
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Currently CEPH_HAVE_SETPIPE_SZ is not set even if F_SETPIPE_SZ is
available, because AC_COMPILE_IFELSE test program as written always
fails to compile. F_SETPIPE_SZ is a macro, so use AC_EGREP_CPP which
works on the preprocessor output instead of trying to compile.
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
It seems to be reasonable easy to complete a flush before the next client
request is processed. Crazy...
Same with the flush vs write race.
Fixes: #7329
Signed-off-by: Sage Weil <sage@inktank.com>
The current crush_choose_firstn code will re-use the same 'r' value for
the recursive call. That means that if we are hitting a collision or
rejection for some reason (say, an OSD that is marked out) and need to
retry, we will keep making the same (bad) choice in that recursive
selection.
Introduce a tunable that fixes that behavior by incorporating the parent
'r' value into the recursive starting point, so that a different path
will be taken in subsequent placement attempts.
Note that this was done from the get-go for the new crush_choose_indep
algorithm.
This was exposed by a user who was seeing PGs stuck in active+remapped
after reweight-by-utilization because the up set mapped to a single OSD.
Signed-off-by: Sage Weil <sage@inktank.com>
Back in 27f4d1f6bc we refactored the CRUSH
code to allow adjustment of the retry counts on a per-pool basis. That
commit had an off-by-one bug: the previous "tries" counter was a *retry*
count, not a *try* count, but the new code was passing in 1 meaning
there should be no retries.
Fix the ftotal vs tries comparison to use < instead of <= to fix the
problem. Note that the original code used <= here, which means the
global "choose_total_tries" tunable is actually counting retries.
Compensate for that by adding 1 in crush_do_rule when we pull the tunable
into the local variable.
This was noticed looking at output from a user provided osdmap.
Unfortunately the map doesn't illustrate the change in mapping behavior
and I haven't managed to construct one yet that does. Inspection of the
crush debug output now aligns with prior versions, though.
Signed-off-by: Sage Weil <sage@inktank.com>
