osd: initialize purged_snap on backfill start; restart backfill if change

If we backfill a PG to a new OSD, we currently neglect to initialize
purged_snaps.  As a result, the first time the snaptrimmer runs it has to
churn through every deleted snap for all time, and to make matters worse
does so in one go with the PG lock held.  This leads to badness on any
cluster with a significant number of removed snaps that experiences
backfill.

Resolve this by initializing purged_snaps when we finish backfill.  The
backfill itself will clear out any stray snaps and ensure the object set
is in sync with purged_snaps.  Note that purged_snaps on the primary
that is driving backfill will not change during this period as the
snaptrimmer is not scheduled unless the PG is clean (which it won't be
during backfill).

If we by chance to interrupt backfill, go clean with other OSDs,
purge snaps, and then let this OSD rejoin, we will either restart
backfill (non-contiguous log) or the log will include the result of
the snap trim (the events that remove the trimmed snap).

Fixes: #9487
Backfill: firefly, dumpling
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 255b430a87201c7d0cf8f10a3c1e62cbe8dd2d93)

diff --git a/src/osd/PG.cc b/src/osd/PG.cc
index 6cabdb7eb0028a46a0ddc548000071af26c66577..ebc2020cfff2734cca82490b2d357ac45e164830 100644 (file)
--- a/src/osd/PG.cc
+++ b/src/osd/PG.cc
@@ -1553,6 +1553,9 @@ void PG::activate(ObjectStore::Transaction& t,
        pi.hit_set = info.hit_set;
        pi.stats.stats.clear();
 
+       // initialize peer with our purged_snaps.
+       pi.purged_snaps = info.purged_snaps;
+
        m = new MOSDPGLog(
          i->shard, pg_whoami.shard,
          get_osdmap()->get_epoch(), pi);