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

[Bernd Schubert]

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:
>>>
>>>> With simple request and a single request per buffer, one can re-use the
>>>> existing buffer for the reply in fuse-server
>>>>
>>>> - write: Do the write operation, then store the result into the io-buffer
>>>> - read: Copy the relatively small header, store the result into the
>>>> io-buffer
>>>>
>>>> - Meta-operations: Same as read
>>>
>>> Reminds me of the header/payload separation in io-uring.
>>>
>>> We could actually do that on the /dev/fuse interface as well, just
>>> never got around to implementing it:  first page reserved for
>>> header(s), payload is stored at PAGE_SIZE offset in the supplied
>>> buffer.
>>
>> Yeah, same here, I never came around to that during the past year.
>>
>>>
>>> That doesn't solve the overwriting problem, since in theory we could
>>> have a compound with a READ and a WRITE but in practice we can just
>>> disallow such combinations.
>>>
>>> In fact I'd argue that most/all practical compounds will not even have
>>> a payload and can fit into a page sized buffer.
>>
>> That is what Horst had said as well, until I came up with a use case -
>> write and immediately fetch updated attributes.
> 
> Attributes definitely should fit in the reply header buffer.

And now let's include something more complex, let's say a write
including a partial page write of an unknown page. With compounds
fetching the entire page or just the missing part + file attributes
becomes possible.

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

Thanks,
Bernd