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

[Joanne Koong]

On Wed, Mar 4, 2026 at 1:11 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Tue, Mar 03, 2026 at 01:19:43PM -0800, Joanne Koong wrote:
> > 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.
> >
>
> So the current consensus would be to use the compound when we
> either don't have the data, or it has become invalid,
> and use the current behavior
> (just do an open and don't worry about the stale attributes)
> when we have unexpired attributes?

In my opinion yes that would be the best path forward. I don't think
we should be optimizing for the distributed backend stale attributes
case as it introduces additional complexity and overhead and the case
is rarely encountered. I think it's better handled by the lease idea
Miklos mentioned.

Thanks,
Joanne
>
> Thanks,
> Horst