by Hi,
some of you might perhaps have experienced the same problem as we have
here - writing from a Linux machine to a directory that is NFS-mounted
from a Solaris, SunOS or OSF/1 system is _lots_ slower than writing to a
directory that is mounted from another Linux system. We are not able
to achieve NFS write rates to OSF/1 of more than ca. 200 kB/sec. over a
155 MBit/sec ATM line, whereas ftp, rcp etc. transfers run at 8-10 _M_B/sec. !
We did the appropriate rsize/wsize tuning and used 8192 for each on all
NFS mounts. The Linux system in question is running a 2.0.29 kernel with
Werner Almesberger's ATM 0.31, the machine on the other end is a DEC
AlphaServer 2100 running Digital Unix (OSF/1) 4.0d. The problems are also
reproducible when using a UltraSparc running Solaris 2.6 on 100BTX ethernet
as server with a Linux system on the same fast ethernet switch.
I'm now trying to find the reason for the slowdown by analysing tcpdump
output for the NFS transfers on an otherwise idle network. As I'm no
NFS expert, I'd be happy if you lend me a helping hand ...
Some people kindly suggested that this was effectively a problem with
writing to a directory that was mounted from a server running NFS V3,
but the same effects seem to occur when writing to a SunOS 4.1.4 NFS server
which is NFS V2 only.
My test setup is currently a Linux system running Linux 2.1.101 (called
velox) that mounts a directory from
1. a SparcStation IPC (sunbeam) running SunOS 4.1.4 (i.e., NFS V2 only)
2. another Linux/intel system (isis) running 2.0.33
(I'm currently running the tests at home on a 10 MBit network, but I'm
observing similar slowdowns here ! I'll run the same tests on our ATM network
on Friday ...)
The first major difference in the tcpdump output I can observe is:
Writes to the SparcStation give me the following output:
03:04:41.538907 velox.unix-ag.org.66760000 > sunbeam.unix-ag.org.nfs: 1472
Writes to the Linux system produce the following:
03:05:42.003120 velox.unix-ag.org.ae7c0000 > isis.unix-ag.org.nfs: 1472
So, the difference is that transfers to the Linux system have an unknown
file handle. Does anyone have an explanation for this behaviour ?
regards,