Umm.. "cp" should really do copies in wsize chunks, so Linux NFS
shouldn't actually be any worse than others when you just do a "cp". The
Linux NFS deficiencies show up in other things: programs that do lots of
small writes like the linker etc (and there aren't really that many
programs that do it, because the stdio library works pretty well in doing
the write merging itself - but as/ld do fseek's that counteract the Linux
stdio implementation).
Are you _sure_ you have "rsize=8192,wsize=8192" in your /etc/fstab for
the NFS mountpoint options? You should _really_ see a lot better
performance than you do with plain "cp".
> Normally, our Linux users are dealing with small files or are working on
> the local disk, so NFS is hardly a variable. However, when we try to
> compile our project software on a Linux system, whereby the object files,
> libraries, and executables are written back to the NFS server, the delay
> is quite noticeable.
Yes. as/ld really shows the problem. Especially with NFS servers that do
(correctly) synchronous NFS writes. Then the stdio library isn't able to
do large write system calls, and the current Linux NFS client will do a
lot of small writes.
Most(?) NFS servers can be configured to do NFS writes asynchronously:
that's not good if the server goes down in the middle of a write, but
with NFS not being exactly 100% reliable anyway it can often be worth it,
especially if you feel safe about your server (ie don't do this if your
NFS server is running Solaris 2.1 ;-). Check your NFS server setup..
> Or when a user quits out of Netscape, and it fiddles
> with the cache directory, which is done via NFS, the delay is VERY
> noticeable. We began the practice a long time ago of compiling the project
> software locally and then moving the objects, libraries, and executables
> back to the NFS server with ftp or something similar.
You should be able to use "cp" to move them back, but for some reason
your cp performance is bad too. Check your wsize setting..
> I've thought about potential hardware problems and just don't see what it
> could be. When the project software is compiled locally, the compile is
> VERY quick, competing with or even beating the HP, Solaris, and AIX
> systems. NFS reading and other network activities seem -- from the user
> perspective -- to be just as fast as our other systems. It's just NFS
> writing which is the bottleneck, from the "data" above and the user
> perspective.
NFS reading is pretty fast, and indeed NFS write performance should these
days be the only performance bottleneck. You seem to be hit worse by it
than most places, though, so I suspect you also have something not
configured optimally.
> I can't imagine that Linux is that slow on NFS writing; I can't imagine
> that the developers would tolerate it. If anyone has any ideas or feedback
> on this, I'd appreciate it.
Linux NFS writes really _are_ slower than other UNIXes, no question about
it. Linux does no write merging at all, and Linux also does all writes
totally synchronously. The lack of write merging means that linux
performs very badly for lots of small "write()" requests. The synchronous
nature of Linux NFS writes also means that Linux does very badly if the
NFS server latency is high (even if the throughput of the server would be
ok, if the latency for individual requests is bad the Linux client NFS
performance suffers a lot).
Linus