Max NFS mounts for a FreeBSD client?

[Robert Watson]

On Fri, 20 Jul 2007, Eric L. Anderson wrote:

> On Sat, Jul 21, 2007 at 10:45:25AM +1000, Norberto Meijome wrote:
>> On Fri, 20 Jul 2007 18:07:37 +0100 (BST)
>> Robert Watson <rwatson at FreeBSD.org> wrote:
>>>
>>> Sounds a bit like something is running out of reserved ports to use -- the
>>> credentials error may mean that a port number >1023 was used for an NFS
>>> connection.  Given that reserved ports start around 600, 420 is about the
>>> right number of sockets to reach 1024.
>>
>> Reserved ports controlled by sysctl :
>>
>> net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 
>> 0
>>
>> although the 600 rwatson mentions seems to be this one:
>>
>> net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600
>>
>> You should be able to tweak these values - as long as you have ephemeral 
>> ports for the rest of your network activity, you should be ok, right?
>
> This sounds like we are on the right track. I verified via netstat that all 
> ports from 600-1023 are being used for NFS after I run my test script.
>
> I can not change lowfirst to any higher amount. I did change lowlast from 
> 600 to 1 and now I can mount more than 1000 NFS mounts. This is great but 
> what kind of side effects am I introducing by making this change?

The issue here, presumably, is that each NFS client mountpoint has (and 
requires) a unique socket, which means a unique TCP/IP or UDP/IP tuple with 
its respective server endpoint.  This is used to demux replies, etc.  With 
TCP/IP NFS mounts, it should be possible, in principle, to be quite a bit more 
conservative in the use of tuples, as reusing a source IP and port number is 
only a problem if there's a collision with another mountpoint using identical 
destination IP and port.  It could be that NFS, perhaps with a bit of help 
from the TCP layer, could be more agressive about reusing existing local port 
numbers rather than using a new one for every mountpoint.  I'm not sure what 
would be involved infrastructure-wise here, and obviously care would have to 
be taken not to break UDP/IP mounts.

Robert N M Watson
Computer Laboratory
University of Cambridge