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

[Miklos Szeredi]

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.

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

Thanks,
Miklos