librbd: clarify handle_sparse_read condition

The earlier condition is >. != means < at this point, and the nesting
is unnecessary.

Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
librbd: clean up snapshot handling a bit

* snapid should determine whether our mapped snapshot is gone, not snapname
* snap_set(<nonexistent_snap>) shouldn't reset us to CEPH_NOSNAP
* snapname should be set before using the it in the perfcounter name
* snapname and image name don't need to be passed as arguments since an
  ImageCtx already contains that info
* ictx_check() doesn't need to check for non-existent snaps - only I/Os care,
  so check in check_io() instead

Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
librbd: reset needs_refresh flag before re-reading header

This way we can't miss an update if we get a notify during ictx_refresh.
Specifically, a race like this:

Thread 1               Thread 2              Process 2

ictx_refresh()
read_header()
                                             snap_create()
                       notify()
                       need_refresh = true
process header...
need_refresh = false

If this happened, we would not re-read the header with the new
snapshot, so the snapshot would not happen at the intended point
in time, but only after we re-read the header again.

Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
test_rbd: add tests for snap_set and more complicated resizing

* snap_set to a deleted (and recreated) snapshot
* resizing down (truncating) and back up
* resizing to non-object-aligned sizes

Signed-off-by: Josh Durgin <josh.durgin@dreamhost.com>
Merge remote branch 'origin/wip-rbd-snapid' into next

Reviewed-by: Sage Weil <sage.weil@dreamhost.com>
mon: decode old PGMap Incrementals differently from new ones

We need to distinguish between the old 0 (meaning undefined) and
the new 0 (meaning switch to 0 and disable the flags). So rev the
encoding version on PGMap::Incremental, and if you decode an old
version with [near]full_ratio == 0, set the ratio to -1 instead. Then
when applying the Incremental interpret -1 as no change.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
Reviewed-by: Sage Weil <sage@newdream.net>
PG: whitelist MNotifyRec in started

Signed-off-by: Samuel Just <samuel.just@dreamhost.com>
Revert "PG: whitelist MNotifyRec in started"

This reverts commit 9579365720818125a4b15741ae65e58948b9c69f.
PG: get_infos() should not post GotInfo

The MNotifyRec handler also posts GotInfo under the same conditions
after calling get_infos().

Signed-off-by: Samuel Just <samuel.just@dreamhost.com>
osd: filter osds removed from probe set from peer_info_requested

Peef_info_requested should be a strict subset of the probe set.  Filter
osds that are dropped from probe from peer_info_requested.  We could also
restart peering from scratch here, but this is less expensive, because we
don't have to re-probe everyone.

Once we adjust the probe and peer_info_requested sets, (re)check if we're
done: we may have been blocedk on a previous peer_info_requested entry.

The situation I saw was:

  "recovery_state": [
        { "name": "Started\/Primary\/Peering\/GetInfo",
          "enter_time": "2012-04-25 14:39:56.905748",
          "requested_info_from": [
                { "osd": 193}]},
        { "name": "Started\/Primary\/Peering",
          "enter_time": "2012-04-25 14:39:56.905748",
          "probing_osds": [
                79,
                191,
                195],
          "down_osds_we_would_probe": [],
          "peering_blocked_by": []},
        { "name": "Started",
          "enter_time": "2012-04-25 14:39:56.905742"}]}

Once in this state, cycling osd.193 doesn't help, because the prior_set
is not affected.

Signed-off-by: Sage Weil <sage.weil@dreamhost.com>
Reviewed-by: Samuel Just <samuel.just@dreamhost.com>
filestore: fix a journal replay issue with collection_add()

Signed-off-by: Joao Eduardo Luis <jecluis@gmail.com>
Merge remote-tracking branch 'gh/next' into wip-congress