From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Josef Bacik <josef@toxicpanda.com>,
linux-fsdevel@vger.kernel.org, riteshh@linux.ibm.com,
linux-ext4@vger.kernel.org, darrick.wong@oracle.com,
willy@infradead.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] iomap: return partial I/O count on error in iomap_dio_bio_actor
Date: Fri, 20 Mar 2020 10:35:28 -0500 [thread overview]
Message-ID: <20200320153528.theulg3fuzmdjhgl@fiona> (raw)
In-Reply-To: <20200320143500.GA16143@infradead.org>
On 7:35 20/03, Christoph Hellwig wrote:
> On Fri, Mar 20, 2020 at 10:23:43AM -0400, Josef Bacik wrote:
> > I'm not sure what you're looking at specifically wrt error handling, but I
> > can explain __endio_write_update_ordered.
> >
> > Btrfs has ordered extents to keep track of an extent that currently has IO
> > being done on it. Generally that IO takes multiple bio's, so we keep track
> > of the outstanding size of the IO being done, and each bio completes and
> > thus removes its size from the pending size. If any one of those bios has
> > an error we need to make sure we discard the whole ordered extent, as part
> > of it won't be valid. Just a cursory look at the current code I assume
> > that's what's confusing you, we call this when we have an error in the
> > O_DIRECT code. This is just so we get the proper cleanup for the ordered
> > extent. People will wait on the ordered extent to be completed, so if we've
> > started an ordered extent and aren't able to complete the range we need to
> > do __endio_write_update_ordered() so that the ordered extent is finished and
> > we wakeup any waiters.
> >
> > Does this help? If I need to I can context switch into whatever you're
> > looking at, but I'm going to avoid looking and hope I can just shout useful
> > information in your direction ;). Thanks,
>
> Yes, this helps a lot. This is about the patches from Goldwyn to
> convert btrfs to use the iomap direct I/O code. And in that series
> he currently calls __endio_write_update_ordered from the ->iomap_end
> method, which for direct I/O is called after all bios are submitted
> to complete ordered extents for a range after an I/O error, that
> is one that no I/O has been submitted to, and the accounting for that
> is a little complicated..
I think you meant "some" instead of "no".
Yes, keeping the information in iomap->private and setting in
btrfs_submit_direct() would be better. I will modify the code and
re-test. Thanks!
--
Goldwyn
next prev parent reply other threads:[~2020-03-20 15:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:08 [PATCH v2] iomap: return partial I/O count on error in iomap_dio_bio_actor Goldwyn Rodrigues
2020-03-20 14:05 ` Christoph Hellwig
2020-03-20 14:23 ` Josef Bacik
2020-03-20 14:35 ` Christoph Hellwig
2020-03-20 15:35 ` Goldwyn Rodrigues [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-02-20 15:24 Goldwyn Rodrigues
2020-02-20 15:23 Goldwyn Rodrigues
2020-02-20 17:42 ` Matthew Wilcox
2020-02-21 2:06 ` Goldwyn Rodrigues
2020-02-21 4:51 ` Ritesh Harjani
2020-02-21 12:48 ` Goldwyn Rodrigues
2020-02-25 20:53 ` Christoph Hellwig
2020-02-26 2:12 ` Damien Le Moal
2020-02-26 2:55 ` Goldwyn Rodrigues
2020-02-28 19:44 ` Goldwyn Rodrigues
2020-02-28 19:59 ` Matthew Wilcox
2020-02-28 20:35 ` Goldwyn Rodrigues
2020-03-02 13:31 ` Christoph Hellwig
2020-02-21 13:14 ` David Sterba
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=20200320153528.theulg3fuzmdjhgl@fiona \
--to=rgoldwyn@suse.de \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=riteshh@linux.ibm.com \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).