From 8c44dabe4b26bb2df77145f1b2227c87087f315e Mon Sep 17 00:00:00 2001 From: Sage Weil Date: Sat, 2 Dec 2017 10:40:20 -0600 Subject: [PATCH] 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 --- src/osd/PG.cc | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/osd/PG.cc b/src/osd/PG.cc index a2cfc99cecdf8..dd791e5b3af4c 100644 --- 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); } -- 2.39.5