Re: Note about rbd_aio_write usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux