Re: Massive NFS problems on large cluster with large number of mounts

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Fri, 2008-08-15 at 16:34 -0400, Chuck Lever wrote:
> Trond, NFS_MOUNT_FLAGMASK is used in nfs_init_server() and
> nfs4_init_server() for both legacy binary and text-based mounts.  This
> needs to be moved to a legacy-only path if we want to use the
> high-order 16 bits in the 'flags' field for text-based mounts.

We definitely want to do this. The point of introducing text-based
mounts was to allow us to add functionality without having to worry
about legacy binary mount formats. The mask should be there in order to
ensure that binary formats don't start enabling features that they
cannot support. There is no justification for applying it to the text
mount path.

> I reviewed the Solaris mount_nfs(1M) man page (I hope this is the
> correct place to look).  There doesn't appear to be a mount option to
> make Solaris NFS clients use a reserved port. Not sure if there's some
> other UI (like a config file in /etc).
> 
> FreeBSD and Mac OS both use "[no]resvport" as Mike pointed out
> earlier.  That's my vote for the new Linux mount option

Agreed: we should try to follow the standard set by existing
implementations wherever we can...

> [ Sidebar: I found this in the Mac OS mount_nfs(8) man page:
> 
>      noconn  Do not connect UDP sockets.  For UDP mount points, do not do a
>              connect(2).  This must be used for servers that do not reply to
>              requests from the standard NFS port number 2049.  It may also be
>              required for servers with more than one IP address if replies come
>              from an address other than the one specified in the requests.
> 
> An interesting consideration if we support connected UDP sockets for
> NFS at some point. ]

Hmm... Well, we already don't support servers that reply to a UDP
request from a different IP address, and I can't see that we should
really care. Aside from the fact that most clients will use TCP by
default these days, it is quite trivial for a server to track on which
interface a UDP request was received, and ensure that the reply is sent
on the same interface. In fact, we already do this in the Linux server
AFAICR...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com