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

[Joanne Koong]

On Thu, Feb 12, 2026 at 3:44 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 12, 2026 at 11:43:12AM +0100, Bernd Schubert wrote:
> >
> >
> > On 2/12/26 11:16, Miklos Szeredi wrote:
> > > On Thu, 12 Feb 2026 at 10:48, Bernd Schubert <bernd@xxxxxxxxxxx> wrote:
> > >> On 2/12/26 10:07, Miklos Szeredi wrote:
> > >>> On Wed, 11 Feb 2026 at 21:36, Bernd Schubert <bernd@xxxxxxxxxxx> wrote:
> > >>>
> > >
> > >>> So as a first iteration can we just limit compounds to small in/out sizes?
> > >>
> > >> Even without write payload, there is still FUSE_NAME_MAX, that can be up
> > >> to PATH_MAX -1. Let's say there is LOOKUP, CREATE/OPEN, GETATTR. Lookup
> > >> could take >4K, CREATE/OPEN another 4K. Copying that pro-actively out of
> > >> the buffer seems a bit overhead? Especially as libfuse needs to iterate
> > >> over each compound first and figure out the exact size.
> > >
> > > Ah, huge filenames are a thing.  Probably not worth doing
> > > LOOKUP+CREATE as a compound since it duplicates the filename.  We
> > > already have LOOKUP_CREATE, which does both.  Am I missing something?
> >
> > I think you mean FUSE_CREATE? Which is create+getattr, but always
> > preceded by FUSE_LOOKUP is always sent first? Horst is currently working
> > on full atomic open based on compounds, i.e. a totally new patch set to
> > the earlier versions. With that LOOKUP
> >
> > Yes, we could use the same file name for the entire compound, but then
> > individual requests of the compound rely on an uber info. This info
> > needs to be created, it needs to be handled on the other side as part of
> > the individual parts. Please correct me if I'm wrong, but this sounds
> > much more difficult than just adding an info how much space is needed to
> > hold the result?
>
> I have a feeling we have different use cases in mind and misunderstand each other.
>
> As I see it:
> From the discussion a while ago that actually started the whole thing I understand
> that we have combinations of requests that we want to bunch together for a
> specific semantic effect. (see OPEN+GETATTR that started it all)
>
> If that is true, then bunching together more commands to create 'compounds' that
> semantically linked should not be a problem and we don't need any algorithm for
> recosntructing the args. We know the semantics on both ends and craft the compounds
> according to what is to be accomplished (the fuse server just provides the 'how')
>
> From the newer discussion I have a feeling that there is the idea floating around
> that we should bunch together arbitrary requests to have some performance advantage.
> This was not my initial intention.
> We could do that however if we can fill the args and the requests are not
> interdependent.

I have a series of (very unpolished) patches from last year that does
basically this. When libfuse does a read on /dev/fuse, the kernel
crams in as many requests off the fiq list as it can fit into the
buffer. On the libfuse side, when it iterates through that buffer it
offloads each request to a worker thread to process/execute that
request. It worked the same way on the dev uring side. I put those
changes aside to work on the zero copy stuff, but if there's interest
I can go back to those patches and clean them up and put them through
some testing. I don't think the work overlaps with your compound
requests stuff though. The compound requests would be a request inside
the larger batch.

>
> If we can signal to the fuse server what we expect as result
> (at least the allocated memory) I think we can do both, but I would like to have the
> emphasis more on the semantic grouping for the moment.
>
> Do you guys think that there will ever be a fuse server that doesn't support compounds
> and all of them are handled by something like libfuse and the request handlers are just
> called without having to handle not even one unseparatebale semantic 'group'?

If I'm understanding the question correctly, yes imo this is likely.
But I think that's fine. In my opinion, the main benefit from this is
saving on the context switching cost. I don't really see the problem
if libfuse has to issue the requests separately and sequentially if
the requests have dependency chains and  the server doesn't have a
special handler for that specific compound request combo (which imo I
don't think libfuse should even add, as I dont see what the purpose of
it is that can't be done by sending each request to each separate
handler sequentially).

Thanks,
Joanne

>
> >
> > Thanks,
> > Bernd