Managing NFS and NIS, 2nd Edition - Mike Eisler [263]
These values are used by the NFS async threads and are completely independent of buffer sizes internal to any client-side processes. An application that writes 400-byte buffers, writing to a filesystem mounted with wsize=4096, does not cause an NFS write request to be sent to the server until the 11th write is performed.
Here is an example of mounting an NFS filesystem with the read and write buffer sizes reduced to 2048 bytes:
# mount -o rsize=2048,wsize=2048 wahoo:/export/home /mnt
Decreasing the NFS buffer size has the undesirable effect of increasing the load on the server and sending more packets on the network to read or write a given buffer. The size of the actual packets on the network does not change, but the number of IP packets composing a single NFS buffer decreases as the rsize and wsize are decreased. For example, an 8KB NFS buffer is divided into five IP packets of about 1500 bytes, and a sixth packet with the remaining data bytes. If the write size is set to 2048 bytes, only two IP packets are needed.
The problem lies in the number of packets required to transfer the same amount of data. Table 18-2 shows the number of IP packets required to copy a file for various NFS read buffer sizes.
Table 18-2. IP packets, RPC requests as function of NFS buffer size
File Size
IP Packets/RPC Calls
rsize
rsize
rsize
rsize
(kbytes)
1024
2048
4096
8192
1
1/1
1/1
1/1
1/1
2
2/2
2/1
2/1
2/1
4
4/4
4/2
3/1
3/1
8
8/8
8/4
6/2
6/1
As the file size increases, transfers with smaller NFS buffer sizes send more IP packets to the server. The number of packets will be the same for 4096- and 8192-byte buffers, but for file sizes over 4K, setting rsize=4096 always requires twice as many RPC calls to the server. The increased network traffic adds to the very problem for which the buffer size change was compensating, and the additional RPC calls further load the server. Due to the increased server load, it is sometimes necessary to increase the RPC timeout parameter when decreasing NFS buffer sizes. Again, we encourage you to use NFS over TCP when possible and avoid having to worry about the NFS buffer sizes.
* * *
[3] One example is the lack of NFS over TCP support for your client or server.
[4] This refers to Version 2.2.14-5 of the Linux kernel.
NFS over wide-area networks
NFS over wide-area networks (WANs) greatly benefits when it is run over the TCP transport. NFS over TCP is preferred when the traffic runs over error-prone or lossy networks. In addition, the reliable nature of TCP allows NFS to transmit larger packets over this type of network with fewer retransmissions.
Although NFS over TCP is recommended for use over WANs, you may have to run NFS over UDP across the WAN if either your client or server does not support NFS over TCP. When running NFS over UDP across WANs, you must adjust the buffer sizes and timeouts manually to account for the differences between the wide-area and the local-area network. Decrease the rsize and wsize to match the MTU of the slowest wide-area link you traverse with the mount. While this greatly increases the number of RPC requests that are needed to move a given part of a file, it is the most social approach to running NFS over a WAN.
If you use the default 32KB NFS Version 3 buffer, you send long trains of maximum sized packets over the wide-area link. Your NFS requests will be competing for bandwidth with other, interactive users' packets, and the NFS packet trains are likely to crowd the rlogin and telnet packets. Sending a 32 KB buffer over a 128 kbps ISDN line takes about two seconds. Writing a small file ties up the WAN link for several seconds, potentially infuriating interactive users who do not get keyboard echo during that time. Reducing the NFS buffer size forces your NFS client to wait for replies after each short burst of packets, giving bandwidth back to other WAN users.
In addition