Message-ID: <5d022dc0-8423-4af2-918f-81ad04d50678@ddn.com>
Date: Wed, 21 Jan 2026 19:49:25 +0100
From: Bernd Schubert <bschubert@....com>
To: Horst Birthelmer <horst@...thelmer.de>, Bernd Schubert <bernd@...ernd.com>
Cc: Luis Henriques <luis@...lia.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: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE
 operation



On 1/21/26 19:36, Horst Birthelmer wrote:
> 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.

What I mean is, the auto-handler of libfuse could complete requests of
the 2nd compound request with those of the 1st 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