We add in the new snap_seq just to try to keep the interval_set
contiguous.

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

In reality we only call this when the PG is peered and thus past_intervals
is empty, but this is more defensive in case that changes someday!

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

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

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

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

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

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

No users.

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

pg_pool_t's snap_seq is an upper bound on any allocated (or removed)
snapids.

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

This ensures we don't have any cruft left over in fields that decode()
assumes are initialized from the ctor (and not a previous instance).

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

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

Instead of maintaining a set of snapids that have been removed over
all time, instead note just the newly removed and newly purged snaps
in each OSDMap epoch.  This is easier to consume for both the Objecter
and OSD.

Also keep the interval of snaps that have been removed but not perged
in each OSDMap.  This is extremely convenient because it frees the OSDs
from having to maintain this information in parallel even when they may
not have PGs belonging to those pools.  These structures will be large
right when the ugprade happens and the pg_pool_t::removed_snaps gets copied
to the new fields, but in the steady state it will be relatively small,
reflecting only the set of snaps that are currently being removed.

This also provides convenient visibility into the "trimming snaps" set
that the cluster is working on.

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

Index by snap and by epoch; separate out pools.

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

If a client requests a map older than the mon's oldest, share with
them snaps deleted during the gap too.

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

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

If an in-flight Op has a snapc referencing a deleted snap, remove it
from the snapc.

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

This is what the caller is passing.

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

If we are so laggy that we aren't contiguous with the mon's latest
map, the mon will provide a summary of removed_snaps for the gap.
Apply those to our in-flight ops.

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

Now

 ceph osd {set,unset} nosnaptrim

will suspend or resume snap trimming.

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

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

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

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

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

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

If we are about to lose our primary status, we don't want to do *any*
of this stuff... especially share_pg_info(), which would get tagged with
the current epoch but confuse our peers!

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

This dependency on the ondisk version dates back before argonaut, and no
longer makes sense.  Once the snap is trimmed by the primary, and
purged_snaps is updated, the replica can (must!) blindly follow suit.

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

- update snap_trimq and purged_snaps based on new mimic OSDMap fields
- improve debug output to include both trimq and purged

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

Explicitly track whether we are a pool snaps pool or a selfmanaged
snaps pool.  This was inferred from removed_snaps.empty() before, but
that was fragile and kludgey and removed_snaps is going away.

The upgrade/compat behavior is a bit tricky:

- on decode, we set the flags based on the legacy condition.  This lets us
use and rely on the flags in memory.
- on encode, we exclude the flags if decoding an older pg_pool_t

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

On the first mimic map, consider previously removed_snaps to be removed
in that epoch (since we don't easily know when it happened).

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

Be a bit careful here because the mon has to do some bookkeeping to avoid
pruning things twice.  If the PGMapDigest set appears obviously stale,
skip some work (looking at this particular interval) until it is not
obviously stale--move onto the next interval instead.

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

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

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>