Hello:
Sorry about the late summary. The orginal question:
Back in 1999 it was reported in the archives that there was a NFS
performance problem between linux intel/alpha and tru64. Has anyone used a
newer linux kernel and have seen this problem fixed or is still a
performance problem today? We are looking at doing adding more linux
around here but, we need good NFS performance.
If NFS is working fine for you what kernel are you using?
Any info would be appreciated.
jim jones
Most people admitted that there is a problem between linux version 2.2.x
and earlier do not have nfsv3 support. the support can be acquired by
applying patches. The info below are patch info that people sent. I have
not applied these yet so cannot speek for success or failure.
As far as I know, current stable release, 2.2.16 still does not have NFSv3
support which most commercial UNIX(including Tru64) does.
If you apply a patch
http://www.fys.uio.no/~trondmy/src/.
that may work.... I have not tested this yet.
As far as I know, you are not going to see any changes unless you are
running a 2.4 pre release kernel, which is supposed to have NFS v3 code
finally.
There are supposed to be v3 patches for Linux 2.2 available.
http://www.CSUA.Berkeley.EDU/~gam3/knfsd/
http://www.fys.uio.no/~trondmy/src/
I mainly use NFS from a Tru64 server with Linux clients. This works
"well enough" for my home directory and mail and such, but I do use a
large local scratch area for big compiles and other disk intensive
stuff.
I am running Linux 2.2.16 NFS patches from
http://nfs.sourceforge.net/
which gives me NFSv3 client and servers. The patches are a bit
confusing to install, so if you want to try them and need help let me
know. Rumor is the patches will be integrated into 2.2.18 or 2.2.19.
Here are some benchmarks I ran to test performance. NFSstones is
designed for server testing, so I don't know how valid it is measuring
client speed. The NFS and http times are how long it took to copy a
100MB file on the server to /dev/null on the client using each
protocol. All of these tests are running over 100Mb switched ethernet
so 14 seconds to copy the file is about 1/3 wire speed.
Linux with NFSv2 (2.2.16 unpatched) client and Tru64 4.0d server
340.389059 NFSstones/second
2:02.51 http (why is this so long, same problem with rsh, too)
0:56.02 nfs
Linux with NFSv3 (2.2.16 patched) client and Tru64 4.0d server
900.354474 NFSstones/second
0:14.51 http
0:15.12 nfs
Tru64 4.0d client and Linux 2.2.16+NFS patches server
4787.104315 NFSstones/second
0:21.33 http
0:15.82 nfs
Tru64 4.0d client and Tru64 4.0d server (NFSv3)
2091.503691 NFSstones/second
0:18.23 http
0:19.93 nfs
Linux with NFSv3 (2.2.16 patched) client and Linux 2.2.16+NFS patches
server
1799.728806 NFSstones/second
0:09.42 http
0:20.31 nfs
So what does this show? Mostly that something is wrong with my 2.2.16
unpatched machine. Otherwise, the new NFS client for Linux is faster
than the old one, but still not as good as the Tru64 client, when
connecting to Tru64 servers. On the other hand, the new Linux NFS
server seems to be quit fast.
Is the new NFS good enough for you? I don't know. I certainly
wouldn't want to be doing any disk intensive stuff over any NFS, but
it works well for me for saving and opening files, reading mail, and
mundane stuff.
Received on Fri Sep 08 2000 - 15:21:08 NZST