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

[Miklos Szeredi]

On Fri, 27 Feb 2026 at 11:48, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:

> > FUSE_SUB_IS_ENTRY - this sub request will return a new entry on
> > success (nodeid, filehandle)
> > FUSE_SUB_DEP_ENTRY - this sub request depends on the result of a previous lookup
> >
>
> we don't need this if we use my converters from above.

Dependencies need to be handled by the kernel and libfuse as well.
Makes no sense to have two separate mechanisms for handling
dependencies, so the kernel should use the same flags.

> Could you maybe provide some examples of usecases, that I should try to drill the
> new logic?

- LOOKUP + GETATTR[L]
- MKOBJ + (SETXATTR[L]  (only for posix_acl inheritance)) + GETATTR[L]
+ (OPEN[L] (optional)
- SETATTR + SETXATTR (setting posix_acl that modifies mode or setting
mode on file with posix_acl)
- INIT + LOOKUP_ROOT + GETATTR[L]
- OPEN + IOCTL[O] + RELEASE[O] (fileattr_get/set)

Only two dependencies here: lookup or open.  Both are simple in terms
of just needing to copy a field from a previous request to the current
one with fixed positions in all of the above cases.

The LOOKUP + MKNOD one *is* more complicated, because it makes
execution of the MKNOD dependent on the result of the LOOKUP, so the
dependency handler needs to look inside the result and decide how to
proceed based on that.  Some pros and cons of both approaches, so I'm
curious to see how yours looks like.

> I have used compounds to send groups of semantically linked requests to the fuse server
> signalling to it if the kernel expects it to be one atomic operation or a preferred
> 'group' of requests (like open+getattr, nothing happens if those are not processed atomic
> in a distributed file system)

Which is the case where the kernel expects them to be atomic?

Thanks,
Miklos