If current map epoch is less than oldest epoch, current map epoch
should step up to oldest epoch.
Fixes: #9986
Signed-off-by: Ding Dinghua <dingdinghua85@gmail.com>
We were only invalidating the cached value from apply_incremental, which
is no longer called on modern clusters.
Fix this by storing the update epoch in the key as well (it is not part
of osd_stat_t).
Backport: giant, firefly, dumpling(?)
Fixes: #9987
Signed-off-by: Sage Weil <sage@redhat.com>
We were only invalidating the cache from the legacy apply_incremental(),
which is no longer called on modern clusters.
Fixes: #9987
Signed-off-by: Sage Weil <sage@redhat.com>
It's possible that the osd stopped between when the filestore
op_seq file was updated and when the journal was trimmed. In
that case, it's possible that on boot the journal might be
full, and yet not be trimmed because commit_start assumes
there is no work to do. Calling committed_thru on the journal
ensures that the journal matches committed_seq.
Backport: giant firefly emperor dumpling
Fixes: #6756
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
Reviewed-by: David Zafman <david.zafman@inktank.com>
Return a pointer to a contiguous range of the bufferlist, rebuilding
into a contiguous region as needed. For now, if we need to rebuild,
we just do the whole thing. We can obviously optimize this later to
rebuild on the necessary region, but this is good enough for the
(presumably) common case where the needed region is already in fact
contiguous.
Signed-off-by: Sage Weil <sage@redhat.com>
Dear list,
I have met this when I was using radosstriper C API. My program is
roughly like this:
rados_striper_aio_write
rados_aio_flush
rados_aio_wait_for_safe
rados_aio_release
rados_striper_destroy
rados_ioctx_destroy
rados_shutdown /Hangs here/
In most time, this works well, But the programm occasionally
hangs forever. Output of gstack:
Thread 1 (Thread 0x7fe0afba0760 (LWP 18509)):
0 0x000000330f20822d in pthread_join () from /lib64/libpthread.so.0
1 0x000000347566cea2 in Thread::join(void**) () from
/usr/lib64/librados.so.2
2 0x00000034755ac535 in librados::RadosClient::shutdown() () from
/usr/lib64/librados.so.2
3 0x0000003475592269 in rados_shutdown () from /usr/lib64/librados.so.2
4 0x0000000000402349 in main ()
Thread 4 (Thread 0x7fe0ab14d700 (LWP 18541)):
0 0x000000330f20e264 in __lll_lock_wait () from /lib64/libpthread.so.0
1 0x000000330f209508 in _L_lock_854 () from /lib64/libpthread.so.0
2 0x000000330f2093d7 in pthread_mutex_lock () from
/lib64/libpthread.so.0
3 0x0000003475633af1 in Mutex::Lock(bool) () from
/usr/lib64/librados.so.2
4 0x00000034755abd37 in librados::RadosClient::put() () from
/usr/lib64/librados.so.2
5 0x0000003475592501 in librados::Rados::shutdown() () from
/usr/lib64/librados.so.2
6 0x00007fe0afbba9f7 in
libradosstriper::RadosStriperImpl::CompletionData::~CompletionData() ()
from /usr/lib64/libradosstriper.so.1
7 0x00007fe0afbbaad9 in
libradosstriper::RadosStriperImpl::WriteCompletionData::~WriteCompletionData()
() from /usr/lib64/libradosstriper.so.1
8 0x00007fe0afbc1d75 in RefCountedObject::put() () from
/usr/lib64/libradosstriper.so.1
9 0x00007fe0afbc224d in
libradosstriper::MultiAioCompletionImpl::safe_request(long) () from
/usr/lib64/libradosstriper.so.1
10 0x00000034755c5ce8 in librados::C_AioSafe::finish(int) () from
/usr/lib64/librados.so.2
11 0x00000034755a0e89 in Context::complete(int) () from
/usr/lib64/librados.so.2
12 0x000000347564d4c8 in Finisher::finisher_thread_entry() () from
/usr/lib64/librados.so.2
13 0x000000330f2079d1 in start_thread () from /lib64/libpthread.so.0
14 0x000000330eae886d in clone () from /lib64/libc.so.6
It is obvious that librados::Rados::shutdown is not a thread-safe
function here. It will hang forever. The culprit of this is when
CompletionData is released, it will first notify
"rados_aio_wait_for_safe" to continue, and CompletionData will call
put() to release other data. But if the main thread(Thread 1 here) runs
fast enough, rados_striper_destroy will be executed before other
thread(Thread 4 here)'s releasing refcnf. In this situation, main thread
runs Rados::shutdown() while other thread runs Rados::shutdown() in the
same time.
My suggestion is to let RadosStriperImpl::aio_flush to block until all
the CompletionData has been released. This makes sure other thread will
never call rados_shutdown.
The acting array was incorrectly including the primary and up_primary.
http://tracker.ceph.com/issues/9752Fixes: #9752
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
If the base pool does not exist, we need to avoid dereferencing pi.
This simplest fix is to return with POOL_DNE early and skip all of the
checks.
Note that there is one other small semantic change in this function: if
we are using the precalc_pgid then base_oloc pool has to match. But
the list_objects() caller does that, so we're fine.
Backport: giant
Fixes: #9944
Signed-off-by: Sage Weil <sage@redhat.com>
This commit introduces some updates for the OpenStack Juno release. New
flags have been added, many trailing spaces were removed and a new
recommendation for Glance cache management has been added too.
Signed-off-by: Sébastien Han <sebastien.han@enovance.com>
Shutdown the delayed delivery before the incoming queue in case the
DelayedDelivery thread is busy queuing messages.
Fixes: #9910
Signed-off-by: Sage Weil <sage@redhat.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
AsyncMessenger will select event driver following epoll, kqueue and
select(now not exists) sequence
Fix#9926
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
Because some test environments generate spurious
rmxattr operations, allow the client to release
'X' caps. Allows xattr operations to proceed
while still preventing client releasing other caps.
Fixes: #9800
Signed-off-by: John Spray <john.spray@redhat.com>
(cherry picked from commit 5691c68a0a)
Not sure how 'quick' this really is now compared with
the full filesystem instructions, but let's not leave
it incomplete.
Signed-off-by: John Spray <john.spray@redhat.com>
When using export <image-name> <path> and the size of image is more
than 2G, the previous version about finish() could not handle in
seeking the offset in image and return error.
This is caused by the incorrect variable type. Try to use the correct
variable type to fixed it.
I use another variable which type is uint64_t for confirming seeking
and still use the previous r for return error.
uint64_t is more better than type int for handle lseek64().
Signed-off-by: Vicente Cheng <freeze.bilsted@gmail.com>
For testing injectargs a configuration option was changed that has side
effects on the cluster. It could introduce random failures later. It is
replaced with a configuration option that cannot have adverse side
effects on the cluster.
http://tracker.ceph.com/issues/9919Fixes: #9919
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
Because some test environments generate spurious
rmxattr operations, allow the client to release
'X' caps. Allows xattr operations to proceed
while still preventing client releasing other caps.
Fixes: #9800
Signed-off-by: John Spray <john.spray@redhat.com>
Currently if we enable quota and set max_size = -1, it doesn’t
mean max_size is unlimited as expected. Instead, it means object
with any size is not allowed to upload because of “QuotaExceeded”.
The root cause is the function rgw_rounded_kb which convert max_size
to max_size_kb returns 0 for -1 because it takes an unsigned int
but we pass an int to it. A simple fix is check max_size before
it’s rounded to max_size_kb.
Test case:
1 enable and set quota:
radosgw-admin quota enable --uid={user_id} --quota-scope=user
radosgw-admin quota set --quota-scope=user --uid={user_id}\
--max-objects=100 --max-size=-1
2 upload any object with non-zero length
it will return 403 with “QuotaExceeded” and return 200 if you apply the fix.
Fixes: #9907
Backport: giant, firefly
Signed-off-by: Dong Lei leidong@yahoo-inc.com
