Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 20 Mar 2020 10:35:28 -0500
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
Message-ID: <20200320153528.theulg3fuzmdjhgl@fiona>
References: <20200319150805.uaggnfue5xgaougx@fiona>
 <20200320140538.GA27895@infradead.org>
 <02209ec3-62b4-595f-b84e-2cd8838ac41b@toxicpanda.com>
 <20200320143500.GA16143@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200320143500.GA16143@infradead.org>
User-Agent: NeoMutt/20180716
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

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