Re: [PATCH v3 12/16] fuse: use iomap for buffered writes

[Joanne Koong <joannelkoong@gmail.com>]

On Wed, Jul 2, 2025 at 10:57 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Wed, Jul 02, 2025 at 10:55:09AM -0700, Darrick J. Wong wrote:
> > On Mon, Jun 23, 2025 at 07:21:31PM -0700, Joanne Koong wrote:
> > > Have buffered writes go through iomap. This has two advantages:
> > > * granular large folio synchronous reads
> > > * granular large folio dirty tracking
> > >
> > > If for example there is a 1 MB large folio and a write issued at pos 1
> > > to pos 1 MB - 2, only the head and tail pages will need to be read in
> > > and marked uptodate instead of the entire folio needing to be read in.
> > > Non-relevant trailing pages are also skipped (eg if for a 1 MB large
> > > folio a write is issued at pos 1 to 4099, only the first two pages are
> > > read in and the ones after that are skipped).
> > >
> > > iomap also has granular dirty tracking. This is useful in that when it
> > > comes to writeback time, only the dirty portions of the large folio will
> > > be written instead of having to write out the entire folio. For example
> > > if there is a 1 MB large folio and only 2 bytes in it are dirty, only
> > > the page for those dirty bytes get written out. Please note that
> > > granular writeback is only done once fuse also uses iomap in writeback
> > > (separate commit).
> > >
> > > .release_folio needs to be set to iomap_release_folio so that any
> > > allocated iomap ifs structs get freed.
> >
> > What happens in the !iomap case, which can still happen for
> > !writeback_cache filesystems?  I don't think you can call
> > iomap_release_folio, because iomap doesn't own folio->private in that
> > case.

AFAICS, there's otherwise no private data attached to the folio for
fuse for the non-writeback paths, so I don't think this is an issue.
ifs_free() would be a no-op.

>
> ...and I think the answer to that is that the !writeback_cache case
> passes all file IO directly to the fuse server and never touches the
> page cache at all?

There's two !writeback_cache cases, direct io and writethrough.
For writethrough, the file IO gets passed to the fuse server and it
also gets written to the page cache.

>
> --D
>