NFS export discloses pool name

[adrianstephens]

I see this question was asked 5 years ago, without a positive outcome.

I have TrueNas Scale (latest). I have a pool on spinning rust, which is mounted by a bunch of nfs clients.
I needed to improve performance, so I added some NVME memory, create a new faster pool from these and moved my
critical dataset to this pool.

BUT ...
Because the NFS export includes the pool name, I now have to go and edit files on multiple clients.
Oh, and I just up/downed some docker containers on a different server and discovered yet more references to the pool name.

My experience in software engineering tells me that requiring the NFS clients to know the name of the pool (embedded in the exported mount point)
is a bad idea, because it creates a dependency that should not exist.

I'd be prepared to put some effort into resolving this, such as creating mount points under /mnt and "mount --bind" the zfs mount directory to this directory.
I think NFS would be totally cool with this. It would probably also be cool with just a symbolic link.

BUT ...
The NFS share middleware restricts the shared directory to be a zfs mount point. It goes out of its way to prevent me doing what is entirely reasonable
in order to avoid the problem I've described.

I might get "it's all NFS's fault", "it's meant to work like this", "everybody else has no problem with this, so why should you" responses.
But this restriction is IMHO unreasonable and has been complained about with no fix, and those are non-reasons, IMHO.

 

[jgreco]

NFS has always worked like this. This is a general Sun Microsystems thing and has been this way since the beginnings of NFS.

There was a time when a NFS server would have been a five or maybe six figure dedicated system, and the software was written with that mindset. This goes to the inner workings of some of the protocol stuff, both because designers couldn't imagine a future where a $35 embedded system like the Raspberry Pi could serve NFS, but also because added layers of indirection and abstraction were felt in terms of impact on performance.

This doesn't mean that nobody cared, it just means that they used a solution that you've not mentioned. The automounter was intended to be the solution to be able to do this kind of mapping, it works on the client side, and allows you to use maps distributed by a directory service like LDAP or YP. This doesn't eliminate the visibility of the path at the client level (which many people would find objectionable), but does generate similar functionality results when modifying mounts.

The developers are unlikely to tackle your request.

Both upstream operating systems (FreeBSD, Linux) follow the NFS standard. Existing implementations include visibility of the absolute path on the NFS server by the client. There's more than 30 years of history to this. There's already a way to deal with the underlying issue you're asking about. And the developers for TrueNAS are not likely to rewrite core bits of two different operating systems just to correct for what essentially is a cosmetic issue.

Some years ago, I scolded them for the incorrect use of /mnt/ as a mountpoint; FHS and BSD SMM both indicate that this is intended for temporarily mounted filesystems. That didn't go anywhere either even though it was technically correct. Inertia is a powerful force.