Mount protocol/showmount vs NFSv4

Rick Macklem rmacklem at uoguelph.ca
Mon Nov 7 20:48:25 UTC 2016


Doug Rabson wrote:
>
>It seems like a reasonably good idea to disable disable the mount protocol if its not >needed. For NFSv4, mountd really doesn't do much other than read the exports files and >push them into the kernel - does it even need to keep running after that for NFSv4?
Probably so that /etc/exports can be reloaded, but that would be the only reason,
assuming "showmount" isn't being supported.
>
>On the subject of showmount, we do have some information on connected clients which I >suppose you could try to expose but its probably not worth the effort.
Some clients (Solaris, I think) don't maintain TCP connections for inactive mounts, so
the connections aren't a direct indication of mounts.

Thanks for the comments, rick

On 6 November 2016 at 20:51, Rick Macklem <rmacklem at uoguelph.ca<mailto:rmacklem at uoguelph.ca>> wrote:
Hi,

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


_______________________________________________
freebsd-fs at freebsd.org<mailto: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<mailto:freebsd-fs-unsubscribe at freebsd.org>"



More information about the freebsd-fs mailing list