The scrubber's state-machine changes states only following a message dispatched
via the OSD queue. That creates some vulnerability periods, from when the
decision to change the state is made, till when the message carrying the event
is dequeued and processed by the state-machine.
One of the problems thus created is a second scrub being started on a PG, before
the previous scrub is fully terminated and cleaned up.
Here we add a 'being-scrubbed' flag, that is asserted when the first scrub
initiation message is queued and is only cleared when the state machine reaches
Inactive state after the scrub is done.
To note: scrub_finish() is now part of the FSM transition from WaitDigest to Inactive,
closing this specific vulnerability period;
Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
doc/radosgw/nfs: add note about NFSv3 deprecation
Reviewed-by: Matt Benjamin <mbenjamin@redhat.com>
Reviewed-by: Sage Weil <sage@newdream.net>
Reviewed-by: Varsha Rao <rvarsha016@gmail.com>
This was supposed to be fixed a year ago in commit
2e3643647b, but it set compat_v to 4 instead of all
the way back to 1 as it should have.
Our testing for stretch mode in these areas is just not very thorough -- the
kernel only supports compat_v 1 and apparently nobody's noticed the issue
since then? :/
As the prior commit says, you can't set locations without being gated on a
server feature bit, so simply cancelling this enforcement is completely safe.
Fixes: https://tracker.ceph.com/issues/53237
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
whenever an index transaction uses remove_objs for complete(), it also
needs to pass them for cancel() to avoid leaking index entries
Signed-off-by: Casey Bodley <cbodley@redhat.com>
when multipart uploads complete their final bucket index transaction,
they pass the list of part objects in 'remove_objs' for bulk removal -
the part objects, along with their bucket stats, get replaced by the
head object
but if CompleteMultipart races with another upload, the head object
write will fail with ECANCELED and the bucket index transaction gets
canceled with CLS_RGW_OP_CANCEL. these canceled uploads still need to
clean up their 'remove_objs', but cancelation was returning too early.
as a result, these bucket index entries get orphaned and leave the
bucket stats inconsistent
this commit reworks rgw_bucket_complete_op() so that CLS_RGW_OP_CANCEL
is handled the same way as OP_ADD and OP_DEL, so always runs the loop to
clean up 'remove_objs'
Fixes: https://tracker.ceph.com/issues/53199
Signed-off-by: Casey Bodley <cbodley@redhat.com>
* refs/pull/43894/head:
qa/suites/orch/cephadm: verify that 'orch ls' reports OSDs properly
mgr/cephadm: show unmanaged OSDs under 'osd' service
Reviewed-by: Sebastian Wagner <sewagner@redhat.com>
fixes all S3 operations failing with:
`2021-11-15T15:46:05.992+0000 7ffee17fa700 20 failed to read header: Bad file descriptor`
when `--rgw_frontends="beast port=8000 request_timeout_ms=0"`
Signed-off-by: Mark Kogan <mkogan@redhat.com>
For non-ceph daemons, (1) they don't log to /var/log/ceph, and (2) the
container image isn't a ceph image, which means the uid/gid extraction
won't have the correct uid/gid and we'll end up with a log directory that
ceph daemons no longer have write permissions for.
Fixes: https://tracker.ceph.com/issues/53257
Signed-off-by: Sage Weil <sage@newdream.net>
This commit changes the FuturizedStore::create() function to return a
seastar::future containing its original return value.
Signed-off-by: Joseph Sawaya <jsawaya@redhat.com>
PR #42727 introduced a regression in `ceph-volume raw activate`
since it dropped `nargs='+'` from the argument `--device`, the variable
is no longer a list but a string.
Signed-off-by: Guillaume Abrioux <gabrioux@redhat.com>
Correct the size of `protection` field. This bug is harmless since Export/Import writes/reads
one byte for `protected` field regardless of `length` field. So the current wrong diff works
correctly by chance
Fixes: https://tracker.ceph.com/issues/53243
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
librbd/cache/pwl/ssd: make log entry 64 bit and add ssd version control
Reviewed-by: Mykola Golub <mykola.golub@clyso.com>
Reviewed-by: Deepika Upadhyay <dupadhya@redhat.com>
The calls to remove a bucket had parameters to specify a prefix and
delimiter, which does not make sense. This was precipitated due to some
existing Swift protocol logic, but buckets are removed irrespective of
prefix and delimiter. So the functions and calls are adjusted to
remove those parameters. Additionally, those same parameters were
removed for aborting incomplete multipart uploads.
Additionally a bug is fixed in which during bucket removal, multipart
uploads were only removed if the prefix was non-empty.
Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
In c59a6f8946, I erroneously changed
the CLI display output so it would only dump disallowed_leaders in
stretch mode. But they can also be set in connectivity or disallow
election modes and we want users to be able to see them then as well.
Fixes: https://tracker.ceph.com/issues/53258
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
Make osd-scrub-dump test ignore the 'scrubbing' that might be late to disappear
from the modified (PR #43403) 'pg dump' output.
Signed-off-by: Ronen Friedman <rfriedma@redhat.com>
While __PRETTY_FUNCTION__ includes more information, it can clutter
the logs. So this reverts some uses of __PRETTY_FUNCTION__ back to
__func__.
I'm thinking that a strategy going forward is for the function entry
logging to use __PRETTY_FUNCTION__ to disambiguate overloaded
functions, but all others in the function simply to use __func__.
Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
During debugging it can be useful to see all the contents of
rgw::sal::Bucket::ListParams. This allows the structure to be dumped
to an output stream in human-readable format.
Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
When `radosgw-admin bi put` adds an entry for an incomplete multipart
upload, the bucket index shard is not calculated correctly. It should
be based on the name of the ultimate object. However the calculation
was including the added organizational suffixes as well. This corrects
that.
NOTE: When entries are not put in the correct index shard, unordered
listing becomes unreliable, perhaps causing entries to be skipped or
infinite loops to form.
Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
