AioImageRequestWQ::_void_process() dequeues an item from the
work queue by invoking ThreadPool::_void_process() which also
performs accounting by incrementing ->m_processing which never
gets decremented if an image refresh fails. This is exactly
the flow when running test_lock_fence.sh which blacklists a
client and expects failed I/O operation from the client.
Without this fix, running test_lock_fence.sh in a loop fails
with an assert in PointerWQ dtor within 100 odd runs.
Fixes: http://tracker.ceph.com/issues/17973
Signed-off-by: Venky Shankar <vshankar@redhat.com>
- some options are only meaningful for C++, so move them into
CMAKE_CXX_FLAGS.
- regroup CMAKE_CXX_FLAGS and CMAKE_C_FLAGS, and remove the duplicated
options.
- do not reset CMAKE_CXX_FLAGS with ${CMAKE_C_FLAGS}, instead, always
append ${CMAKE_C_FLAGS} to existing ${CMAKE_CXX_FLAGS}. so we don't
clobber CMAKE_CXX_FLAGS set by command line.
Signed-off-by: Kefu Chai <kchai@redhat.com>
this silences warnings like:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
and recent clang (3.9 and 4.0) do not complain at seeing
so we only pass this this param to gcc.
Signed-off-by: Kefu Chai <kchai@redhat.com>
pick up latest gf-complete submodule
$ git log --no-merges --pretty=%s \
a6847973cba329ae079d3bd26341a4ec2906f012..c431e1ff76bdce6c3f6c0d0cbdf6a01c68f81071
gf_w32.c: silence the -Wmaybe-uninitialized warning
it silences following warning:
ceph/src/erasure-code/jerasure/gf-complete/src/gf_w32.c: In
function ‘gf_w32_cfmgk_multiply_region_from_single’:
ceph/src/erasure-code/jerasure/gf-complete/src/gf_w32.c:410:5:
warning: ‘a’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
g = _mm_insert_epi64 (a, g_star, 0);
^
Signed-off-by: Kefu Chai <kchai@redhat.com>
Do all math using bc so we can have fractions
Allow caller to specify the first step (default 1)
Add testing of fractional first step
Signed-off-by: David Zafman <dzafman@redhat.com>
this silences the warning of "Use of memory after it is freed" reported
by clang static analyzer.
Reported-by: Brad Hubbard <bhubbard@redhat.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
osd: set server-side limits on omap get operations
Reviewed-by: xie xingguo <xie.xingguo@zte.com.cn>
Reviewed-by: Kefu Chai <kchai@redhat.com>
Reviewed-by: Samuel Just <sjust@redhat.com>
osd: heartbeat peers need to be updated when a new OSD added into an existed cluster
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Haomai Wang <haomai@xsky.com>
If the host system has boost version 1.61 or higher (as in the case
for ubuntu 16.10 yakkety) the ceph build is currently broken. it
will pickup the system boost libraries but use the headers from the
submodule.
This commit ensure that when WITH_SYSTEM_BOOST is OFF we always
use the boost libraries and headers built from the submodule.
Signed-off-by: Bassam Tabbara <bassam.tabbara@quantum.com>
The udev rules that set the owner/group of the OSD devices are racing
with 50-udev-default.rules and depending on which udev event fires last,
ownership may not be as expected.
Since ceph-disk trigger --sync runs as root, always happens after
dm/lvm/filesystem units are complete and before activation, it is a good
time to set the ownership of the device.
It does not eliminate all races: a script running after systemd
local-fs.target and firing a udev event may create a situation where the
permissions of the device are temporarily reverted while the activation
is running.
Fixes: http://tracker.ceph.com/issues/17813
Signed-off-by: Loic Dachary <loic@dachary.org>
A ceph udev action may be triggered before the local file systems are
mounted because there is no ordering in udev. The ceph udev action
delegates asynchronously to systemd via ceph-disk@.service which will
fail if (for instance) the LVM partition required to mount /var/lib/ceph
is not available yet. The systemd unit will retry a few times but will
eventually fail permanently. The sysadmin can systemctl reset-fail at a
later time and it will succeed.
Add a dependency to ceph-disk@.service so that it waits until the local
file systems are mounted:
After=local-fs.target
Since local-fs.target depends on lvm, it will wait until the lvm
partition (as well as any dm devices) is ready and mounted before
attempting to activate the OSD. It may still fail because the
corresponding journal/data partition is not ready yet (which is
expected) but it will no longer fail because the lvm/filesystems/dm are
not ready.
Fixes: http://tracker.ceph.com/issues/17889
Signed-off-by: Loic Dachary <loic@dachary.org>
