Mount protocol/showmount vs NFSv4

Sat Nov 12 09:41:12 UTC 2016

On 11/11/16 14:25, Rick Macklem wrote:
> I have just put a patch for umount(8) here that makes it do the Unmount RPC over TCP
> for NFSv3/TCP mounts and not do the Unmount RPC for NFSv4 mounts.
> reviews.freebsd.org/D8503
> 
> Colin, maybe you could review this?

Aside from one very minor bug, it works fine for NFSv4.  But I can't
confirm about other NFS versions.

Colin Percival

> ________________________________________
> From: owner-freebsd-fs at freebsd.org <owner-freebsd-fs at freebsd.org> on behalf of Jason Mader <jmader2 at gmu.edu>
> Sent: Wednesday, November 9, 2016 9:39:19 AM
> To: freebsd-fs at freebsd.org
> Subject: Re: Mount protocol/showmount vs NFSv4
> 
> 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
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 
> 

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid