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.
