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

[Joanne Koong]

On Tue, Mar 3, 2026 at 2:39 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> 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.

in my opinion, this adds additional complexity for no real benefit.  I
think we'll rarely hit a case where it'll be useful to speculatively
prefetch attributes that are already valid that is not already
accounted for by the attr_timeout the server set.

Thanks,
Joanne

>
> We can take a look at when to fetch the attributes in another context for
> the other cases.
>
> >
> > Thanks,
> > Miklos
> >
>
> Thanks,
> Horst