On Wed, Jun 25, 2025 at 09:44:31AM -0700, Joanne Koong wrote: > On Tue, Jun 24, 2025 at 11:26 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > On Tue, Jun 24, 2025 at 10:26:01PM -0700, Joanne Koong wrote: > > > > The question is whether this is acceptable for all the filesystem > > > > which implement ->launder_folio today. Because we could just move the > > > > folio_test_dirty() to after the folio_lock() and remove all the testing > > > > of folio dirtiness from individual filesystems. > > > > > > Or could the filesystems that implement ->launder_folio (from what I > > > see, there's only 4: fuse, nfs, btrfs, and orangefs) just move that > > > logic into their .release_folio implementation? I don't see why not. > > > In folio_unmap_invalidate(), we call: > > > > Without even looking into the details from the iomap POV that basically > > doesn't matter. You'd still need the write back a single locked folio > > interface, which adds API surface, and because it only writes a single > > folio at a time is rather inefficient. Not a deal breaker because > > the current version look ok, but it would still be preferable to not > > have an extra magic interface for it. > > > > Yes but as I understand it, the focus right now is on getting rid of > ->launder_folio as an API. The iomap pov imo is a separate issue with > determining whether fuse in particular needs to write back the dirty > page before releasing or should just fail. This might not help for Joanne's case, but so far the lack of a launder_folio in my fuse+iomap prototype hasn't hindered it at all.
