Message-ID: <aXEbnMNbE4k6WI7j@fedora>
Date: Wed, 21 Jan 2026 19:36:53 +0100
From: Horst Birthelmer <horst@...thelmer.de>
To: Bernd Schubert <bernd@...ernd.com>
Cc: Luis Henriques <luis@...lia.com>, Bernd Schubert <bschubert@....com>, 
	Amir Goldstein <amir73il@...il.com>, Miklos Szeredi <miklos@...redi.hu>, 
	"Darrick J. Wong" <djwong@...nel.org>, Kevin Chen <kchen@....com>, 
	Horst Birthelmer <hbirthelmer@....com>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Matt Harvey <mharvey@...ptrading.com>, 
	"kernel-dev@...lia.com" <kernel-dev@...lia.com>
Subject: Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

On Wed, Jan 21, 2026 at 07:28:43PM +0100, Bernd Schubert wrote:
> On 1/21/26 19:16, Horst Birthelmer wrote:
> > Hi Luis,
> > 
> > On Wed, Jan 21, 2026 at 05:56:12PM +0000, Luis Henriques wrote:
> >> Hi Horst!
> >>
> >> On Fri, Jan 09 2026, Horst Birthelmer wrote:
> >>
> >>> On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
> >>>> On 1/9/26 19:29, Amir Goldstein wrote:
> >>>>> On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@....com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/9/26 16:37, Miklos Szeredi wrote:
> >>>>>>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@...il.com> wrote:
> >>>>>>>
> >>>>>>>> What about FUSE_CREATE? FUSE_TMPFILE?
> >>>>>>>
> >>>>>>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
> >>>>>>>
> >>>>>>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
> >>>>>>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
> >>>>>>>
> >>>>>
> >>>>> I thought that the idea of FUSE_CREATE is that it is atomic_open()
> >>>>> is it not?
> >>>>> If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
> >>>>> it won't be atomic on the server, would it?
> >>>>
> >>>> Horst just posted the libfuse PR for compounds
> >>>> https://github.com/libfuse/libfuse/pull/1418
> >>>>
> >>>> You can make it atomic on the libfuse side with the compound
> >>>> implementation. I.e. you have the option leave it to libfuse to handle
> >>>> compound by compound as individual requests, or you handle the compound
> >>>> yourself as one request.
> >>>>
> >>>> I think we need to create an example with self handling of the compound,
> >>>> even if it is just to ensure that we didn't miss anything in design.
> >>>
> >>> I actually do have an example that would be suitable.
> >>> I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.
> >>
> >> So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
> >> And I would like to hear your opinion on a problem I found:
> >>
> >> If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
> >> in the request args.  On the other hand, the nodeid for a STATX will be
> >> the nodeid will be for the actual inode being statx'ed.
> >>
> >> The problem is that when merging both requests into a compound request,
> >> you don't have the nodeid for the STATX.  I've "fixed" this by passing in
> >> FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
> >> succeeds, we have the correct nodeid for the STATX.  That seems to work
> >> fine for my case, where the server handles the compound request itself.
> >> But from what I understand libfuse can also handle it as individual
> >> requests, and in this case the server wouldn't know the right nodeid for
> >> the STATX.
> >>
> >> Obviously, the same problem will need to be solved for other operations
> >> (for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
> >> FUSE_STATX + FUSE_OPEN).
> >>
> >> I guess this can eventually be fixed in libfuse, by updating the nodeid in
> >> this case.  Another solution is to not allow these sort of operations to
> >> be handled individually.  But maybe I'm just being dense and there's a
> >> better solution for this.
> >>
> > 
> > You have come across a problem, that I have come across, too, during my experiments. 
> > I think that makes it a rather common problem when creating compounds.
> > 
> > This can only be solved by convention and it is the reason why I have disabled the default
> > handling of compounds in libfuse. Bernd actually wanted to do that automatically, but I think
> > that is too risky for exactly the reason you have found.
> > 
> > The fuse server has to decide if it wants to handle the compound as such or as a
> > bunch of single requests.
> 
> Idea was actually to pass compounds to the daemon if it has a compound
> handler, if not to handle it automatically. Now for open+getattr
> fuse-server actually not want the additional getattr - cannot be handle
> automatically. But for lookup+stat and others like this, if fuse server
> server does not know how to handle the entire compound, libfuse could
> still do it correctly, i.e. have its own handler for known compounds?

We could definitely provide a library of compounds that we 'know' in libfuse,
of course. No argument there.

The problem Luis had was that he cannot construct the second request in the compound correctly
since he does not have all the in parameters to write complete request.

BTW, I forgot in my last mail to say that we have another problem, where we need 
some sort of convention where we will bang our heads sooner or later.
If the fuse server does not support the given compound it should 
return EOPNOTSUP in my opinion.
IIRC this is not implemented correctly so far.

> 
> > 
> > At the moment I think it is best to just not use the libfuse single request handling 
> > of the compound where it is not possible. 
> > As my passthrough_hp shows, you can handle certain compounds as a compound where you know all the information
> > (like some lookup, you just did in the fuse server) and leave the 'trivial' ones to the lib.
> > 
> > We could actually pass 'one' id in the 'in header' of the compound as some sort of global parent 
> > but that would be another convention that the fuse server has to know and keep.
> > 
> 
> 
> Thanks,
> Bernd

Horst

Powered by blists - more mailing lists