Slow lines include Modems, ISDN and quite possibly other long distance connections.
This section is based on knowledge about the used protocols but no actual experiments. Please let me hear from you if try this ;-)
The first thing to remember is that NFS is a slow protocol. It has high overhead. Using NFS is almost like using kermit to transfer files. It's slow. Almost anything is faster than NFS. FTP is faster. HTTP is faster. rcp is faster. ssh is faster.
Still determined to try it out? Ok.
NFS' default parameters are for quite fast, low latency, lines. If you use these default parameters over high latency, slow, lines it can cause NFS to report errors, abort operations, pretend that files are shorter than they really are, and act mysteriously in other ways.
The first thing to do is not to use the soft mount
option. This will cause timeouts to return errors to the software,
which will, most likely not handle the situation at all well. This is
a good way to get mysterious failures. Instead use the hard
mount option. When hard is active timeouts causes infinite
retries instead of aborting whatever it was the software wanted to do.
This is what you want. Really.
The next thing to do is to tweak the timeo and retrans
mount options. They are described in the nfs(5) man page, but here is
a copy:
timeo=n The value in tenths of a second before
sending the first retransmission after an
RPC timeout. The default value is 7 tenths
of a second. After the first timeout, the
timeout is doubled after each successive
timeout until a maximum timeout of 60 sec-
onds is reached or the enough retransmis-
sions have occured to cause a major time-
out. Then, if the filesystem is hard
mounted, each new timeout cascade restarts
at twice the initial value of the previous
cascade, again doubling at each retransmis-
sion. The maximum timeout is always 60
seconds. Better overall performance may be
achieved by increasing the timeout when
mounting on a busy network, to a slow
server, or through several routers or gate-
ways.
retrans=n The number of minor timeouts and retrans-
missions that must occur before a major
timeout occurs. The default is 3 timeouts.
When a major timeout occurs, the file oper-
ation is either aborted or a "server not
responding" message is printed on the con-
sole.
In other words: If a reply is not received within the 0.7 second (700ms) timeout the NFS client will repeat the request and double the timeout to 1.4 seconds. If the reply does not appear within the 1.4 seconds the request is repeated again and the timeout doubled again, to 2.8 seconds.
A lines speed can be measured with ping with the same packet size as your rsize/wsize options.
$ ping -s 8192 lugulbanda PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes 8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms 8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms 8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms --- lugulbanda.uio.no ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 14.9/15.1/15.9 ms
The time here is how long the ping packet took to get back and
forth to lugulbanda. 15ms is quite fast. Over a 28.000 bps line you
can expect something like 4000-5000ms, and if the line is otherwise
loaded this time will be even higher, easily double. When this time
is high we say that there is 'high latency'. Generally, for larger
packets and for more loaded lines the latency will tend to increase.
Increase timeo suitably for your line and load. And since the
latency increases when you use the line for other things: If you ever
want to use FTP and NFS at the same time you should try measuring ping
times while using FTP to transfer files and increase timeo to
match your line latency.