From: Jan Kara <jack@suse.cz>
To: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
darrick.wong@oracle.com, linux-xfs@vger.kernel.org,
Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH 0/2 v3] iomap: Waiting for IO in iomap_dio_rw()
Date: Mon, 14 Oct 2019 11:32:08 +0200 [thread overview]
Message-ID: <20191014093208.GC5939@quack2.suse.cz> (raw)
In-Reply-To: <20191014085218.GA6102@athena.bobrowski.net>
On Mon 14-10-19 19:52:18, Matthew Bobrowski wrote:
> On Mon, Oct 14, 2019 at 10:26:01AM +0200, Jan Kara wrote:
> > Original motivation:
> >
> > when doing the ext4 conversion of direct IO code to iomap, we found it very
> > difficult to handle inode extension with what iomap code currently provides.
> > Ext4 wants to do inode extension as sync IO (so that the whole duration of
> > IO is protected by inode->i_rwsem), also we need to truncate blocks beyond
> > end of file in case of error or short write. Now in ->end_io handler we don't
> > have the information how long originally the write was (to judge whether we
> > may have allocated more blocks than we actually used) and in ->write_iter
> > we don't know whether / how much of the IO actually succeeded in case of AIO.
> >
> > Thinking about it for some time I think iomap code makes it unnecessarily
> > complex for the filesystem in case it decides it doesn't want to perform AIO
> > and wants to fall back to good old synchronous IO. In such case it is much
> > easier for the filesystem if it just gets normal error return from
> > iomap_dio_rw() and not just -EIOCBQUEUED.
> >
> > The first patch in the series adds argument to iomap_dio_rw() to wait for IO
> > completion (internally iomap_dio_rw() already supports this!) and the second
> > patch converts XFS waiting for unaligned DIO write to this new API.
>
> Ah, wonderful, I was waiting for this to come through.
>
> I'll rebase my EXT4 direct I/O port on top of these patches and apply
> the discussed changes. Any objections? :)
No, go ahead. Thanks!
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2019-10-14 9:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-14 8:26 [PATCH 0/2 v3] iomap: Waiting for IO in iomap_dio_rw() Jan Kara
2019-10-14 8:26 ` [PATCH 1/2] iomap: Allow forcing of waiting for running DIO " Jan Kara
2019-10-14 8:40 ` Christoph Hellwig
2019-10-14 8:26 ` [PATCH 2/2] xfs: Use iomap_dio_rw_wait() Jan Kara
2019-10-14 8:41 ` Christoph Hellwig
2019-10-14 8:52 ` [PATCH 0/2 v3] iomap: Waiting for IO in iomap_dio_rw() Matthew Bobrowski
2019-10-14 9:32 ` Jan Kara [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=20191014093208.GC5939@quack2.suse.cz \
--to=jack@suse.cz \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
/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.