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

[Horst Birthelmer]

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.

> > 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.

> 
> Thanks,
> Miklos

Thanks,
Horst