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

[Horst Birthelmer]

On Tue, Mar 03, 2026 at 11:03:14AM +0100, Miklos Szeredi 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.
> 

OK, I will add a 'compound flag' for optional operations and don't
execute those, when the fuse server does not support compounds.

This way we can always send the open+getattr, but if the fuse server
does not process this as a compound (aka. it would be costly to do it), 
we only resend the FUSE_OPEN. Thus the current behavior does not change
and we can profit from fuse servers that actually have the possibility to
give us the attributes.

We can take a look at when to fetch the attributes in another context for
the other cases.

> 
> Thanks,
> Miklos
> 

Thanks,
Horst