Re: [PATCH v6 3/3] fuse: add an implementation of open+getattr

[Joanne Koong]

On Tue, Mar 3, 2026 at 2:03 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Tue, 3 Mar 2026 at 06:06, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
> >
> > On Mon, Mar 02, 2026 at 09:03:26PM +0100, Bernd Schubert wrote:
> > >
> > > On 3/2/26 19:56, Joanne Koong wrote:
>
> > > > The overhead for the server to fetch the attributes may be nontrivial
> > > > (eg may require stat()). I really don't think we can assume the data
> > > > is locally cached somewhere. Why always compound the getattr to the
> > > > open instead of only compounding the getattr when the attributes are
> > > > actually invalid?
> > > >
> > > > But maybe I'm wrong here and this is the preferable way of doing it.
> > > > Miklos, could you provide your input on this?
>
> Yes, it makes sense to refresh attributes only when necessary.
>
> > I wonder, since O_APPEND writes supposedly reposition the file position
> > to i_size before every write, can we enlarge the write reply so that the
> > fuse server could tell the client what i_size is supposed to be after
> > every write?  Or perhaps add a notification so a network filesystem
> > could try to keep the kernel uptodate after another node appends to a
> > file?
>
> This can be done with FUSE_NOTIFY_INVAL_INODE.
>
> Still racy.  If need to have perfect O_APPEND semantics,
> FOPEN_DIRECT_IO is currently the only option.

I think FOPEN_DIRECT_IO also uses the stale file size. eg
write_iter()
   fuse_file_write_iter()
      fuse_direct_write_iter()
         generic_write_checks()
            generic_write_checks_count()

which does

        if (iocb->ki_flags & IOCB_APPEND)
                iocb->ki_pos = i_size_read(inode);

and uses the locally cached (and stale) i_size.

I think right now the only option is for the fuse server to just
handle append semantics itself if it detects the O_APPEND flag in the
write request and just ignore the kernel-provided offset (assuming the
distributed backend synchronizes access amongst multiple clients). Or
return -ESTALE to open() if it detects the file size is stale, which
will trigger a lookup to fetch the latest attributes.

Thanks,
Joanne

>
> It would be nice to have some sort of delegation/lease mechanism in
> the fuse protocol to allow caching when remote is not modifying (which
> is the common case usually) but force uncached I/O when there's
> concurrent modification.
>
> Thanks,
> Miklos