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

[Bernd Schubert]

On 2/14/26 02:35, Joanne Koong wrote:
> 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).

Think of sshfs and open+getattr and a latency of ~1s per request. I.e.
especially if you go over the wire, you want to bundle as much as
possible. I'm aware that sftp current does not handle open+getattr, but
once fuse would support it as compound, we would have a good use case.
And while the 1s latency is corner case, although not even too uncommon
with sshfs, it applies to any network file system - you always want to
send as much as possible over the wire in one buffer. The
kernel/userspace interface is likely not the limit here.


Thanks,
Bernd