All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.