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

[Horst Birthelmer]

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.

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

> 
> Thanks,
> Bernd