Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 6 Nov 2016 20:51:25 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>
Subject:   Mount protocol/showmount vs NFSv4
Message-ID:  <YTXPR01MB01893AD86D5F1280DC63CA4BDDA40@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>

next in thread | raw e-mail | index | archive | help
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 f=
or 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 configur=
ed for IP6
     only related to the handling of localhost. (I'll admit I didn't unders=
tand quite why
     there was this 2sec delay, but others familiar with networking confirm=
ed it was
     correct behaviour.)

NFSv4 doesn't use the Mount protocol at all and does everything via the NFS=
v4 protocol
serviced at port #2049.
I have never done anything about this, since most were still using NFSv3, b=
ut it seems
that maybe something should be done now?
- What do people think of having a new option on mountd(8) that would be us=
ed 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 protoc=
ol).
        --> It does imply that "showmount -e" will stop working and that in=
fo might be
              useful w.r.t. NFSv4 servers.

Umount(8) for NFSv3 is a slightly different problem. It has (for 30years) j=
ust talked to
UDP. If that doesn't work, there is a delay, but the umount still works (an=
d the info
from "showmount" is no longer correct, but it is never guaranteed to be cor=
rect 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 f=
or the Mount
        protocol on the server, but that would be a rare/broken case, I'd g=
uess.

Anyhow, any/all comments on this would be appreciated, rick





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB01893AD86D5F1280DC63CA4BDDA40>