From: "Piotr Dałek" <branch@predictor.org.pl>
To: dillaman@redhat.com
Cc: "Piotr Dałek" <piotr.dalek@corp.ovh.com>,
ceph-devel <ceph-devel@vger.kernel.org>,
ceph-users <ceph-users@lists.ceph.com>
Subject: Re: Note about rbd_aio_write usage
Date: Thu, 6 Jul 2017 21:25:08 +0200 [thread overview]
Message-ID: <20170706192508.GG9832@mailware> (raw)
In-Reply-To: <CA+aFP1CXkF914u1qboCC1OnK3Qqqs7w0NctDxG82u=gpmUcxmA@mail.gmail.com>
On Thu, Jul 06, 2017 at 02:02:39PM -0400, Jason Dillaman wrote:
> On Thu, Jul 6, 2017 at 11:46 AM, Piotr Dałek <piotr.dalek@corp.ovh.com> wrote:
> > How about a hybrid solution? Keep the old rbd_aio_write contract (don't copy
> > the buffer with the assumption that it won't change) and instead of
> > constructing bufferlist containing bufferptr to copied data, construct a
> > bufferlist containing bufferptr made with create_static(user_buffer)?
>
> We must be talking past each other -- there was never such a
> pre-Lumunous contract since (1) it did copy the buffer on every IO and
> (2) it could have potentially copied before the 'rbd_aio_write' call
> returned or after (but at least before the completion was fired). Just
> because it works some times doesn't mean it would always work since it
> would be a race between two threads.
>
> Unfortunately, until the librados issue is solved, you will still have
> to copy the data once when using the C++ API. The only advantage is
> that you would be responsible for the copying and it would only need
> to be performed once instead of twice.
Even if it did copied the buffer, it did at unspecified point in time (as
you noted above!) requiring rbd_aio_write caller to follow usual AIO
practice of keeping buffers passed for as long as AIO is in progress. With
Luminous, not only it's no longer necessary, but it also hinders the user
program performance as buffers are always deep-copied, regardless of whether
caller follows AIO rules or not. Is that deep copy an equivalent of what
Jewel librbd did at unspecified point of time, or extra one?
--
Piotr Dałek
next prev parent reply other threads:[~2017-07-06 19:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-06 12:26 Note about rbd_aio_write usage Piotr Dałek
2017-07-06 13:03 ` Jason Dillaman
[not found] ` <CA+aFP1A5UVZzSDfFvphsVq9Jra9PXbJHUXhaJ9tH8LGx5OKJfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-06 13:33 ` Piotr Dałek
2017-07-06 13:43 ` Jason Dillaman
2017-07-06 14:22 ` Piotr Dałek
2017-07-06 14:40 ` Jason Dillaman
2017-07-06 15:46 ` Piotr Dałek
[not found] ` <e39eba47-ae4d-05bb-41cd-928565324d6c-Rm6v+N6rxxBWk0Htik3J/w@public.gmane.org>
2017-07-06 18:02 ` Jason Dillaman
2017-07-06 19:25 ` Piotr Dałek [this message]
2017-07-06 19:39 ` Jason Dillaman
2017-07-07 6:48 ` Piotr Dałek
2017-07-07 13:14 ` Jason Dillaman
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=20170706192508.GG9832@mailware \
--to=branch@predictor.org.pl \
--cc=ceph-devel@vger.kernel.org \
--cc=ceph-users@lists.ceph.com \
--cc=dillaman@redhat.com \
--cc=piotr.dalek@corp.ovh.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.