From: Matthew Wilcox <[email protected]>
To: Stefan Roesch <[email protected]>
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Subject: Re: [PATCH v7 06/15] iomap: Return error code from iomap_write_iter()
Date: Mon, 6 Jun 2022 21:30:21 +0100 [thread overview]
Message-ID: <Yp5j3Yr7gnT/[email protected]> (raw)
In-Reply-To: <[email protected]>
On Mon, Jun 06, 2022 at 12:28:04PM -0700, Stefan Roesch wrote:
> On 6/6/22 12:25 PM, Matthew Wilcox wrote:
> > On Mon, Jun 06, 2022 at 12:21:28PM -0700, Stefan Roesch wrote:
> >> On 6/6/22 12:18 PM, Matthew Wilcox wrote:
> >>> On Mon, Jun 06, 2022 at 09:39:03AM -0700, Stefan Roesch wrote:
> >>>> On 6/2/22 5:38 AM, Matthew Wilcox wrote:
> >>>>> On Wed, Jun 01, 2022 at 02:01:32PM -0700, Stefan Roesch wrote:
> >>>>>> Change the signature of iomap_write_iter() to return an error code. In
> >>>>>> case we cannot allocate a page in iomap_write_begin(), we will not retry
> >>>>>> the memory alloction in iomap_write_begin().
> >>>>>
> >>>>> loff_t can already represent an error code. And it's already used like
> >>>>> that.
> >>>>>
> >>>>>> @@ -829,7 +830,8 @@ static loff_t iomap_write_iter(struct iomap_iter *iter, struct iov_iter *i)
> >>>>>> length -= status;
> >>>>>> } while (iov_iter_count(i) && length);
> >>>>>>
> >>>>>> - return written ? written : status;
> >>>>>> + *processed = written ? written : error;
> >>>>>> + return error;
> >>>>>
> >>>>> I think the change you really want is:
> >>>>>
> >>>>> if (status == -EAGAIN)
> >>>>> return -EAGAIN;
> >>>>> if (written)
> >>>>> return written;
> >>>>> return status;
> >>>>>
> >>>>
> >>>> I think the change needs to be:
> >>>>
> >>>> - return written ? written : status;
> >>>> + if (status == -EAGAIN) {
> >>>> + iov_iter_revert(i, written);
> >>>> + return -EAGAIN;
> >>>> + }
> >>>> + if (written)
> >>>> + return written;
> >>>> + return status;
> >>>
> >>> Ah yes, I think you're right.
> >>>
> >>> Does it work to leave everything the way it is, call back into the
> >>> iomap_write_iter() after having done a short write, get the -EAGAIN at
> >>> that point and pass the already-advanced iterator to the worker thread?
> >>> I haven't looked into the details of how that works, so maybe you just
> >>> can't do that.
> >>
> >> With the above change, short writes are handled correctly.
> >
> > Are they though? What about a write that crosses an extent boundary?
> > iomap_write_iter() gets called once per extent and I have a feeling that
> > you really need to revert the entire write, rather than just the part
> > of the write that was to that extent.
> >
> > Anyway, my question was whether we need to revert or whether the worker
> > thread can continue from where we left off.
>
> Without iov_iter_revert() fsx fails with errors in short writes and also my test
> program which issues short writes fails.
Does your test program include starting in one extent, completing the
portion of the write which is in that extent successfully, and having
the portion of the write which is in the second extent be short?
next prev parent reply other threads:[~2022-06-06 20:31 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 21:01 [PATCH v7 00/15] io-uring/xfs: support async buffered writes Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 01/15] mm: Move starting of background writeback into the main balancing loop Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 02/15] mm: Move updates of dirty_exceeded into one place Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 03/15] mm: Add balance_dirty_pages_ratelimited_flags() function Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 04/15] iomap: Add flags parameter to iomap_page_create() Stefan Roesch
2022-06-02 16:26 ` Darrick J. Wong
2022-06-01 21:01 ` [PATCH v7 05/15] iomap: Add async buffered write support Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 06/15] iomap: Return error code from iomap_write_iter() Stefan Roesch
2022-06-02 12:38 ` Matthew Wilcox
2022-06-02 17:08 ` Stefan Roesch
2022-06-06 16:39 ` Stefan Roesch
2022-06-06 19:18 ` Matthew Wilcox
2022-06-06 19:21 ` Stefan Roesch
2022-06-06 19:25 ` Matthew Wilcox
2022-06-06 19:28 ` Stefan Roesch
2022-06-06 20:30 ` Matthew Wilcox [this message]
2022-06-06 20:34 ` Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 07/15] fs: Add check for async buffered writes to generic_write_checks Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 08/15] fs: add __remove_file_privs() with flags parameter Stefan Roesch
2022-06-02 9:04 ` Jan Kara
2022-06-01 21:01 ` [PATCH v7 09/15] fs: Split off inode_needs_update_time and __file_update_time Stefan Roesch
2022-06-02 8:44 ` Jan Kara
2022-06-02 12:57 ` Matthew Wilcox
2022-06-02 21:04 ` Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 10/15] fs: Add async write file modification handling Stefan Roesch
2022-06-02 8:44 ` Jan Kara
2022-06-02 9:06 ` Jan Kara
2022-06-02 21:00 ` Stefan Roesch
2022-06-03 10:12 ` Jan Kara
2022-06-06 16:35 ` Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 11/15] fs: Optimization for concurrent file time updates Stefan Roesch
2022-06-02 8:59 ` Jan Kara
2022-06-02 21:06 ` Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 12/15] io_uring: Add support for async buffered writes Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 13/15] io_uring: Add tracepoint for short writes Stefan Roesch
2022-06-01 21:01 ` [PATCH v7 14/15] xfs: Specify lockmode when calling xfs_ilock_for_iomap() Stefan Roesch
2022-06-02 16:25 ` Darrick J. Wong
2022-06-01 21:01 ` [PATCH v7 15/15] xfs: Add async buffered write support Stefan Roesch
2022-07-01 4:39 ` Al Viro
2022-07-01 14:19 ` Jens Axboe
2022-07-01 14:30 ` Jens Axboe
2022-07-01 14:38 ` Jens Axboe
2022-07-01 18:05 ` Darrick J. Wong
2022-07-01 18:14 ` Jens Axboe
2022-07-05 13:47 ` Josef Bacik
2022-07-05 14:23 ` Goldwyn Rodrigues
2022-07-05 16:11 ` Christoph Hellwig
2022-06-02 8:09 ` [PATCH v7 00/15] io-uring/xfs: support async buffered writes Jens Axboe
2022-06-03 2:43 ` Dave Chinner
2022-06-03 13:04 ` Jens Axboe
2022-06-07 16:41 ` Stefan Roesch
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=Yp5j3Yr7gnT/[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox