more weird bugs with mmap-ing via NFS

Jon Dama jon at
Wed Mar 22 00:46:50 UTC 2006

>From Mikhail Teterin <mi+mx at>, Tue, Mar 21, 2006 at 06:58:01PM -0500:
> I'll try the TCP mount, workaround. If it helps, we can assume, our UDP NFS is 
> broken for sustained high bandwidth writes :-(

What?  I think you misunderstood.  UDP NFS fairs poorly under 
network congestion; it has nothing to do with FreeBSD.  Any 
iota of frame-loss will induce costly time-outs and hang-ups
and quickly become intolerable.

Let us consider a few cases:
1) a server attached with 1Gb ethernet and clients with 100Mb 
   connections.  Server begins sending data to a client.   The
   client pipe is narrower and the switch begins to buffer the
   frames.  Switches _do not_ have very much buffer space.  A 
   high-end switch may have 2MB.  Likely some of this can be
   shared between ports; some will be reserved per port.  Let us
   assume all of the memory is on.

   d(Memory_Used)/dt = 1000Mb/s - 100Mb/s = 900MB/s.  Thus... in 
   less than 10ms the switch will run out of buffer space... and
   then *drop* frames.

   oops.  bye-bye UDP NFS.

2) a server is attached with 1Gb ethernet and the clients with 1Gb
   ethernet.  Multiple clients write to the NFS server simultanteously...

Okay, okay.  It isn't quite this bad because there will only be so many 
outstanding requests, but it doesn't take many clients actively contending 
for a shared resource (the link to the server) to cause glitches...
This is precisely the problem TCP was intended to solve.  NFS UDP is
an antiquated solution to TCP overhead on the underpowered machines of 
yesteryear.  NFS UDP has essentially no use on modern hardware.

More information about the freebsd-stable mailing list