osd/PG: ignore purged_snaps inconsistencies for now

These are possible because we update purged_snaps, part of the pg_info_t,
but we do not bump the pg version or match it with a log entry, which
means that the change does not reliably propagate to new OSDs during
peering etc.

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

diff --git a/src/osd/PG.cc b/src/osd/PG.cc
index a2cfc99cecdf88e9460c24305b9d1893432eea0f..dd791e5b3af4c35469fa9acbf15c29d7113679ec 100644 (file)
--- a/src/osd/PG.cc
+++ b/src/osd/PG.cc
@@ -7360,7 +7360,18 @@ boost::statechart::result PG::RecoveryState::Active::react(const AdvMap& advmap)
          lderr(pg->cct) << __func__ << " purged_snaps does not contain "
                         << rm << ", only " << overlap << dendl;
          pg->info.purged_snaps.subtract(overlap);
-         bad = true;
+         // This can currently happen in the normal (if unlikely) course of
+         // events.  Because adding snaps to purged_snaps does not increase
+         // the pg version or add a pg log entry, we don't reliably propagate
+         // purged_snaps additions to other OSDs.
+         // One example:
+         //  - purge S
+         //  - primary and replicas update purged_snaps
+         //  - no object updates
+         //  - pg mapping changes, new primary on different node
+         //  - new primary pg version == eversion_t(), so info is not
+         //    propagated.
+         //bad = true;
        } else {
          pg->info.purged_snaps.erase(k.first, k.second);
        }