Re: Re: Re: [PATCH v7 0/4] fuse: compound commands

[Horst Birthelmer]

On Fri, Jun 05, 2026 at 11:15:03AM +0200, Amir Goldstein wrote:
> On Fri, Jun 5, 2026 at 10:49 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jun 05, 2026 at 10:12:59AM +0200, Amir Goldstein wrote:
> > > On Thu, Jun 4, 2026 at 11:51 AM Horst Birthelmer <horst@xxxxxxxxxxxxxx> wrote:
> > > >
> > > > This series adds a single new opcode, FUSE_COMPOUND, that bundles a
> > > > sequence of subrequests into one round trip.  The wire format is
> > > >
> > > >     fuse_in_header (opcode FUSE_COMPOUND)
> > > >     fuse_compound_in
> > > >       fuse_compound_req_in
> > > >       fuse_in_header
> > > >       payload
> > > >       ... (repeated per subop)
> > > >
> > > > Compound is opt-in per connection and discovered by trial: the kernel
> > > > assumes support and clears its flag on the first -ENOSYS reply.
> > > > -EOPNOTSUPP declines a specific combination without disabling the
> > > > feature.  In both cases the kernel replays the subops individually
> > > > via fuse_simple_request(), so callers never need a separate
> > > > non-compound code path.
> > > >
> > > > The series ships two consumers:
> > > >
> > > >   - open + getattr, used when fuse_file_open() needs both ff->fh and
> > > >     fresh attrs (O_APPEND, or cached attrs already stale).  This
> > > >     closes the open-then-stat race described in [1].
> > > >   - dentry revalidate, fusing LOOKUP + GETATTR when both the entry
> > > >     and the attribute caches are stale.
> > >
> > > I am not sure if the intention for fusex is to carry over or phase out GETATTR
> > > in favor of STATX, but apart of the strategic question whether FUSE_COMPOUND
> > > should or should not be added to current FUSE protocol, we need to answer the
> > > more concrete question:
> > >
> > > Is FUSE_COMPOUND intended to improve existing unmodified servers
> > > which link with newer libfuse and run on a newer kernel?
> > >
> > > If not, then maybe we should start with OPEN/LOOKUP + STATX
> > > from the start.
> >
> > To your first question about phase out of GETATTR, I don't think so,
> > since fusex will use the same opcodes, so it will be there and we will
> > have to fall back IMHO.
> >
> > I have told this to a couple of people I have talked to about fusex
> > I would actually favor to negotiate supported opcodes and features in fusex
> > and adjust and overwrite the write operations accordingly. This of course is
> > miles away from the current state.
> >
> > I don't think compounds will do anything for fuse servers that do not support it
> > and that don't have special cases that could be made faster when basically knowing
> > on a semantical level what the kernel actually wants (this is like some sort of
> > lookahead in fuse requests. If you are in fuse_atomic_open() the LOOKUP you are
> > sending is most likely followed by the CREATE right down below ... but the fuse
> > server cannot know that unless the kernel tells it)
> >
> > It could have been when the compound handling of not supported operations would
> > have been in libfuse (which theoretically it still is), then you will save
> > user/kernel space switches, but when the kernel has to step in to do the 'legacy'
> > calls you actually will lose that intial try, where the fuse server tells you
> > ENOSYS or EOPNOTSUP.
> >
> > So when linked with a not yet existing new libfuse, we could get faster due to the
> > lesser switches to user space. Do you think that answers your initial question?
> >
> > I actually have an implementation of the atomic open (this is counter productive
> > for upstream, but I'm using it here as a concrete example to calrify the more general
> > point) and since our fuse server can do the atomic open  way more efficiently
> > (everybody knows by now that distributed locks cost you performance)
> > I get 15%-20% more performance on metadataa tests.
> >
> > The definitve answer here is probably somewhere around 'your milage may vary'.
> > I'm really interested in further discussion about this ... and your opinion here.
> > Would you want to use compounds for some case?
> 
> No, I do not have any use cases for compounds that I am aware of.
> 
> Compounds of READDIR+STATX was discussed as an technical alternative
> to READDIRPLUS2 which would need to return backing_ids, but I am still
> if this direction is worth pursuing.
> 
> >
> > BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?
> >
> 
> Yes, I was asking whether FUSE_STATX is expected to supersede
> FUSE_GETATTR in fusex. I don't know that answer.

I would support that idea, if it was up to me. 
Fortunately it's not ;-)

> 
> Thanks,
> Amir.

Thanks,
Horst