From: Josh Durgin <josh.durgin@inktank.com>
To: Sylvain Munaut <s.munaut@whatever-company.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Correct usage of rbd_aio_release
Date: Mon, 12 Aug 2013 14:58:56 -0700 [thread overview]
Message-ID: <52095AA0.9000008@inktank.com> (raw)
In-Reply-To: <CAF6-1L5nrco6oLq8xwnpymP+jLh8gi4O1WgvcOZimmCw4gFHiw@mail.gmail.com>
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 on it).
rbd_aio_release() could be in the callback, after the callback is
called, or like you suggest below, when there's an error submitting the
I/O in the first place. If you don't supply a callback when creating the
rbd_completion_t, you can release it after scheduling I/O with
rbd_aio_xxx, but you won't be able to do any error handling.
> 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.
Yes, you should call rbd_aio_release() then. It's a bug in the qemu rbd
driver that it doesn't, but the rbd_aio_xxx functions only fail for
some kind of bad request (i.e. trying to write to a snapshot, or
starting past the end of the image), so it's not really a problem in
practice. Errors like ENOSPC will not be triggered until after the
request is submitted, and will need to be handled by the callback.
Josh
prev parent reply other threads:[~2013-08-12 22:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 13:36 Correct usage of rbd_aio_release Sylvain Munaut
2013-08-12 21:58 ` Josh Durgin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52095AA0.9000008@inktank.com \
--to=josh.durgin@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=s.munaut@whatever-company.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox