We would like to eliminate `safe=false` parameter in opt.set_val. ms_dpdk_gateway_ipv4_addr
is modified in runtime. We convert it to SAFE_OPTION to eliminate `safe=fales` and
guard thread safity.
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
ms_dpdk_host_ipv4_addr is modified in src/test/msgr/test_async_networkstack.cc,
It's better to use SAFE_OPTION.
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
ms_dpdk_coremask is modified in test/msgr/test_async_networkstack.cc. It's better
to declare SAFE_OPTION.
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
We need to modify ms_type in unittest. That use SAFE_OPTION to declare ms_type
is safer than pass `safe=false` to set_val.
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
We need to change `rocksdb_db_paths` in runtime. pass safe=false to set_val is not
a good behavior. We should use SAFE_OPTION.
Signed-off-by: liuchang0812 <liuchang0812@gmail.com>
Currently dump_historic_ops dumps ops sorted by their initiation time,
which may not have any relation to how long it took, and sorting output
of that command by op duration is neither fast nor convenient.
New asok command ("dump_historic_ops_by_duration") outputs the same
op list, but ordered by their duration time (longest first).
Signed-off-by: Piotr Dałek <piotr.dalek@corp.ovh.com>
When get_partition_dev() fails, it reports the following message :
ceph_disk.main.Error: Error: partition 2 for /dev/sdb does not appear to exist
The code search for a directory inside the /sys/block/get_dev_name(os.path.realpath(dev)).
The issue here is the error message doesn't report that path when failing while it might be involved in.
This patch is about reporting where the code was looking at when trying to estimate if the partition was available.
Signed-off-by: Erwan Velu <erwan@redhat.com>
The daemons report this in a particular order; match that in the
daemonperf output. This corresponds to the numeric value of the l_*
enum.
Signed-off-by: Sage Weil <sage@redhat.com>
It's possible for the Sequencer to go away while the OpSequencer still has
txcs in flight. We were handling the case where the osr was on the
deferred_queue, but it may be off the deferred_queue but waiting for the
commit to happen, and we still need to wait for that.
Fix this by introducing a 'zombie' state for the osr, in which we keep the
osr in the osr_set.
Clean up the OpSequencer methods and a few other method names.
Signed-off-by: Sage Weil <sage@redhat.com>
We've been avoiding doing this for a while and it has finally caught up
with us: the SharedBlob may outlive the split due to deferred IO, and
a read on the child collection may load a competing Blob and SharedBlob
and read from the on-disk blocks that haven't been written yet.
Fix by preserving the one-SharedBlob-instance invariant by moving cache
items to the new Collection and cache shard like we should have from the
beginning.
Signed-off-by: Sage Weil <sage@redhat.com>
We can't use a bare Collection since we get/put refs, the last put will
delete it, and the dtor asserts nref == 0 (no faking a ref and deliberately
leaking!).
Signed-off-by: Sage Weil <sage@redhat.com>
Otherwise cache items survive beyond umount into the next mount cycle!
Also, ensure that we flush_cache *before* clearing coll_map, as some cache
items have references back to the Collection.
Signed-off-by: Sage Weil <sage@redhat.com>
These can survive as long as the txc, which can be longer than the
Collection. Make sure we have a valid ref as both finish_write and
~SharedBlob use coll for the SharedBlobSet (and coll->store->cct for
debug).
Signed-off-by: Sage Weil <sage@redhat.com>
We were modifying bufferlists in place, and kludging around it by making
full copies elsewhere. Instead, never modify a buffer.
This fixes issues where the buffer we submit to ObjectStore ends up in
the cache and we modify in place later, corrupting the implementation's
copy. (This was affecting BlueStore.)
Rearrange the data methods to be next to each other and clean them up a
bit too.
Signed-off-by: Sage Weil <sage@redhat.com>
If we have no non-deferred IO to flush, and we are running bluefs on a
single shared device, then we can rely on the bluefs flush to make our
current batch of deferred ios stable.
Separate deferred into a "done" and "stable" list. If we do sync, put
everything from "done" onto "stable". Otherwise, after we do our kv
commit via bluefs, move "done" to "stable" then.
Signed-off-by: Sage Weil <sage@redhat.com>
When the Sequencer goes away it get deregistered. If there are still
deferred IOs in flight, we need to wait for those too.
Signed-off-by: Sage Weil <sage@redhat.com>
Allow several deferred writes to accumulate before we submit them. In
general we have no time pressure, and on HDD (and perhaps sometimes SSD)
it is beneficial to accumulate and batch these so that they result in
fewer seeks. On HDD, this is particularly true of seeks away from the
journal. And on sequential workloads this can avoid seeks. In may even
allow the block layer or SSD firmware to merge IOs and perform fewer
writes.
Signed-off-by: Sage Weil <sage@redhat.com>
If a blob is shared, we can't discard deallocated regions: there may
be deferred buffers in flight and we might get a read via the clone.
Signed-off-by: Sage Weil <sage@redhat.com>
In a simple HDD workload with queue depth of 1, we halve our throughput
because the kv thread does a full commit twice per IO: once for the
initial commit, and then again to clean up the deferred write record. The
second wakeup is unnecessary; we can clean it up on the next commit.
We do need to do this wakeup in a few cases, though, when draining the
OpSequencers: (1) on replay during startup, and (2) on shutdown in
_osr_drain_all().
Send everything through _osr_drain_all() for simplicity.
This doubles HDD qd=1 IOPS from ~50 to ~100 on my 7200 rpm test device
(rados bench 30 write -b 4096 -t 1).
Signed-off-by: Sage Weil <sage@redhat.com>
First, eliminate the work queue--it's useless. We are dispatching aio and
should not block. And if a single thread isn't sufficient to do it, it
probably means we should be parallelizing kv_sync_thread too (which is our
only caller that matters).
Repurpose the old osr-list -> txc-list-per-osr queue structure to manage
the queuing. For any given osr, dispatch one batch of aios at a time,
taking care to collapse any overwrites so that the latest write wins.
Signed-off-by: Sage Weil <sage@redhat.com>
Make osr_set refcounts so that it can tolerate a Sequencer destruction
racing with flush or a Sequencer that outlives the BlueStore instance
itself.
Signed-off-by: Sage Weil <sage@redhat.com>
