[16527] in Athena Bugs
Re: NFS parameters in attach.conf
daemon@ATHENA.MIT.EDU (John Hawkinson)
Thu Dec 3 12:30:00 1998
Date: Thu, 3 Dec 1998 12:29:53 -0500
To: Greg Hudson <ghudson@MIT.EDU>
Cc: "Thomas H. Grayson" <thg@MIT.EDU>, bugs@MIT.EDU, network@MIT.EDU,
f_l@MIT.EDU, karen@MIT.EDU, jf@MIT.EDU, phils@MIT.EDU
In-Reply-To: "[16526] in Athena Bugs"
From: John Hawkinson <jhawk@MIT.EDU>
| I think it's probably a mistake for attach to override the system
| defaults for NFS mounts. I will submit a patch to get rid of these
| options and let the system's NFS client decide what buffer sizes to
| use. However, these options do control how a large number of machines
| do the vast majority of their NFS mounts; the network group may
| express an objection to having them send packets which the routers
| will have to fragment.
That can't happen, since the link to the router is no greater than
the ethernet MTU (or the fddi mtu) ;-).
rsize/wsize > ifmtu (1500 for ethernet) causes the sending host to
fragment the packet. This doesn't put any direct burden on the network
infrastructure.
What does happen is that *if* the network infrastructure loses a single
fragment within the 8k IP packet, then the entire 8k packet needs to be
retransmitted. Oh, and the packet needs to be timed out, too.
Conventional wisdom (by some metrics) has been that if you were doing
NFS across a router, it was a bad idea to let your hosts use NFS
rsize/wsizes that were greater than the ifmtu. I'm not sure
I can justify this other than the comment in the previous paragraph.
It should, of course, be noted that it's dangerous to assume that what
generates an improvment for one client necessarily generates an
improvement for all clients (i.e. sure, one person cutting the line
gets to the head of the queue faster, but if everybody cut the line,
the system would just break down).
--jhawk
