If we have a mixed cluster of hammer and pre-hammer OSDs, we will fall back
to using 0 as the initial crc32c value. However, if the primary has a
stored digest, it currently compares its value to the reported value (w/
the wrong initial value) and complains.
There are two possible fixes:
- avoid storing a digest if all peers don't support it, or
- avoid complaining on scrub if all peers don't support it.
The latter is easier, and this fix also has the benefit of fixing the bug
even for clusters where this has already happened.
Fixes: #11102
Signed-off-by: Sage Weil <sage@redhat.com>
Fixes: #11159
Backport: hammer, firefly
Scripts required rgw_socket_path to exist in order to start radosgw.
This is not needed.
Reported-by: Dan Mick <dmick@redhat.com>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 6823bcdcd0)
Otherwise, we might remember the write, but not that the activation
interval was history.last_epoch_started.
Signed-off-by: Samuel Just <sjust@redhat.com>
It is possible for an incremental change to have both a rm and a set for
a given erasure code profile. It only happens when a rm is followed by a
set. When a set is followed by a rm, the rm will remove the pending set
in the incremental change.
The logic is the same for pool create and pool delete.
We must apply the incremental erasure-code-profile removal before the
creation otherwise rm and set in the same proposal will ignore the set.
This fix is minimal. A better change would be that erasure-code-profile
set checks if there is a pending removal and wait_for_finished_proposal
before creating.
http://tracker.ceph.com/issues/11144Fixes: #11144
Signed-off-by: Loic Dachary <ldachary@redhat.com>
When erasure-code-profile set refuses to override an existing profile,
it may be non trivial to figure out why. For instance:
ceph osd set default ruleset-failure-domain=host
fails with:
Error EPERM: will not override erasure code profile default
although ruleset-failure-domain=host is documented to be the
default. The error message now includes the two profiles that have been
compared to not be equal so that the user can verify the difference.
Error EPERM: will not override erasure code profile default
because the existing profile
{directory=.libs,k=2,m=1,plugin=jerasure,technique=reed_sol_van}
is different from the proposed profile
{directory=.libs,k=2,m=1,plugin=jerasure,ruleset-failure-domain=host,technique=reed_sol_van}
http://tracker.ceph.com/issues/10488Fixes: #10488
Signed-off-by: Loic Dachary <ldachary@redhat.com>
This profile is allowed to create client.rgw.* librados users. They have
access to any pool, which is pretty coarse.
Signed-off-by: Sage Weil <sage@redhat.com>
The current blanket check in prepare_transaction() will trigger only when
there is a net obs.exists change from the commited obs to new_obs.
However, this misses the case where the first osd_op is a delete and then a
subsequent osd_op recreates the object. Changing the whiteout check to
look only at new_obs does not work because it fails to understand when
_delete_oid sets the whiteout and will simply clear it again.
In order to support sequences of delete + create in general, we need to do
the whiteout flag clearing when the actual create happens (to match the
fact that we set it when we process the delete osd_op). Use a helper to
do this and consolidate most other obs.exists = true code to use it.
Backport: giant, firefly
Signed-off-by: Sage Weil <sage@redhat.com>
Even if the tail != last_update, the log might be empty due to split
moving all entries into other logs.
Fixes: 10718
Signed-off-by: Samuel Just <sjust@redhat.com>
This triggers #11123, originally observed when rgw does a delete + create
sequence in a single op and the whiteout gets left behind.
Signed-off-by: Sage Weil <sage@redhat.com>
Deep scrub does not actually give us the whole-object checksum for an ec
object, only the checksum for the first shard. We ignore it in scrub
for ec pools anyway in be_select_auth_object.
Signed-off-by: Samuel Just <sjust@redhat.com>
merge-diff and status commands, --image-features and --image-shared
options, other stuff.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 356a749f63)
Instead of setting the HEAD image flag to indicate an invalid
object map, set the flag for the specific snapshot that is
invalid.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
It's possible for an object map to be invalid only for
a snapshot, so allow snapshot flags to be updated. This
will also be required when rebuilding the object map and
clearing the invalid flag.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
