public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Bernd Schubert <bschubert@ddn.com>,
	Luis Henriques <luis@igalia.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Amir Goldstein <amir73il@gmail.com>, Kevin Chen <kchen@ddn.com>,
	Horst Birthelmer <hbirthelmer@ddn.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matt Harvey <mharvey@jumptrading.com>,
	"kernel-dev@igalia.com" <kernel-dev@igalia.com>
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation
Date: Tue, 16 Dec 2025 17:00:46 -0800	[thread overview]
Message-ID: <20251217010046.GC7705@frogsfrogsfrogs> (raw)
In-Reply-To: <CAJnrk1a8nFhws6L61QSw21A4uR=67JSW+PyDF7jBH-YYFS8CEQ@mail.gmail.com>

On Wed, Dec 17, 2025 at 08:32:02AM +0800, Joanne Koong wrote:
> On Tue, Dec 16, 2025 at 4:54 PM Bernd Schubert <bschubert@ddn.com> wrote:
> >
> > On 12/16/25 09:49, Joanne Koong wrote:
> > > On Sat, Dec 13, 2025 at 2:14 AM Luis Henriques <luis@igalia.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@igalia.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.

<-- wakes up from his long slumber

Why wouldn't you use the same handle format for NFS and for fuse server
restarts?  I would think that having separate formats would cause type
confusion and friction.

But that said, the fs implementation (fuse server) gets to decide the
handle format it uses, because they're just binary blobcookies to the
clients.  I think that's why the size is variable.

(Also I might be missing some context, if fuse handles aren't used in
the same places as nfs handles...)

--D

> Thanks,
> Joanne
> 
> >
> >
> > Thanks,
> > Bernd
> 

  reply	other threads:[~2025-12-17  1:00 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 18:12 [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 1/6] fuse: store index of the variable length argument Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 2/6] fuse: move fuse_entry_out structs out of the stack Luis Henriques
2025-12-15 14:03   ` Bernd Schubert
2025-12-16 10:30     ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 3/6] fuse: initial infrastructure for FUSE_LOOKUP_HANDLE support Luis Henriques
2025-12-15 13:36   ` Bernd Schubert
2025-12-15 17:06     ` Amir Goldstein
2025-12-15 17:11       ` Bernd Schubert
2025-12-15 18:09         ` Amir Goldstein
2025-12-15 18:23           ` Bernd Schubert
2025-12-16 10:36           ` Luis Henriques
2025-12-16 10:19   ` Miklos Szeredi
2025-12-16 11:33     ` Luis Henriques
2025-12-16 11:46       ` Miklos Szeredi
2025-12-16 12:02         ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation Luis Henriques
2025-12-15 17:39   ` Bernd Schubert
2025-12-16 11:48     ` Luis Henriques
2025-12-17 10:18       ` Amir Goldstein
2025-12-17 14:45         ` Luis Henriques
2025-12-17 15:02       ` Bernd Schubert
2025-12-17 16:53         ` Luis Henriques
2025-12-16  8:49   ` Joanne Koong
2025-12-16  8:54     ` Bernd Schubert
2025-12-17  0:32       ` Joanne Koong
2025-12-17  1:00         ` Darrick J. Wong [this message]
2025-12-17  2:48           ` Joanne Koong
2025-12-17  9:38             ` Luis Henriques
2025-12-17 10:08               ` Miklos Szeredi
2025-12-17 16:17                 ` Luis Henriques
2025-12-16 10:39   ` Miklos Szeredi
2025-12-16 10:51     ` Amir Goldstein
2025-12-16 11:07       ` Miklos Szeredi
2026-01-09 11:57     ` Luis Henriques
2026-01-09 12:38       ` Miklos Szeredi
2026-01-09 14:45         ` Luis Henriques
2026-01-09 14:56           ` Horst Birthelmer
2026-01-09 17:07             ` Luis Henriques
2026-01-12  7:43               ` Horst Birthelmer
2026-01-09 15:20           ` Miklos Szeredi
2026-01-09 15:03         ` Amir Goldstein
2026-01-09 15:37           ` Miklos Szeredi
2026-01-09 15:56             ` Bernd Schubert
2026-01-09 16:28               ` Miklos Szeredi
2026-01-09 17:16                 ` Luis Henriques
2026-01-09 18:29               ` Amir Goldstein
2026-01-09 19:01                 ` Miklos Szeredi
2026-01-09 19:28                   ` Amir Goldstein
2026-01-09 19:12                 ` Bernd Schubert
2026-01-09 19:55                   ` Horst Birthelmer
2026-01-21 17:56                     ` Luis Henriques
2026-01-21 18:16                       ` Horst Birthelmer
2026-01-21 18:28                         ` Bernd Schubert
2026-01-21 18:36                           ` Horst Birthelmer
2026-01-21 18:49                             ` Bernd Schubert
2026-01-21 19:00                               ` Horst Birthelmer
2026-01-21 19:03                                 ` Bernd Schubert
2026-01-21 19:12                                   ` Horst Birthelmer
2026-01-22  9:52                                     ` Luis Henriques
2026-01-22 10:20                                       ` Horst Birthelmer
2026-01-22 10:35                                         ` Bernd Schubert
2026-01-22 10:53                                         ` Luis Henriques
2026-01-22 10:59                                           ` Horst Birthelmer
2026-01-22 11:25                                             ` Luis Henriques
2026-01-22 11:32                                               ` Bernd Schubert
2026-01-22 12:34                                               ` Horst Birthelmer
2025-12-12 18:12 ` [RFC PATCH v2 5/6] fuse: factor out NFS export related code Luis Henriques
2025-12-14 15:13   ` Amir Goldstein
2025-12-15 12:05     ` Luis Henriques
2025-12-12 18:12 ` [RFC PATCH v2 6/6] fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE Luis Henriques
2025-12-16 10:58   ` Miklos Szeredi
2025-12-16 17:06     ` Luis Henriques
2025-12-16 20:12       ` Horst Birthelmer
2025-12-17 17:02         ` Luis Henriques
2025-12-17 18:02           ` Horst Birthelmer
2025-12-16 11:01   ` Amir Goldstein
2025-12-16 17:26     ` Luis Henriques
2025-12-14 17:02 ` [RFC PATCH v2 0/6] fuse: LOOKUP_HANDLE operation Askar Safin
2025-12-15 12:08   ` Luis Henriques
2025-12-16  0:33     ` Askar Safin
2025-12-16 17:36       ` Luis Henriques
2025-12-16 18:49       ` Bernd Schubert
2025-12-16 22:45         ` Askar Safin
2025-12-25  7:42         ` Askar Safin
2026-01-04 22:38         ` Askar Safin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251217010046.GC7705@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=bschubert@ddn.com \
    --cc=hbirthelmer@ddn.com \
    --cc=joannelkoong@gmail.com \
    --cc=kchen@ddn.com \
    --cc=kernel-dev@igalia.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luis@igalia.com \
    --cc=mharvey@jumptrading.com \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox