Memory leaks detector report:
...
==117947== 11,725 (200 direct, 11,525 indirect) bytes in 25 blocks are definitely lost in loss
record 82 of 82
==117947== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==117947== by 0x687CC1: RGWGC::process(int, int) (in /usr/bin/radosgw)
==117947== by 0x6884D1: RGWGC::process() (in /usr/bin/radosgw)
==117947== by 0x68875C: RGWGC::GCWorker::entry() (in /usr/bin/radosgw)
==117947== by 0x55F890A: Thread::_entry_func(void*) (in /usr/lib64/librados.so.2.0.0)
==117947== by 0x34D46079D0: start_thread (in /lib64/libpthread-2.12.so)
==117947== by 0x34D42E8B6C: clone (in /lib64/libc-2.12.so)
...
Signed-off-by: Andrey Kuznetsov <Andrey_Kuznetsov@epam.com>
Memory leaks detector report:
$ valgrind --leak-check=full /usr/bin/radosgw -c /etc/ceph/ceph.conf -n
client.radosgw.gateway -f
...
=16986== 1,262 (48 direct, 1,214 indirect) bytes in 1 blocks are definitely lost in loss record 81
of 83
==16986== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==16986== by 0x618F0D: RGWRados::init_complete() (in /usr/bin/radosgw)
==16986== by 0x618FE6: RGWRados::initialize() (in /usr/bin/radosgw)
==16986== by 0x63BB23: RGWRados::initialize(CephContext*, bool) (in /usr/bin/radosgw)
==16986== by 0x634D20: RGWStoreManager::init_storage_provider(CephContext*, bool) (in
/usr/bin/radosgw)
==16986== by 0x5B8970: RGWStoreManager::get_storage(CephContext*, bool) (in /usr/bin/radosgw)
==16986== by 0x5B6D5D: main (in /usr/bin/radosgw)
...
Signed-off-by: Andrey Kuznetsov <Andrey_Kuznetsov@epam.com>
Use the INFO keywork instead of WARNING so that gitbuilder does not
confuse this with a warning worth fixing.
Signed-off-by: Loic Dachary <loic@dachary.org>
This option is similar to osd_snap_trim_sleep: simply inject an optional
sleep in the thread that is doing scrub work. This is a very kludgey and
coarse knob for limiting the impact of scrub on the cluster, but can help
until we have a more robust and elegant solution.
Only sleep if we are in the NEW_CHUNK state to avoid delaying processing of
an in-progress chunk. In this state nothing is blocked on anything.
Conveniently, chunky_scrub() requeues itself for each new chunk.
Backport: firefly, dumpling
Signed-off-by: Sage Weil <sage@inktank.com>
If lru_*pin() is called twice, the counter will be incr/decr
incorrectly since it will count more/less pinned objects than
there is and so corrupts the balancing (lru_adjust()).
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@cloudwatt.com>
The method lru_clear() must set attribute lru_num to zero
after lru_top, lru_bot and lru_mid are reseted. indeed, lru_num
is the total number of elements found in all of them.
Also the test insures the good behavior of the method
lru_adjust() - lru_touch() calls lru_adjust every time
to balance lru_top and lru_bot by the value of lru_midpoint.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@cloudwatt.com>
When trying to kill a daemon, keep its pid in a variable instead of
retrieving it from the pidfile multiple times. It prevents the following
race condition:
* try to kill ceph-mon
* ceph-mon is in the process of dying and removed its pidfile
* try to kill ceph-mon fails because the pidfile is not found
* another ceph-mon is spawned and fails to bind the port
because the previous ceph-mon is still holding it
Signed-off-by: Loic Dachary <loic@dachary.org>
Remove the = from the goodchars of the erasure_code_profile argument of
osd pool create so that it is consistent with the goodchars of osd
erasure-code-profile set / rm.
Signed-off-by: Loic Dachary <loic@dachary.org>
If it is not, the non const version of OSDMap::get_erasure_code_profile
is called and a profile is created as a side effect, which is not
intended.
http://tracker.ceph.com/issues/8307 refs: #8307
Signed-off-by: Loic Dachary <loic@dachary.org>
If a non existent profile is provided as an argument to osd pool create,
it must exit on error and not create the profile as a side effect.
http://tracker.ceph.com/issues/8307 refs: #8307
Signed-off-by: Loic Dachary <loic@dachary.org>
To provide coverage for the 'import' command
resulting in the same contents as before an
export/import cycle.
Signed-off-by: John Spray <john.spray@redhat.com>
