Greg was right!
When a pool is created, the PGs are not added to the PGMap until the *next*
proposal. Weaken the assert here and return empty stats for non-existent
(new) pools so that a pool create + tier add sequence does not crash.
Signed-off-by: Sage Weil <sage@inktank.com>
Currently, running "make check" nukes any existing vstart
setup in the tree. This change makes it use test_dev/ and test_out/
so that it can peacefully coexist.
Signed-off-by: John Spray <john.spray@inktank.com>
Commit a7e9a7b648 changed the JSON format of CRUSH rules
such that the 'item' attribute on a step was sometimes
an integer and sometimes a string.
This commit separates the integer and string representations
so that tools which rely on a 'item' consistently being an
integer ID will work.
Signed-off-by: John Spray <john.spray@inktank.com>
cursor.omap_offet indicates the most recently recovered key, we continue
filling in at the smallest key k | k > cursor.omap_offset. If the loop
as written terminates due to !(left > 0), iter points at the next key to
copy, rather than the last key copied, resulting in the next copy
operation skipping that key.
Now, iter, if valid, must point to the last key copied once the loop has
completed since we check left <= 0 prior to advancing iter. We can
therefore use it to fill in cursor.omap_offset.
Signed-off-by: Samuel Just <sam.just@inktank.com>
This is not a leak: we are in an else block where cb must
be NULL. The fix as introduced did not include braces on
the if causing the method to return unconditionally.
Fixes: #7604
Introduced in: 500206d809
Reviewed-by: David Zafman <david.zafman@inktank.com>
Signed-off-by: Samuel Just <sam.just@inktank.com>
We always send the transaction for operations on temp objects,
but if we didn't get the final transacition on the actual object,
we might end up failing to remove the temp object. Thus, if
we get a sub op and don't have the transaction, just remove the
named temp objects.
Fixes: #7447
Signed-off-by: Samuel Just <sam.just@inktank.com>
This is a friendlier interface for setting up a cache tier with some
reasonable defaults (defined via config options). This will simplify
the user experience and documentation.
Signed-off-by: Sage Weil <sage@inktank.com>
If you have two racing requests to add two different pools as a tier, the
committed checks will pass but they proposals will conflict. Recheck the
pending pools for the same conditions and wait for a commit if they
occur.
Reported-by: Loic Dachary <loic@dachary.org>
Signed-off-by: Sage Weil <sage@inktank.com>
In general, users should not use non-empty pools as new tiers or else
things can behave strangely:
- the data sets are unrelated behavior will be... strange.
- if the cache pool is not "new" and does not do the OMAP flag, the OSD
will not know not to flush omap objects to an EC base tier
- probably other random stuff I'm forgetting
Allow a user to shoot themselves in the foot with --force-nonempty.
Implements: #7457
Signed-off-by: Sage Weil <sage@inktank.com>
We need the merge_log and proc_replica_log paths to result in the
same missing set. This patch adds some machinery for specifying
a log merge scenario and comparing both paths to the same correct
result. This machinery also makes it a bit easier to read and add
new tests.
Signed-off-by: Samuel Just <sam.just@inktank.com>
This test didn't quite make sense since the divergent entry
cannot be from a newer epoch. It also didn't quite match the
diagram.
Signed-off-by: Samuel Just <sam.just@inktank.com>
We can't merge using the primary's log since we haven't decided whether
to send them a complete log yet. Thus, merge based on the truncated olog
rather than the primary's log. This is a consequence of the division
between trimming divergent entries in peering/unfound search and sending
a complete log to actual members of the actingbackfill set in activate().
_merge_divergent_entries on the truncated log and add_next_event() on the
newer entries result in the same missing/log regardless of the order in
which they are performed.
Signed-off-by: Samuel Just <sam.just@inktank.com>
The _merge_old_entry structure had trouble distinguishing between the
following cases:
missing: foo, 1,1
merge_old_entry modify 1,1 0,0
merge_old_entry modify 1,2 1,1
and
merge_old_entry modify 1,2 1,1
In the first case, we should end up with foo removed from missing
at the end. In the second, we need foo added to missing at 1,1.
It's far simpler to present all of the divergent entries for a single
object at once.
Signed-off-by: Samuel Just <sam.just@inktank.com>