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

[Miklos Szeredi]

On Thu, 12 Feb 2026 at 11:48, Horst Birthelmer <horst@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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.

Not sure if I'm making sense.


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