In case insertions have occurred during the split that would
immediately take the new fragments over the split threshold.
Signed-off-by: John Spray <john.spray@redhat.com>
Check it during the initial request, not just
on completion, so that when doing lots of creates
we get a chance to split the directory before
it zooms past the size threshold.
Signed-off-by: John Spray <john.spray@redhat.com>
In _fragment_finish we would like to try splitting
the new frags without applying a spurious hit to their
temperatures. Same for the start of openc where we would
like to do an early check for splitting without hitting
the dir twice.
Signed-off-by: John Spray <john.spray@redhat.com>
The allows_dirfrags() test was in the wrong place, causing
in some cases a root fragment to be passed into queue_merge.
Signed-off-by: John Spray <john.spray@redhat.com>
Increment these when we have finished splitting
or merging, not partway through the process.
This makes testing more deterministic: once I've seen
the counter increment, I'm sure that the children
no longer have STATE_FRAGMENTING set as a result of
their parent's split-in-progress.
Signed-off-by: John Spray <john.spray@redhat.com>
Tell users they need to set this to true before Monitors will allow
pools to be removed.
Also update the Pending Release Notes so that users can find this change
there.
This was changed with commit 5d7f4ea
Signed-off-by: Wido den Hollander <wido@42on.com>
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>
