On 07.11.24 17:09, Matthew Wilcox wrote:
On Thu, Nov 07, 2024 at 04:07:08PM +0100, David Hildenbrand wrote:
I'm debugging an interesting problem: split_folio() will fail on dirty
folios on XFS, and I am not sure who will trigger the writeback in a timely
manner so code relying on the split to work at some point (in sane setups
where page pinning is not applicable) can make progress.
You could call something like filemap_write_and_wait_range()?
Thanks, have to look into some details of that.
Looks like the folio_clear_dirty_for_io() is buried in
folio_prepare_writeback(), so that part is taken care of.
Guess I have to fo from folio to "mapping,lstart,lend" such that
__filemap_fdatawrite_range() would look up the folio again. Sounds doable.
(I assume I have to drop the folio lock+reference before calling that)
It's a bit suboptimal that the split_folio() caller has to take care of
that. But it's similar to waiting for writeback ... now I wonder if we
should have a helper function that takes care of "simple" cases of -EBUSY.
... or is there a feasible way forward to make iomap_release_folio() not
bail out on dirty folios?
The comment there says:
"If the folio is dirty, we refuse to release our metadata because it may be
partially dirty. Once we track per-block dirty state, we can release the
metadata if every block is dirty."
With the data structures and callbacks we have, it's hard to do.
Let's see if getting writeback kicked off will be enough to solve the
problem you're working on.
Let me find some time tomorrow/next week to play with this.
Thanks!
--
Cheers,
David / dhildenb
