Date: Fri, 11 Nov 2016 22:25:35 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Jason Mader <jmader2@gmu.edu>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Mount protocol/showmount vs NFSv4 Message-ID: <YTXPR01MB01892FA1218B18B14F2E6BD5DDBB0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu> References: <YTXPR01MB01893AD86D5F1280DC63CA4BDDA40@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <46BE3C1E-BC1B-4D48-95D4-45F61F7AD238@gmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Thanks, rick
________________________________________
From: owner-freebsd-fs@freebsd.org <owner-freebsd-fs@freebsd.org> on behalf=
of Jason Mader <jmader2@gmu.edu>
Sent: Wednesday, November 9, 2016 9:39:19 AM
To: freebsd-fs@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=92t.
A possible bug: the NFS server picks up it=92s 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=92s 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=92m 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=92t 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=92s 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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB01892FA1218B18B14F2E6BD5DDBB0>