Problem caught test_migration_on_shutdown. Migration could not proceed because
export_targets were not being updated.
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Remove the OpSequencer from the deferred_queue before
marking the txc's completed. This prevents a race with
_txc_finish trying to reap the completed sequencer that
is still on the deferred_queue, triggering an assert
in the intrusive list hook dtor.
Fixes: http://tracker.ceph.com/issues/19880
Signed-off-by: Sage Weil <sage@redhat.com>
cherrypy.engine.stop() doesn't actually completely kill cherrypy,
which means cherrypy.engine.block() never returns, so this module's
thread never completes cleanly.
Signed-off-by: Tim Serong <tserong@suse.com>
osd: sched_scrub() lock pg only if all scrubbing conditions are fulfilled
Reviewed-by: Kefu Chai <kchai@redhat.com>
Reviewed-by: Pan Liu <liupan1111@gmail.com>
The base case for the past_intervals bounds is the creation epoch for the
pool, not the PG. Otherwise, a pool that is created, does not go active,
and then splits will not include the pre-split history. For example,
- pg A is created in epoch X
- pg A does not go active
- pg A splits into pg B in epoch Y
but then,
- pg B has past intervals from [X,Y)
- pg B epoch_created is Y ***
- pg B required past intervals is [Y,Y)
- fails check_past_interval_bounds check
Fixes: http://tracker.ceph.com/issues/19877
Signed-off-by: Sage Weil <sage@redhat.com>
The epoch_created property is the *pg* creation epoch; we want to know the
pool creation epoch too. Unfortunately that is not part of the pg_pool_t.
Add a pg_history_t member that sits alongside epoch_created.
Signed-off-by: Sage Weil <sage@redhat.com>
Also catches corner-case found by Zheng where an unjournaled directory will
cause export pinning to fail because it cannot be made a subtree until its
parent is stable.
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Wow, this has been broken since v0.38, but apparently
the message never made it into the object corpus so
we never noticed!
In reality the bug is harmless: decode_message() will
set_header which clobbers whatever version the default
ctor fills in, so this only affects ceph-dencoder's
test.
Signed-off-by: Sage Weil <sage@redhat.com>
list_plain_entries() was using encode_obj_versioned_data_key() to set
its end_key, which gives a prefix of BI_BUCKET_OBJ_INSTANCE_INDEX[=2]
that range between start_key and end_key would not only span the
BI_BUCKET_OBJS_INDEX[=0] prefixes, but BI_BUCKET_LOG_INDEX[=1] prefixes
as well. this can result in list_plain_entries() trying and failing to
decode a rgw_bi_log_entry as a rgw_bucket_dir_entry
Fixes: http://tracker.ceph.com/issues/19876
Signed-off-by: Casey Bodley <cbodley@redhat.com>
This works out of the box with a vstart environment and
RGW=1 ../src/vstart.sh -n -l
PATH=bin:$PATH ../qa/workunits/rgw/run-s3tests.sh
Signed-off-by: Sage Weil <sage@redhat.com>
If we are a syncrhonous read, we don't need this: we don't aio_wait for
sync reads. If we are an aio_read, we are in the aio_running count anyway,
and there is also no purpose for this counter.
I'm a bit unsure about the NVME use of this counter; I switched it to use
num_running (pretty sure we aren't mixing reads and writes on a single
IOContext) *but* it might make more sense to switch to a private counter.
Signed-off-by: Sage Weil <sage@redhat.com>
