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.