osd: unlock sdata_op_ordering_lock with sdata_lock hold to avoid miss…
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: xie xingguo <xie.xingguo@zte.com.cn>
Fixes The Coverity Scan Report:
CID 1412577 (#1 of 1): Division or modulo by float zero (DIVIDE_BY_ZERO)
35. divide_by_zero: In expression (float)mk / k, division by expression k which may be zero has undefined behavior.
Signed-off-by: Jos Collin <jcollin@redhat.com>
9164804416 introduced a build error:
ceph-common-12.1.0+git.1498286248.2fcedc7b3d-1.1.x86_64.rpm: directories not
owned by a package:
- /usr/share/doc/packages/ceph
The %docdir directive is a way of flagging anything in that directory as being
documentation. It does not actually package the directory. And we don't need
it because we're not dumping a large number of files into this directory.
For more information, see the "Directory-related Directives" section of
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
Signed-off-by: Nathan Cutler <ncutler@suse.com>
This reverts 693bd23851, which was
added in response to http://tracker.ceph.com/issues/18126. But
we updated the Ubuntu packages in sepia so it should be good to go.
Signed-off-by: Greg Farnum <gfarnum@redhat.com>
We are running mysql on top of rbd. sysbench qps occasionally drops to zero
with the INSERT benchmark.
Debug code captured >2s latency between PG::queue_op() and OSD::dequeue_op().
We finally found out that the latency came from below code in OSD::ShardedOpWQ::_process(),
sdata->sdata_cond.WaitInterval(sdata->sdata_lock,
utime_t(osd->cct->_conf->threadpool_empty_queue_max_wait, 0));
"threadpool_empty_queue_max_wait" is 2s by default.
Normally, it should not sleep for 2s since the comming IO requests will wakeup it.
But there is a small timing window that it missed the wakeup signal actually.
For example,
msgr-worker-0 thread tp_osd_tp thread
OSD::ShardedOpWQ::_enqueue OSD::ShardedOpWQ::_process
--------------------------- ---------------------------
T1: sdata_op_ordering_lock.Lock()
T2: sdata_op_ordering_lock.Lock()
"queue empty"
sdata_op_ordering_lock.Unlock()
"insert op"
sdata_op_ordering_lock.Unlock()
T3: sdata_lock.Lock()
T4: sdata_lock.Lock()
"send wakeup signal"
sdata_lock.Unock()
// here the wakeup signal has no effect actually
// becuase it has not slept yet.
// then, it sleeps.
WaitInterval(2s)
This patch unlocks sdata_op_ordering_lock with sdata_lock hold in OSD::ShardedOpWQ::_process(),
then the timeline becomes,
msgr-worker-0 thread tp_osd_tp thread
OSD::ShardedOpWQ::_enqueue OSD::ShardedOpWQ::_process
--------------------------- ---------------------------
T1: sdata_op_ordering_lock.Lock()
T2: sdata_op_ordering_lock.Lock()
"queue empty"
sdata_lock.Lock()
T3: sdata_op_ordering_lock.Unlock()
"insert op"
sdata_op_ordering_lock.Unlock()
sdata_lock.Lock()
T4: WaitInterval(2s) -> it actually unlocks sdata_lock
"send wakeup signal"
sdata_lock.Unock()
//got signal, wakeup immediately
With this one line change, we can avoid occasional high latency.
Signed-off-by: Ming Lin <ming.lin@alibaba-inc.com>
mds may try discover several times for MDirUpdate, rename may kick
in and cause MDCache::path_traverse() to return error.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
MDCache::eval_subtree_root() may tigger scatter-gather process, which
submits log entry. Submitting log entry while adjusting subtree map is
bad, because subtree map in intermediate state may get used/logged.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
When a directory tree become frozen, its WAIT_FROZEN contexts are
executed asynchronously. Before Migrator::export_frozen() set export
bounds, MDCache::try_subtree_merge_at() can merge newly imported
subtree into the frozen directory tree. This causes problem if there
are auth pins in newly imported subtree.
The fix is creating subtree root immediately after directory tree
becomes frozen. The new subtree root has dir_auth 'me, me', so it's
not meregeable.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
