I'm wondering if there would be a way to just "cancel" the writeback and
mark the folio dirty again. That way it could be migrated, but not
reclaimed. At least we could avoid the whole AS_WRITEBACK_INDETERMINATE
thing.
That is what I basically meant with short timeouts. Obviously it is not
that simple to cancel the request and to retry - it would add in quite
some complexity, if all the issues that arise can be solved at all.
At least it would keep that out of core-mm.
AS_WRITEBACK_INDETERMINATE really has weird smell to it ... we should
try to improve such scenarios, not acknowledge and integrate them, then
work around using timeouts that must be manually configured, and ca
likely no be default enabled because it could hurt reasonable use cases :(
Right now we clear the writeback flag immediately, indicating that data
was written back, when in fact it was not written back at all. I suspect
fsync() currently handles that manually already, to wait for any of the
allocated pages to actually get written back by user space, so we have
control over when something was *actually* written back.
Similar to your proposal, I wonder if there could be a way to request
fuse to "abort" a writeback request (instead of using fixed timeouts per
request). Meaning, when we stumble over a folio that is under writeback
on some paths, we would tell fuse to "end writeback now", or "end
writeback now if it takes longer than X". Essentially hidden inside
folio_wait_writeback().
When aborting a request, as I said, we would essentially "end writeback"
and mark the folio as dirty again. The interesting thing is likely how
to handle user space that wants to process this request right now (stuck
in fuse_send_writepage() I assume?), correct?
Just throwing it out there ... no expert at all on fuse ...
--
Cheers,
David / dhildenb
