Re: [PATCH] fuse: add fusex filesystem

[Bernd Schubert <bernd@bsbernd.com>]

On 5/12/26 23:07, Amir Goldstein wrote:
> On Tue, May 12, 2026 at 3:46 PM Bernd Schubert <bernd@bsbernd.com> wrote:
>>
>>
>>
>> On 5/12/26 15:08, Amir Goldstein wrote:
>>> On Tue, May 12, 2026 at 10:18 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>>>
>>>>> I see no reason for fusex to not support lookup by ".", which is
>>>>> anyway needed for "reconnect", so a fresh FUSEX_NFS_EXPORT opt-in
>>>>> for "re-export to NFS" may make more sense.
>>>>
>>>> Why add reconnect?  If server supports persistent file handles, and
>>>> all req's get the file handle, then no state (nodeid) needs to be
>>>> stored by the server.
>>>>
>>>
>>> Yes, we are saying the same thing.
>>> What I am saying is that legacy fuse has FUSE_EXPORT_SUPPORT
>>> which means server supports lookup of "." which libfuse always enabled
>>> and then we added FUSE_NO_EXPORT_SUPPORT to opt-out of nfs export.
>>>
>>> I am saying that in FUSEX, lookup "." support is implied.
>>> And that nfs export should always be opt-in (FUSEX_NFS_EXPORT).
>>
>> I'm confused here, why do we need lookup of "." without NFS export? And
>> which file system actually supports lookup of "."?
>> Shouldn't all that be scratched in favor of LOOKUP_HANDLE?
> 
> Yes. This is exactly what I meant by lookup "." support is implied.
> 
> AFAICT, libfuse sets CAP_EXPORT_SUPPORT unconditionally:
> 
>         fuse_set_feature_flag(conn, FUSE_CAP_EXPORT_SUPPORT);
> 
> ALL of the high level fuse fs are allowed to be exported by NFS,
> which is often a very bad idea.

I think that predates me and is in the came category as
FUSE_CAP_AUTO_INVAL_DATA. Initially I thought it gets really complicated
and I need to add another ABI/API compat layer to encode into struct
fuse_session which FUSE_USE_VERSION the application uses, but then in
the discussion with Darrick we got the idea to put it into the existing
padding

fuse_session_new_fn(struct fuse_args *args, const struct
fuse_lowlevel_ops *op,
                    size_t op_size, void *userdata)
{
        struct libfuse_version version = {
                .major = FUSE_MAJOR_VERSION,
                .minor = FUSE_MINOR_VERSION,
                .hotfix = FUSE_HOTFIX_VERSION,
                .padding = 0
        };

        return fuse_session_new_versioned(args, op, op_size, &version,
                                          userdata);
}


So idea and suggestion Miklos for FUSE_CAP_AUTO_INVAL_DATA was to chage
the default based on FUSE_USE_VERSION. We can do the same for
FUSE_CAP_EXPORT_SUPPORT.


The initial patch to add in that version into libfuse as another
function argument got really complex in the high level layer and then QA
team at DDN figure out that disabling FUSE_CAP_AUTO_INVAL_DATA actually
triggers another data corruption related xftest error (reproducible with
passthrough_hp) and I didn't have time to follow up that chain of issues
- got stalled for now, but I need to resume it (unless someone else
wants to work on it).


Thanks,
Bernd