Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Wed, Mar 21, 2018 at 11:47:02AM -0700, Christoph Hellwig wrote: > On Wed, Mar 21, 2018 at 11:16:09AM -0700, Andrei Vagin wrote: > > If we look at lo_rw_aio, we can find that bvec can be allocated or got > > from bio. I think the problem with the second case. > > > > static int lo_rw_aio(struct

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Wed, Mar 21, 2018 at 11:16:09AM -0700, Andrei Vagin wrote: > If we look at lo_rw_aio, we can find that bvec can be allocated or got > from bio. I think the problem with the second case. > > static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd, > loff_t pos,

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Wed, Mar 21, 2018 at 12:23:40AM -0700, Christoph Hellwig wrote: > > I'm afraid this patch doesn't work, because we are not always allocate bvec, > > sometimes we get it from bio. In this case, we have to call > > blk_mq_complete_request after read_iter/write_iter. > > The issue there is that

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

> I'm afraid this patch doesn't work, because we are not always allocate bvec, > sometimes we get it from bio. In this case, we have to call > blk_mq_complete_request after read_iter/write_iter. The issue there is that we really need to NULL ->bvec after freeing it. Which normally is an

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Tue, Mar 20, 2018 at 01:47:01AM -0700, Christoph Hellwig wrote: > On Tue, Mar 20, 2018 at 12:54:58AM -0700, Andrei Vagin wrote: > > commit 92d773324b7edbd36bf0c28c1e0157763aeccc92 > > Author: Shaohua Li > > Date: Fri Sep 1 11:15:17 2017 -0700 > > > > block/loop: fix use

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Tue, Mar 20, 2018 at 12:54:58AM -0700, Andrei Vagin wrote: > commit 92d773324b7edbd36bf0c28c1e0157763aeccc92 > Author: Shaohua Li > Date: Fri Sep 1 11:15:17 2017 -0700 > > block/loop: fix use after free > > lo_rw_aio->call_read_iter-> > 1 aops->direct_IO

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Fri, Mar 16, 2018 at 12:50:27AM -0700, Christoph Hellwig wrote: > > DIF (PI) emulation doesn't work when a target uses async I/O, because > > DIF metadata is saved in a separate file, and it is another non-trivial > > task how to synchronize writing in two files, so that a following read > >

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Fri, Mar 16, 2018 at 05:13:25PM -0700, Andrei Vagin wrote: > > Please call the methods directly instead of through the wrappers. > > Do you mean to call file->f_op->write_iter(kio, iter) instead of > call_write_iter()? What is wrong with these wrappers? Yes. They are completely pointless and

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

Hi Christoph, Thank you for the review. All comments look reasonable. I will fix and set a final version soon. Pls, answer on one inline question. On Fri, Mar 16, 2018 at 12:50:27AM -0700, Christoph Hellwig wrote: > > DIF (PI) emulation doesn't work when a target uses async I/O, because > > DIF

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

> DIF (PI) emulation doesn't work when a target uses async I/O, because > DIF metadata is saved in a separate file, and it is another non-trivial > task how to synchronize writing in two files, so that a following read > operation always returns a consisten metadata for a specified block. There

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On Thu, Mar 15, 2018 at 09:26:57AM -0500, Bryant G. Ly wrote: > On 3/8/18 6:42 PM, Andrei Vagin wrote: > > > Direct I/O allows to not affect the write-back cache, this is > > expected when a non-buffered mode is used. > > > > Async I/O allows to handle a few commands concurrently, so a target

Re: [PATCH] [RFC] target/file: add support of direct and async I/O

On 3/8/18 6:42 PM, Andrei Vagin wrote: > Direct I/O allows to not affect the write-back cache, this is > expected when a non-buffered mode is used. > > Async I/O allows to handle a few commands concurrently, so a target shows a > better perfomance: > > Mode: O_DSYNC Async: 1 > $ ./fio --bs=4K