Re: Re: Re: [PATCH v5 1/3] fuse: add compound command to combine multiple requests

[Miklos Szeredi]

On Thu, 12 Feb 2026 at 10:53, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 12, 2026 at 10:38:25AM +0100, Miklos Szeredi wrote:
> > On Wed, 11 Feb 2026 at 17:35, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> > >
> > > >
> > > > > +#define FUSE_MAX_COMPOUND_OPS   16        /* Maximum operations per compound */
> > > >
> > > > Don't see a good reason to declare this in the API.   More sensible
> > > > would be to negotiate a max_request_size during INIT.
> > > >
> > >
> > > Wouldn't that make for a very complicated implementation of larger compounds.
> > > If a fuse server negotiates something like 2?
> >
> > I didn't mean negotiating the number of ops, rather the size of the
> > buffer for the compound.
> >
> OK, so the current limit would be the size of the whole operation.
>
> > But let's not overthink this.   If compound doesn't fit in 4k, then it
> > probably not worth doing anyway.
>
> Got it!
> Unless some people have the idea of doing some atomic operation with
> WRITE+<some attribute operation> ;-)
>
> >
> > > > > +
> > > > > +#define FUSE_COMPOUND_SEPARABLE (1<<0)
> > > > > +#define FUSE_COMPOUND_ATOMIC (1<<1)
> > > >
> > > > What is the meaning of these flags?
> > >
> > > FUSE_COMPOUND_SEPARABLE is a hint for the fuse server that the requests are all
> > > complete and there is no need to use the result of one request to complete the input
> > > of another request further down the line.
> >
> > Aha, so it means parallel execution is allowed.
>
> Yes.
>
> >
> > > Think of LOOKUP+MKNOD+OPEN ... that would never be 'separable'.
> >
> > Right.  I think for the moment we don't need to think about parallel
> > execution within a compound.
>
> Not only for parallel execution. You cannot craft the args for this to be
> complete, independent of parallel execution.
>
> You will need the result of LOOKUP to know what to do with MKNOD and to fill the args for OPEN.
>
> >
> > > At the moment I use this flag to signal libfuse that it can decode the compund
> > > and execute sequencially completely in the lib and just call the separate requests
> > > of the fuse server.
> >
> > I think decoding and executing the ops sequentially should always be
> > possible, and it would be one of the major advantages of the compound
> > architecture: kernel packs a number of requests that it would do
> > sequentially, sends to server, server decodes and calls individual
> > callbacks in filesystem, then replies with the compound result.  This
> > reduces the number of syscalls/context switches which can be a win
> > even with an unchanged library API.
>
> Yes, but some combinations are not complete when you have interdependencies
> within the packed requests.
>
> >
> > The trick in a case like MKNOD + OPEN is to let the server know how to
> > feed the output of one request to the input of the next.
> >
>
> Exactly. And the FUSE_COMPOUND_SEPARABLE was actually there to tell the fuse server,
> that we know that this is not done in this case, so the requests can be processed
> 'separately'.
> If that is missing the fuse server has to look at the combination and decide wether it
> will execute it as a 'compound' or return an error.

I'd rather add some sub-op header flag that how to fill the missing
input.  E.g. use the nodeid from the previous op's result.

If there's no flag, then the op is "separable".

> > > FUSE_COMPOUND_ATOMIC was an idea to hint to the fuse server that the kernel treats
> > > the compound as one atomic request. This can maybe save us some checks for some
> > > compounds.
> >
> > Do you have an example?
>
> Yes, I have used it for my (not yet ready for scrutiny) implementation of atomic open.
> If you know that LOOKUP got a valid result and the operation was atomic on fuse server side,
> you don't have to check for MKNODs result.

As noted in my reply to Bernd the LOOKUP+MKNOD may not be the best way
to use compounds. May be better off sticking with an actual atomic op
for this.

Thanks,
Miklos