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

[Amir Goldstein]

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.

Thanks,
Amir.