Re: [PATCH 00/17] btrfs: restrain lock extent usage during writeback

[Josef Bacik <josef@toxicpanda.com>]

On Thu, Apr 18, 2024 at 07:47:26AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 18, 2024 at 08:45:35AM -0500, Goldwyn Rodrigues wrote:
> > The only reason I have encountered for taking extent locks during reads
> > is for checksums. read()s collects checksums before submitting the bio
> > where as writeback() adds the checksums during bio completion.
> > 
> > So, there is a small window where a read() performed immediately after
> > writeback+truncate pages would give an EIO because the checksum is
> > not in the checksum tree and does not match the calculated checksum.
> > 
> > If we can delay retrieving the checksum or wait for ordered extents to
> > complete before performing the read, I think avoiding extent locks
> > during read is possible.
> 
> And the fix for that is to only clear the writeback bit once the
> ordered extent processing has finished, which is the other bit
> making btrfs I/O so different from the core kernels expectations.
> It is highly coupled with the extent lock semantics as far as I
> can tell.
> 

They aren't coupled, but they are related.  My follow-up work is to make this
change and see what breaks, and then tackle the read side.  This should pave the
way for a straightforward iomap conversion.  Thanks,

Josef