large zero object has a large compression rate,
even 4M compressed data can decompress several GB data.
Handle so much data in single process lead strange issue.
Fixes: http://tracker.ceph.com/issues/20098
Signed-off-by: fang yuxiang fang.yuxiang@eisoo.com
* silence clang analyzer's warning of: "Value stored to 'r' is never
read"
* replace the "goto" statement with early return to improve the
readability
Signed-off-by: Kefu Chai <kchai@redhat.com>
* silence the warning of: Value stored to 'r' is never read
* update the gtest assertions to be semantically more correct.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The ".." form only works within the teuthology repo. With swift.py now in the
Ceph repo, we have to be explicit.
Error message was: "ValueError: Attempted relative import beyond toplevel
package
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Fixes the Coverity Scan Report:
CID 1411820 (#1 of 1): Division or modulo by zero (DIVIDE_BY_ZERO)
9. divide_by_zero: In expression bl.length() * i / sum, division by expression sum which may be zero has undefined behavior.
Signed-off-by: Jos Collin <jcollin@redhat.com>
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>
If the underlying disk is missing, the current logic won't check the actual
reason why Get/Set failed, it will result to client get a empty key/value
pair which is not expected. The correct logic should be abort
right now. Otherwise, it will leads to undefined behavior.
Signed-off-by: Haomai Wang <haomai@xsky.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>
Fixes the Coverity Scan Report:
CID 1412614 (#2-1 of 2): Uninitialized scalar field (UNINIT_CTOR)
7. uninit_member: Non-static class member m_do_resync is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Jos Collin <jcollin@redhat.com>
