mds: fix FP error in ROUND_UP_TO

Explicitly handle case where denominator is 0, instead of
passing into ROUND_UP_TO.

Regression from 9449520b121fc6ce0c64948386d4ff77f46f4f5f

Signed-off-by: John Spray <john.spray@redhat.com>
Merge pull request #2331 from ceph/wip-9238

mds: fix FP error in ROUND_UP_TO

Reviewed-by: Sage Weil <sage@redhat.com>
PG: make the reservation sets more descriptively named

These sets won't precisely be the backfill_targets or actingbackfill
shortly.

%s/sorted_backfill_set/remote_shards_to_reserve_backfill/g
%s/acting_osd_it/remote_recovery_reservation_it/g
%s/sorted_actingbackfill_set/remote_shards_to_reserve_recovery/g

Signed-off-by: Samuel Just <sam.just@inktank.com>
PG: recover from each osd at most once

Signed-off-by: Samuel Just <sam.just@inktank.com>
Merge pull request #2330 from ceph/wip-9211

osd/OSDMap: encode blacklist in deterministic order

Reviewed-by: Samuel Just <sam.just@inktank.com>
update license for libcephfs

Signed-off-by: rootfs <hchen@redhat.com>
ReplicatedPG::start_flush: remove superfluous loop

Signed-off-by: Samuel Just <sam.just@inktank.com>
tests: histogram prevent re-use of local variables

By moving the test to a separate function.

http://tracker.ceph.com/issues/9235 Fixes: #9235

Signed-off-by: Loic Dachary <loic-201408@dachary.org>
ReplicatedPG:start_flush send a second delete

Suppose we start with the following in the cache pool:

30:[29,21,20,15,10,4]:[22(21), 15(15,10), 4(4)]+head

The object doesn't exist at 29 or 20.

First, we flush 4 leaving the backing pool with:

3:[]+head

Then, we begin to flush 15 with a delete with snapc 4:[4] leaving the
backing pool with:

4:[4]:[4(4)]

Then, we finish flushing 15 with snapc 9:[4] with leaving the backing
pool with:

9:[4]:[4(4)]+head

Next, snaps 10 and 15 are removed causing clone 10 to be removed leaving
the cache with:

30:[29,21,20,4]:[22(21),4(4)]+head

We next begin to flush 22 by sending a delete with snapc 4(4) since
prev_snapc is 4 <---------- here is the bug

The backing pool ignores this request since 4 < 9 (ORDERSNAP) leaving it
with:

9:[4]:[4(4)]

Then, we complete flushing 22 with snapc 19:[4] leaving the backing pool
with:

19:[4]:[4(4)]+head

Then, we begin to flush head by deleting with snapc 22:[21,20,4] leaving
the backing pool with:

22[21,20,4]:[22(21,20), 4(4)]

Finally, we flush head leaving the backing pool with:

30:[29,21,20,4]:[22(21*,20*),4(4)]+head

When we go to flush clone 22, all we know is that 22 is dirty, has snaps
[21], and 4 is clean. As part of flushing 22, we need to do two things:
1) Ensure that the current head is cloned as cloneid 4 with snaps [4] by
sending a delete at snapc 4:[4].
2) Flush the data at snap sequence < 21 by sending a copyfrom with snapc
20:[20,4].

Unfortunately, it is possible that 1, 1&2, or 1 and part of the flush
process for some other now non-existent clone have already been
performed.  Because of that, between 1) and 2), we need to send
a second delete ensuring that the object does not exist at 20.

Fixes: #9054
Backport: firefly
Signed-off-by: Samuel Just <sam.just@inktank.com>
Merge pull request #2333 from dachary/wip-9235-uninitialized-variables

tests: histogram prevent re-use of local variables

Reviewed-by: Sage Weil <sage@redhat.com>
tests: histogram prevent re-use of local variables

By moving the tests to separate functions.

http://tracker.ceph.com/issues/9235 Fixes: #9235

Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Merge pull request #2334 from dachary/wip-9235-uninitialized-variables

tests: histogram prevent re-use of local variables
common: config: let us obtain a diff between current and default config

It's mildly annoying when trying to figure out what has been changed on
a running system's config options and having to rely on whatever is set
on ceph.conf and the admin's memory of what has been injected.

With this we can simply ask the daemon for the diff between what would be
its default and what is its current config.

Current form will output extraneous information that was not directly
supplied by the user though, such as 'host' 'fsid' and 'daemonize', as
well as defaults we may rewrite ourselves (leveldb tunables on the monitor
for instance).  Nonetheless, it's way better than the alternative and
considering it should be used solely for debug purposes I think we can
get away with it.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
common: ceph_context: add admin socket command 'config diff'

Outputs a diff between the current config and what the daemon believes
to be its default config.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
OSD::session_notify_pg_create: requeue at the start of the queue

Introduced: 2120f4bb6c5ba0f066d4541a51ce1d43c8ab6881
Fixes: #9205
Signed-off-by: Samuel Just <sam.just@inktank.com>
PG: mark_log_for_rewrite on resurrection

Fixes: #8777
Backport: firefly
Signed-off-by: Samuel Just <sam.just@inktank.com>
Merge remote-tracking branch 'gh/next'

Conflicts:
	src/os/CollectionIndex.h
osd: fix osd_tp shutdown

We need to clear the queue, not just drain the currently executing jobs.

Fixes: #9218
Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
Merge pull request #2312 from ceph/wip-config-diff

config diff: obtain diff between current config and default config

Reviewed-by: Sage Weil <sage@redhat.com>
Merge pull request #2197 from ceph/wip-mon-empty-store

ceph_mon: check for existing mon store before opening db

Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Pavan Rallabhandi <pavanrallabhandis@gmail.com>