Handle the case that kernel does not support fcntl.F_OFD_SETLK.
Also fix the code that checks if fnctl fails with errno == EINTR.
Fixes: 11205
Signed-off-by: Yan, Zheng <zyan@redhat.com>
(cherry picked from commit 4ececa3dc4a21b98f61a592da9e2be60a0d71625)
Otherwise, we might attempt to promote into an in-progress scrub
interval causing 11156. I would have added a return value to
promote_object(), but could not find an existing user which
cared to distinguish the cases, even with a null op passed.
All existing users are in maybe_handle_cache. The ones which
pass a null op are for promoting the object in parallel
with a proxy -- a case where not actually performing the promote
does not really matter.
Fixes: #11156
Signed-off-by: Samuel Just <sjust@redhat.com>
Currently, this method also returns true if the object is backfilling.
This commit was reverted earlier in the branch in order to make the
other reverts clean. It's actually a nice rename though, so I'm
re-cherry-picking it.
Signed-off-by: Samuel Just <sjust@redhat.com>
Conflicts:
src/osd/ReplicatedPG.cc
Fixes: #10907
Backport: firefly
Pass any configurables in the rgw frontends config line to civetweb.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 986d7554426764a149621ba733c5c075b94e0431)
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 6823bcdcd0ce72cd223e809291f46d82da76115c)
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>
