Mount protocol/showmount vs NFSv4

[Jason Mader]

On 6 Nov 2016, at 15:51, Rick Macklem wrote:

> NFSv2 and NFSv3 use a protocol called Mount (implemented by mountd) to 
> try and
> track mounts/unmounts and report exports to clients. Except for the 
> one RPC that
> maps a directory path to a File Handle, none of this is needed by NFS. 
> The rest is
> reported (and never guaranteed to be correct) by showmount(8).
>
> There are a couple of issues related to the Mount protocol.
> 1 - It uses a dynamically assigned port# via rpcbind (which means 
> hassles for firewalls, etc).
> 2 - umount(8) currently assumes that it is supported over UDP and 
> fails if it is
>      configured to work over TCP only.
> 3 - A recent issue was reported where there is a delay for systems 
> configured for IP6
>      only related to the handling of localhost. (I'll admit I didn't 
> understand quite why
>      there was this 2sec delay, but others familiar with networking 
> confirmed it was
>      correct behaviour.)
>
> NFSv4 doesn't use the Mount protocol at all and does everything via 
> the NFSv4 protocol
> serviced at port #2049.
> I have never done anything about this, since most were still using 
> NFSv3, but it seems
> that maybe something should be done now?
> - What do people think of having a new option on mountd(8) that would 
> be used for
>    NFSv4 only servers that disables servicing of Mount RPCs.
>    --> This would imply that "showmount" would no longer work for it.
>          --> Note that "showmount" returns nothing useful for NFSv4 
> mounts, since mountd
>                doesn't know about NFSv4 mounts (and the NFSv4 server 
> doesn't know either,
>                because there is no concept of a "mount" in the NFSv4 
> protocol).
>         --> It does imply that "showmount -e" will stop working and 
> that info might be
>               useful w.r.t. NFSv4 servers.
>
> Umount(8) for NFSv3 is a slightly different problem. It has (for 
> 30years) just talked to
> UDP. If that doesn't work, there is a delay, but the umount still 
> works (and the info
> from "showmount" is no longer correct, but it is never guaranteed to 
> be correct anyhow).
> - Should umount(8) use TCP if the NFSv3 mount is using TCP?
>   --> This could cause it to break for a case where only UDP is 
> supported for the Mount
>         protocol on the server, but that would be a rare/broken case, 
> I'd guess.
>
> Anyhow, any/all comments on this would be appreciated, rick

I agree that the NFS client can be improved to not try to contact the 
RPC server for an NFSv4 mount. The Linux NFS client already doesn’t.

A possible bug: the NFS server picks up it’s NFSv4-only behavior from 
vfs.nfsd.server_min_nfsvers, but nfsd still registers 2 & 3 with 
rpcbind,

     100003    2    tcp       0.0.0.0.8.1            nfs        
superuser
     100003    3    tcp       0.0.0.0.8.1            nfs        
superuser
     100003    2    tcp6      ::.8.1                 nfs        
superuser
     100003    3    tcp6      ::.8.1                 nfs        
superuser

In nfsd.c the value of vfs.nfsd.server_min_nfsvers is not checked before 
registering sockets with rpcbind.

In my use, I would like mountd to adjust it’s behavior when 
vfs.nfsd.server_min_nfsvers > 3 and, by default, only listen on 
127.0.0.1 and ::1. When additional addresses are needed they could then 
be added by the existing -h flag. Then mountd may not need to register 
the sockets with rpcbind at all. Then starting rpcbind could be 
eliminated to run an NFSv4-only server. (Guard the force_depend rpcbind 
in mountd and nfsd command scripts)

`showmount -e` will still want to contact an RPC server though.

Even when NFSv4-only, I’m currently using the output of `showmount -E` 
to obtain the list of filesystems that already are automatically 
exported with the ZFS property sharenfs. This is because I need an 
additional -network flag on each filesystem, scripted when 
/etc/zfs/exports changes, and haven’t found a better way to get two 
-network flags per filesystem. There is a possible improvement to ZFS 
when sharenfs has multiple -network flags, to write them as additional 
lines in /etc/zfs/exports. Then I would have no need for showmount at 
all, or for it’s behavior to be changed.

But the two minute delay on `showmount -e` happens when rpcbind is 
started with the -6 flag. This is being called correct behavior, but it 
is rather odd behavior on the transition to IPv6-only.

-- 
Jason Mader