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

[Miklos Szeredi]

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.

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