Re: [PATCH] btrfs: write-protect folios during data writeback

在 2026/7/10 13:41, Christoph Hellwig 写道:
> On Thu, Jul 09, 2026 at 03:08:49PM +0930, Qu Wenruo wrote:
>> Just to mention, we can workaround the problem, by extracting the real work
>> of btrfs_invalidate_folio() into a helper, with a bool parameter to indicate
>> if we're called from the writeback path.
>>
>> Then we would have a better chance to rever to folio_clear_dirty_for_io(),
>> but there could be other things involved.
>> So I'm totally fine with the current hot fix, but eventually we will still
>> revert back to folio_clear_dirty_for_io(), to align the code to iomap.
> 
> This has nothing to do with iomap.  Normally the dirty clearing is done
> by the generic code in mm/page-writeback.c.  Gettind btrfs to use that
> instead of the horribly outdated forked version would be a really good
> thing.
> 

This involves a lot of technical debts, the main reason is that we have 
two paths that can writeback part of a folio:

- Compression
   AKA, the async submission.

   I had a series converting it to regular submission, but still under
   review, and the current version is still a little complex on the
   OE handling part.

- Zoned write
   I have no idea why we have to do it in the first place.
   I believe WDC people hit some problems with the regular writeback
   path.

The above two paths all lock a delalloc range that can cover part of the 
tailing folio.

If we call folio_clear_dirty_for_io() for all folios inside the range, 
then the tailing folio will not got its remaining part written back, 
because the folio is no longer dirty.

That's why we have to do all the complex per-block dirty tracking, and 
only call folio_clear_dirty_for_io() when there is no dirty block left 
in a folio.

But as Boris pointed out, the delayed timing is already problematic. And 
the current solution is the manual folio_mkclean() calls.

So I'm afraid there are a lot of work to do before we can get rid of the 
existing technical debts.

Thanks,
Qu