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

[Horst Birthelmer <horst@birthelmer.de>]

On Fri, Feb 27, 2026 at 12:29:00PM +0100, Miklos Szeredi wrote:
> On Fri, 27 Feb 2026 at 11:48, Horst Birthelmer <horst@birthelmer.de> 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.
> 
OK, got it.

> > 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 really am greateful for this list. Helps me a lot, since I was looking at this from the 
perspective of the fuse server, which truns out to be different.

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

I naively thought that fuse_atomic_open() was actually there to do an atomic open ... ;-)

> Thanks,
> Miklos
> 

Thanks,
Horst