osd_types: add generic HitSet type with bloom and explicit implementations

Track a set of hash values, either explicitly or using a bloom_filter. Hide
the implementation and allow us to transparently encode and decode.

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
HitSet: reimplement Params for a better interface (I hope)

Signed-off-by: Greg Farnum <greg@inktank.com>
HitSet: allow copying Hitsets and the Impls

Signed-off-by: Greg Farnum <greg@inktank.com>
osd/HitSet: refactor Param stuff

Signed-off-by: Sage Weil <sage@inktank.com>
osd/osd_types: add pg_hit_set_{info,history}_t

Signed-off-by: Sage Weil <sage@inktank.com>
osd/osd_types: include pg_hit_set_history_t in pg_info_t

Track metadata about the currently accumulating HitSet as well as
previously archived ones in the pg_info_t.  This will not scale well for
extremely long histories, but does let us avoid explicitly sharing this
metadata during recovery or other normal update activity.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: add hit_set_* parameters to pg_pool_t

Add pool properties to control what type of HitSet we want to use, along with
some (mostly generic) parameters.

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
fixup "osd: add hit_set_* parameters to pg_pool_t"
mon/OSDMonitor: set hit_set fields

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
fixup "mon/OSDMonitor: set hit_set fields"
osd/ReplicatedPG: add basic HitSet tracking

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
fixup "osd/ReplicatedPG: add basic HitSet tracking"
osd/ReplicatedPG: use vectorized osd_op outdata for pg ops

This lets us put PGLS in a compound operation.  Nothing does that yet, but
this would allow it.
Despite appearances, this is not a protocol change and does not require
a feature bit for clients: using the osd_ops vector mechanisms store all
the data in the same places as before, it just fills in some of the
already-decoded-but-empty data structures in the MOSDOpReply header.
<Greg note:> We may need a feature bit to let clients know they can send
compound PG ops to OSDs, though? Or maybe we can let it be covered
by supporting hitset ops.

Signed-off-by: Sage Weil <sage@inktank.com>
librados, osd: list and get HitSets via librados

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
librados: create new ceph_test_rados_api_tier target

Move the dirty/undirty test to it, and add one for HitSets.

Signed-off-by: Sage Weil <sage@inktank.com>
Signed-off-by: Greg Farnum <greg@inktank.com>
osd/HitSet: only compress if density is < 50%

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: put hit_set objects in a configurable namespace

Signed-off-by: Sage Weil <sage@inktank.com>
osd/osd_types: add eversion_t to hit_set_info_t

Track the eversion stamp on the hit_set objects we've written.  This makes
life a bit easier later when we need to generate log entries and don't
want to bother stating the objects.

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: track version on hit_set objects we've written

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: trim old hit_set objects on persist

Any time we persist a hit_set object, take the opportunity to remove any
old ones that we don't want any more.

Note that this means if the admin decreases the number of objects to track,
we won't remove them until the next time we persist something.  We also
don't clean up if the HitSet tracking is disabled entirely.

Signed-off-by: Sage Weil <sage@inktank.com>