Hi,
When should / can rbd_aio_release be called exactly ?
For example if I create a rbd_aio_create_completion then do a
rbd_aio_XXX that fails, should I call rbd_aio_release ?
I would think yes, but when looking at the qemu rbd code, it doesn't
and I'm not sure if it's by design.
Cheers,
Hi,
tapdisk[9180]: segfault at 7f7e3a5c8c10 ip 7f7e387532d4 sp
7f7e3a5c8c10 error 4 in libpthread-2.13.so[7f7e38748000+17000]
tapdisk:9180 blocked for more than 120 seconds.
tapdisk D 88043fc13540 0 9180 1 0x
You can try generating a core file by
-- All Branches --
Alfredo Deza alfr...@deza.pe
2013-08-07 13:53:54 -0700 wip-5900
Dan Mick dan.m...@inktank.com
2012-12-18 12:27:36 -0800 wip-rbd-striping
2013-07-16 23:00:06 -0700 wip-5634
2013-07-23 22:13:14 -0700 wip-daemon
David Zafman
I couldn't find any info on ownership of items in the CDS 'paper cuts'
session. Was that done / documented somewhere? Specifically:
Quickstart for librados
- cls_helloworld
- helloworld_rados
- Noah
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a
On 08/12/2013 06:36 AM, Sylvain Munaut wrote:
Hi,
When should / can rbd_aio_release be called exactly ?
It should be called whenever you're certain you won't be using the
rbd_completion_t anymore (and an rbd_completion_t should not be reused
after rbd_aio_{read,write,discard,flush} is called
tapdisk[9180]: segfault at 7f7e3a5c8c10 ip 7f7e387532d4 sp
7f7e3a5c8c10 error 4 in libpthread-2.13.so[7f7e38748000+17000]
tapdisk:9180 blocked for more than 120 seconds.
tapdisk D 88043fc13540 0 9180 1 0x
You can try generating a core file by
Here's an (untested yet) patch in the rbd error path:
diff --git a/drivers/block-rbd.c b/drivers/block-rbd.c
index 68fbed7..ab2d2c5 100644
--- a/drivers/block-rbd.c
+++ b/drivers/block-rbd.c
@@ -560,6 +560,9 @@ err:
if (c)
rbd_aio_release(c);
+
Ah, there's another we apply universally to our test systems, apparently:
'/etc/security/limits.d/ubuntu.conf'
ubuntu hard nofile 16384
and the tests run as user ubuntu. Line 4 of the script is the nofile
setting.
On 08/10/2013 01:34 AM, Loic Dachary wrote:
On 10/08/2013 07:35, Dan Mick
Moving this conversation to ceph-devel where the dev's might be able
to shed some light on this.
I've added some additional debug to my code to narrow the issue down a
bit and the reader thread appears to be getting locked by
tcp_read_wait() because rpoll never returns an event when the socket
is
Hi,
A ceph user hit a problem with the 3.5 precise kernel with symptoms
exactly like an old poll(2) bug[1]. Basically, one end of a socket is
blocked on sendmsg(2), and the other end is blocked on poll(2) waiting for
data. 15 minutes later the poll(2) timeout triggers, we reset the
Did you take a look?
Stefan
Am 11.08.2013 um 05:50 schrieb Samuel Just sam.j...@inktank.com:
Great! I'll take a look on Monday.
-Sam
On Sat, Aug 10, 2013 at 12:08 PM, Stefan Priebe s.pri...@profihost.ag wrote:
Hi Samual,
Am 09.08.2013 23:44, schrieb Samuel Just:
I think Stefan's
I got swamped today. I should be able to look tomorrow. Sorry!
-Sam
On Mon, Aug 12, 2013 at 9:39 PM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:
Did you take a look?
Stefan
Am 11.08.2013 um 05:50 schrieb Samuel Just sam.j...@inktank.com:
Great! I'll take a look on Monday.
Hi Matthew,
I can confirm the beahviour whichi you describe.
I too believe that the problem is on the client side (ceph command).
My log files show the very same symptom, i.e. the client side
not being able to shutdown the pipes properly.
(Q: I had problems yesterday to send a mail to ceph-users
13 matches
Mail list logo
