On Tue, Jan 11, 2022 at 02:43:37PM -0500, J. Bruce Fields wrote: > On Mon, Jan 10, 2022 at 07:44:16PM +0100, Richard Weinberger wrote: > > rpc.mountd could: > > a) re-use the fsid from the original NFS server. > > Beside of requesting this information, the problem with that approach is > > that the original fsid might conflict with an existing export. > > b) derive the fsid from stat->st_dev. > > c) allocate a free fsid. > > > > One use case to consider is load balancing. When multiple NFS servers re-export > > a NFS mount, they need to use the same fsid for crossed mounts. I guess if rpc.mountd kept an on-disk database of fsid's, it wouldn't be too big a deal to later enhance that with the option of a distributed database. So I'm leaning towards picking a random fsid and sticking it in a database. When you encouter a new filesystem you'd need to make sure the addition of a new entry is atomic and persistent before returning to knfsd. It'd be nice if mountd had an easy way to query the on-the-wire fsid from userspace, and then you could index entries on the fsid. Absent that, maybe just indexing on server and path would be good enough. I'm not sure how NFS's st_dev's are generated. I think they might depend on stuff that isn't necessarily the same on each boot (like the order the NFS filesystems were mounted in), so they wouldn't work. --b. > > So I'm a little puzzled which approach is best. What do you think? > > > > Known issues: > > - Only tested with NFSv3 (both server and client) so far. > > > > [0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2 > > > > Richard Weinberger (3): > > NFSD: Teach nfsd_mountpoint() auto mounts > > fs: namei: Allow follow_down() to uncover auto mounts > > NFS: nfs_encode_fh: Remove S_AUTOMOUNT check > > > > fs/namei.c | 2 +- > > fs/nfs/export.c | 5 ----- > > fs/nfsd/vfs.c | 2 +- > > 3 files changed, 2 insertions(+), 7 deletions(-) > > > > -- > > 2.26.2
