[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJnrk1a8nFhws6L61QSw21A4uR=67JSW+PyDF7jBH-YYFS8CEQ@mail.gmail.com>
Date: Wed, 17 Dec 2025 08:32:02 +0800
From: Joanne Koong <joannelkoong@...il.com>
To: Bernd Schubert <bschubert@....com>
Cc: Luis Henriques <luis@...lia.com>, Miklos Szeredi <miklos@...redi.hu>,
Amir Goldstein <amir73il@...il.com>, "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 Tue, Dec 16, 2025 at 4:54 PM Bernd Schubert <bschubert@....com> wrote:
>
> On 12/16/25 09:49, Joanne Koong wrote:
> > On Sat, Dec 13, 2025 at 2:14 AM Luis Henriques <luis@...lia.com> wrote:
> >>
> >> The implementation of LOOKUP_HANDLE modifies the LOOKUP operation to include
> >> an extra inarg: the file handle for the parent directory (if it is
> >> available). Also, because fuse_entry_out now has a extra variable size
> >> struct (the actual handle), it also sets the out_argvar flag to true.
> >>
> >> Most of the other modifications in this patch are a fallout from these
> >> changes: because fuse_entry_out has been modified to include a variable size
> >> struct, every operation that receives such a parameter have to take this
> >> into account:
> >>
> >> CREATE, LINK, LOOKUP, MKDIR, MKNOD, READDIRPLUS, SYMLINK, TMPFILE
> >>
> >> Signed-off-by: Luis Henriques <luis@...lia.com>
> >> ---
> >> fs/fuse/dev.c | 16 +++++++
> >> fs/fuse/dir.c | 87 ++++++++++++++++++++++++++++++---------
> >> fs/fuse/fuse_i.h | 34 +++++++++++++--
> >> fs/fuse/inode.c | 69 +++++++++++++++++++++++++++----
> >> fs/fuse/readdir.c | 10 ++---
> >> include/uapi/linux/fuse.h | 8 ++++
> >> 6 files changed, 189 insertions(+), 35 deletions(-)
> >>
> >
> > Could you explain why the file handle size needs to be dynamically set
> > by the server instead of just from the kernel-side stipulating that
> > the file handle size is FUSE_HANDLE_SZ (eg 128 bytes)? It seems to me
> > like that would simplify a lot of the code logic here.
>
> It would be quite a waste if one only needs something like 12 or 16
> bytes, wouldn't it? 128 is the upper limit, but most file systems won't
> need that much.
Ah, I was looking at patch 5 + 6 and thought the use of the lookup
handle was for servers that want to pass it to NFS. But just read
through the previous threads and see now it's for adding server
restart. That makes sense, thanks for clarifying.
Thanks,
Joanne
>
>
> Thanks,
> Bernd
Powered by blists - more mailing lists