[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZlSzotIrVPGrC6vt@infradead.org>
Date: Mon, 27 May 2024 09:24:02 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Jan Kara <jack@...e.cz>
Cc: Christoph Hellwig <hch@...radead.org>, Aleksa Sarai <cyphar@...har.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Jeff Layton <jlayton@...nel.org>,
Amir Goldstein <amir73il@...il.com>,
Alexander Aring <alex.aring@...il.com>,
linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
name_to_handle_at(2)
On Mon, May 27, 2024 at 03:34:30PM +0200, Jan Kara wrote:
> So I was wondering how this is actually working in practice. Checking the
> code, NFS server is (based on configuration in /etc/exports) either using
> device number as the filesystem identifier or fsid / uuid as specified in
> /etc/exports.
Yes, it's a rather suboptimal implementation.
> So returning the 64-bit mount ID from name_to_handle_at() weasels out of
> these "how to identify arbitrary superblock" problems by giving userspace a
> reasonably reliable way to generate this superblock identifier itself. I'm
> fully open to less errorprone API for this but at this point I don't see it
> so changing the mount ID returned from name_to_handle_at() to 64-bit unique
> one seems like a sane practical choice to me...
Well, how about we fix the thing for real:
- allow file systems to provide a uniqueu identifier of at least
uuid size (16 bytes) in the superblock or through an export operation
- for non-persistent file systems allow to generate one at boot time
using the normal uuid generation helpers
- add a new flag to name_to_handle_at/open_by_handle_at to include it
in the file handle, and thus make the file handle work more like
the normal file handle
- add code to nfsd to directly make use of this
This would solve all the problems in this proposal as well as all the
obvious ones it doesn't solve.
Powered by blists - more mailing lists