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

[Horst Birthelmer <horst@birthelmer.de>]

On Thu, Feb 12, 2026 at 01:10:19PM +0100, Miklos Szeredi wrote:
> On Thu, 12 Feb 2026 at 11:48, Horst Birthelmer <horst@birthelmer.de> wrote:
> > On Thu, Feb 12, 2026 at 11:23:56AM +0100, Miklos Szeredi wrote:
> > > On Thu, 12 Feb 2026 at 10:53, Horst Birthelmer <horst@birthelmer.de> wrote:
> > > >
> > > >
> > > > 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".
> > >
> >
> > This makes the handling on the fuse server side unnecessarily harder.
> > With the current way I can check the flag in the compound header and let libfuse handle the
> > compound by calling the request handlers separately, and not worry about a thing.
> >
> > If the flag is not there, the fuse server itself
> > (passthrough_hp from the PR already demonstrates this) has to handle the whole compound
> > as a whole. I'm confident that this way we can handle pretty much every semantically
> > overloaded combination.
> 
> Yeah, that's one strategy.  I'm saying that supporting compounds that
> are not "separable" within libfuse should be possible, given a few
> constraints.  Something very similar is done in io-uring.  It adds
> complexity, but I think it's worth it.
> 
> I also have the feeling that decoding requests should always be done
> by the library, and if the server wants to handle compounds in special
> way (because for example the network protocol also supports that),
> then it should be done by bracketing the regular operation callbacks
> with compound callbacks, that can allocate/free context which can be
> used by the operation callbacks.
> 

Right now we don't have it completely like this but very similar.
The fuse server makes the final decision not the library.

If it doesn't support a combination it gives control back to libfuse
and if the FUSE_COMPOUND_SEPARABLE flag is set libfuse calls the handlers
sequencially.

The only drawback here is, (this actually makes handling a lot easier)
that we have to have valid and complete results for all requests 
that are in the compound.

> Not sure if I'm making sense.
> 

I think we're getting there that I understand your perspective better.

> >
> > The other way would make the handling in libfuse or in the lowest level of the fuse server
> > (for fuse servers that don't use libfuse) almost impossible without parsing all the requests
> > and all the flags to know that we would have been able to get away with very little work.
> >
> > I had thought of a hierarchical parsing of the compound.
> > The fuse server can decide
> > 1. does it handle compounds at all
> > 2. does it support this particular compound (based on the opcodes and the compound flags
> > and the particular capabilities of the fuse server)
> > 3. if the particular compound can not be handled can libfuse handle it for us?
> >
> > This way we can have real atomic operations in fuse server, where it supports it.
> 
> Yes, that's something definitely useful.   But I also think that the
> fuse *filesystem* code in the kernel should not have to worry about
> whether a particular server supports a particular combination of
> operations and fall back to calling ops sequentially if it doesn't.
> This could be all handled transparently in the layers below
> (fs/fuse/dev.c, lib/fuse_lowelevel.c).

I actually like this approach.
lib/fuse_lowlevel.c is already there ... the kernel part does not do this yet.
I'll have a look and come up with a new version.

> > I don't understand yet, why.
> > I think we could actually implement a real atomic open if we craft a compound for it and
> > the fuse server supports it. If not, we can go back to the way it is handled now.
> >
> > What am I missing here?
> 
> I'm saying that there's no point in splitting FUSE_CREATE into
> FUSE_LOOKUP + FUSE_MKNOD compound, since that would:
> 
> a) complicate the logic of joining the ops (which I was taking about above)
> b) add redundant information (parent and name are the same in both ops)
> c) we already have an atomic op that does both, so why make it larger
> and less efficient?
> 
> Thanks,
> Miklos

Thanks,
Horst