`uint` is not available in musl. so this change should address the FTBFS
on distros, like Alpine and Gentoo Linux, which uses musl-libc.
Signed-off-by: Kefu Chai <kchai@redhat.com>
We do not want to hold osd_lock while calling apply_transaction or else
we may cause a deadlock due to a completion event that needs osd_lock.
Also, we don't need to hold the lock here, so don't.
Signed-off-by: Sage Weil <sage@redhat.com>
With randomization.
We do this from tick() for simplicity. It is a rare event, will take 10s
of seconds at most, and nothing else particularly time-sensitive is
happening from tick().
Signed-off-by: Sage Weil <sage@redhat.com>
If 'begin' isn't found, we'll get a [pbegin,pend) range back that was
nearby. Only if it overlaps the [begin,end) range do we want to shorten
our range to [begin,pbegin); the old assert was making the assumption
that the lookup would only return a range that was after 'begin', but in
reality it can return was that comes before it too.
Signed-off-by: Sage Weil <sage@redhat.com>
When we delete a selfmanaged snap we have to bump seq. Record this as
purged so that we avoid discontinuities in the history and so our storage
is a bit more efficient.
Signed-off-by: Sage Weil <sage@redhat.com>
This was an attempt to ensure that we didn't let removed_snaps slip by
when we had a discontiguous stream of OSDMaps. In octopus, this can still
happen, but it's mostly harmless--the OSDs will periodically scrub to
clean up any resulting stray clones. It's not worth the complexity.
Signed-off-by: Sage Weil <sage@redhat.com>
This a naive one-shot implementation that does the full scan synchronously
in the command thread. It shouldn't block any IO except to the extent
that it will compete for IO reading the underlying snapmapper omap object.
When we discover mapped objects that are covered by ranges of snaps that
should be purged, we requeue the snapid for trim on the relevant PG(s).
For these 'repeat' trims we skip the final step(s) to mark the snapid as
purged, since that presumably already happened some time ago.
Signed-off-by: Sage Weil <sage@redhat.com>
The test creates a snap, removes it, waits for it to (hopefully) purge,
and then uses that snapid in a snapc to generate a clone.
This isn't a complete test because (1) it doesn't wait for the purge to
happen (e.g., by watching the osdmaps go by), and (2) it doesn't trigger
an osd scrub_purged_snaps afterwards.
Signed-off-by: Sage Weil <sage@redhat.com>
This path only triggers after an upgrade or osd creation, when
purged_snaps_last < current_epoch. When that happens, we slurp down the
old purged snaps so that we have a full history recorded locally.
Signed-off-by: Sage Weil <sage@redhat.com>
When we get a new map, record the (new) purged_snaps.
Only do this if the OSD has purged_snaps that are in sync with the latest
OSDMap. That means that after an upgrade, if the OSD didn't sync the
old purged_snaps on startup, it won't sync anything until it *next* starts
up.
Signed-off-by: Sage Weil <sage@redhat.com>
When we public our first require_osd_release >= octopus osdmap, record
all prior purged snaps in a key linked to the previous osdmap. We assume
this will encode and fit into a single key and transaction because the
even larger set of removed_snaps is already a member of pg_pool_t, which
is included in every osdmap.
Signed-off-by: Sage Weil <sage@redhat.com>
Only do this if the mons are all running octopus (and thus there is also
a record for all the pre-octopus purged snaps).
Signed-off-by: Sage Weil <sage@redhat.com>
- look at purged, not removed snap keys
- fix the key check to look at the *key name* prefix, not the overall
prefix (the one implemented by the KeyValueDB interface).
Signed-off-by: Sage Weil <sage@redhat.com>
Convert snapmapper keys to the new form the first time we start up running
octopus.
This is an incompat feature--once you start as octopus you can't go back.
Signed-off-by: Sage Weil <sage@redhat.com>
We want to sort starting with (pool, snapid, ...) so that we align with
the structure of the purged_snaps. Simply flattening all snaps across
pools is less than ideal because the purge records are intervals (with the
snap in the key the last snap for the interval); flattening means we'd have
to look at many records (across pools) to conclude anything. Putting
these in the form we really want them simplifies things going forward.
Signed-off-by: Sage Weil <sage@redhat.com>
