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 <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
