Re: Re: [PATCH v7 1/4] fuse: add compound command to combine multiple requests

[Horst Birthelmer <horst@birthelmer.de>]

On Fri, Jun 05, 2026 at 09:41:00AM +0200, Amir Goldstein wrote:
> 
> TBH, I did not look at NFS/SMB compound protocols, not io_uring
> command chains, so I would appreciate it if you include a survey of the
> state of the art in other protocols practices for compound commands.

I think the NFS compounds and FUSE compounds have very little in common.
Except for the the name ;-)

NFS has a tiny stack machine in the compound engine you could write stuff like this:

SEQUENCE(sessionid, slotid, seqid, ...)
PUTFH(parent_fh)        # CFH = parent dir
SAVEFH                  # SFH = parent
OPEN(name, claim, ...)  # CFH = opened file, returns stateid
GETFH                   # return CFH so client learns the fh
GETATTR(bitmap)         # attrs of the opened file
RESTOREFH               # CFH = parent again
GETATTR(bitmap)         # attrs of parent (change attr for cache)

With the latest changes, I had to get a liitle bit in that direction, but I
would hesitate to even compare them. I don't think we need somthing like that
for FUSE, even though it could be useful, since they can be atomic or even
transactional AFAIK.

I don't think there could be conditions, though.

My first approach was to bunch the FUSE requests together and send them together
to userspace via fuse_simple_request(), nothing more. What made this more
complicated was the later requirement, that we have to do call the requests separately
if the fuse server does not support compounds or does not support this particular
compound.

In NFS if you get a minor version mismatch the server will fall back to a smaller
version. This is a little bit like what we do here.

Further, NFS has a map of supported operations. ATM I don't think we need that.
I would rather want to have a map of combinations we support, since my whole
motivation was, to be able to implement optimized combinations in the fuse server.

FUSE IMHO wasn't designed for this. 
It was designed to send the requests to the server and wait for an answer for every 
request, but with io-uring you actually could have a bunch of them in parallel.

---

IO-uring command chains I rejected, because I did not want to tie this to uring.
But with fusex, this is a whole new ball game.

AFAICT, the uring chains (or lately there were groups introduced) are just commands
that are linked together as a sequence. IOSQE_IO_LINK means that the next sqe should 
start after this one finishes successful. Our compounds are probably more related 
to uring groups, but there I don't know enough about, exept that groups can share 
resources, but I have no idea how that works.

My compounds were more of a semantic grouping, where the fuse server could provide
optimized implementation of the whole group request. At least that is how I use them
at the moment.

> 
> Thanks,
> Amir.

Thanks for challenging me to actually compare these. I haven't done this before since
it was something completely different in my mind ... and to some degree it still is.

Thanks,
Horst