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

[Bernd Schubert <bernd@bsbernd.com>]

On 2/12/26 10:07, Miklos Szeredi wrote:
> On Wed, 11 Feb 2026 at 21:36, Bernd Schubert <bernd@bsbernd.com> 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.

A bit side tracking background, I disabled auto-invalidate in the DDN
file system, because we use DLM anyway (additional patches for
background writes and mmap in our branches, should be published to the
list asap). And then that disabled auto-invalidation introduced another
xfstest failure, I think generic/323, but I would need to look it up. I
didn't have time for the details yet, but I think page read beyond EOF.
And that made me think that all operations that change file size and
time stamps could immediately return the updates attributes, if the file
system supports it - with our DLM we would support that.

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


Thanks,
Bernd