The correct (POSIX-style) program behavior should treat the buffer as immutable until the IO operation completes. It is never safe to assume the buffer can be re-used while the IO is in-flight. You should not add any logic to assume the buffer is safely copied prior to the completion of the IO. On Thu, Jul 6, 2017 at 9:33 AM, Piotr Dałek <piotr.dalek@xxxxxxxxxxxx> wrote: > On 17-07-06 03:03 PM, Jason Dillaman wrote: >> >> On Thu, Jul 6, 2017 at 8:26 AM, Piotr Dałek <piotr.dalek@xxxxxxxxxxxx> >> wrote: >>> >>> Hi, >>> >>> If you're using "rbd_aio_write()" in your code, be aware of the fact that >>> before Luminous release, this function expects buffer to remain unchanged >>> until write op ends, and on Luminous and later this function internally >>> copies the buffer, allocating memory where needed, freeing it once write >>> is >>> done. > > >> Pre-Luminous also copies the provided buffer when using the C API -- >> it just copies it at a later point and not immediately. The eventual >> goal is to eliminate the copy completely, but that requires some >> additional plumbing work deep down within the librados messenger >> layer. > > > I've learned the hard way that pre-luminous, even if it copies the buffer, > it does so too late. In my specific case, my FUSE module does enter the > write call and issues rbd_aio_write there, then exits the write - expecting > the buffer provided by FUSE to be copied by librbd (as it happens now in > Luminous). I didn't expect that it's a new behavior and once my code was > deployed to use Jewel librbd, it started to consistently corrupt data during > write. > > > -- > Piotr Dałek > piotr.dalek@xxxxxxxxxxxx > https://www.ovh.com/us/ > -- > 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 -- Jason -- 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
