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

[Horst Birthelmer <horst@birthelmer.de>]

On Fri, Jun 05, 2026 at 12:49:55PM +0200, Bernd Schubert wrote:
> On 6/5/26 10:49, Horst Birthelmer 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@birthelmer.com> 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 agree with Amir and also with recent DDN requirements for DLM - there
> is no good reason to keep getattr. Basically for open we need to know
> the updated file size. Depending on the backend implementation, getting
> additionally the time stamps and other attributes _might_ be expensive.
> And that exactly there the statx mask helps.
> 
> And I don't think it is related to fusex vs fuse. If libfuse or fuse
> server do not support statx with the mask, well, then open+getattr will
> just not supported for open+getattr - existing behavior?
> 
> > 
> > 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?
> > 
> > BTW, OPEN+GETATTR is a special case of OPEN+STATX, isn't it?
> 
> Exactly, except that statx has a mask built in of what it needs.

In this regard. I think we can probably make it OPEN+STATX and set the appropriate mask.

> Thanks,
> Bernd