osd/osd_types: add {data,omap}_digest to object_info_t

Also add flags to indicate whether the fields are valid.

Signed-off-by: Sage Weil <sage@redhat.com>
osd/ReplicatedPG: set and invalidate data/omap digests on osd ops

When we create an empty object, we have a known digest of -1.  In a few
cases, we also know the digest from the op (e.g., writefull).  The rest
of the time we invalidate any existing digest.

Signed-off-by: Sage Weil <sage@redhat.com>
osd/ReplicatedPG: kill some dead scrub code

Signed-off-by: Sage Weil <sage@redhat.com>
osd: clean up scrub method debug output

Use __func__ instead of (usually inaccurate) names.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: drop vestigal invalid_snapcolls fields from scrub

This isn't used.  Snapcolls are ancient.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: use -1 for deep scrub digest seed on new OSDs

0 is a weak initial value for a CRC since it doesn't change with a sequence
of 0 bytes (which are relatively common).  -1 is better.  Use -1 when
everyone in the acting set supports it.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: remove more (most? all?) of classic scrub

Hopefully this is everything

Signed-off-by: Sage Weil <sage@redhat.com>
osd: move scrub no good auth check out of helper

This helps call out that this is an exceptional case and simplifies the
helper a bit.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: share auth oi with caller and be_compare_scrub_objects

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: disqualify shards with digests that disagree with oi digest

The auth may or may not know that the digest is truly bad.  Note that we
can only relate scrub digests to those in oi if the scrub used a seed of
-1; older OSDs use 0.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: be explicit about whether bad digest is known bad

The digest may just disagree with our best guess 'auth' shard, or it may
also disagree with the recorded oi digest.  Clarify which.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: complain about bad digest in final pass auth check

This will only trigger if we choose an auth that is known bad, but that
currently can happen, so compalin here too.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: record whole-object digest on scrub

If we do not have a whole-object digest, record one after a deep scrub.

Note that we make no particular attempt to avoid this on frequently
changing objects where the digest will quickly be invalidated.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: scrub: set a min age before we update whole-object digest

If an object is being actively updated, the whole-object digest will
quickly be invalidated.  On deep scrub, only record that digest if the
object is a few hours old.  Otherwise, we are wasting an IO.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: EIO if a full-object read produces a bad digest

Add a tunable to control this.  Returning an EIO instead of garbled data
may not be the best approach in all environments.

Eventually we want to do something better here, like read from a replica
instead.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: pass and verify data+omap digest on copyfrom

Two things here:

 1- Pass the original digest from the source across the wire, if it is
    present.
 2- Calculate a new digest as we receive it, and record that.

If there is a mismatch, we currently crash; need to turn this into an
EIO, most likely.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: add copyfrom error injection

Unfortunately it's nontrivial to inject this from the usual
ceph_test_rados_api_* tests which need to run despite thrashing.

Signed-off-by: Sage Weil <sage@redhat.com>
rados: use copy_from for rados cp (and cppool) command

A hammer CLI won't be able to run against a pre-firefly OSD, but I don't
think we care.

Signed-off-by: Sage Weil <sage@redhat.com>
test/osd/osd-copy-from: simple test of copy-from and error injection

Signed-off-by: Sage Weil <sage@redhat.com>
osd: change omap data encoding in object_copy_data_t

Pass the omap data in the struct as an opaque (encoded) bufferlist.  This
avoids a decode into an STL map, simplifying the crc calculation.  The
win isn't huge (yet) because we still turn it into a map to pass it down
to the ObjectStore method, but that too will change in time.

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