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

[Joanne Koong]

On Thu, Feb 12, 2026 at 4:34 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 12, 2026 at 01:10:19PM +0100, Miklos Szeredi wrote:
> > 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.

In my opinion, having the request marked at the individual request
header level as having a dependency on the request before it gives
more flexibility long term. With marking it at the compound header
level, all the requests will have to be assumed as sequentially
dependent whereas it might be the case that there's only a few
dependency chains between requests rather than all of the requests in
the compound being dependent on the request preceding it.

Thanks,
Joanne

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