Messages in this thread | | | Date | Sun, 14 Apr 1996 10:43:19 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: Linux-1.3.88 - Code Freeze |
| |
On Sat, 13 Apr 1996, John E. Davis wrote: > > On Sat, 13 Apr 1996 17:02:12 +0300 (EET DST), Linus Torvalds <torvalds@cs.helsinki.fi> > wrote: > : The code-freeze means that I once more enter "bug-fixes only" mode, and > : don't even try to send me new features (I'd hate to fall for them ;-). > : There are obviously things we could do better (write-side NFS caching > : etc), but believe it or not, there is life after 2.0 too.. > > Is the lack of ``write-side NFS caching'' the reason that writing to an NFS > mounted disk is slow by about a factor of 2 compared with other versions of > Unix? (This is with a 1.3.79 kernel).
Probably. It depends on what your setup is, and especially on _how_ the programs do their writes.
Check out that you have rsize=8192 and wsize=8192, and then the write-side caching shouldn't matter for most programs that use buffered stdio.
However, programs that do not use buffered stdio (do raw "write()" system calls with small buffers), or that use a line-buffered approach will be hurt by the lack of write-side caching (well, not so much caching as "coalescing" of write requests, although the way I'd do it would be to use the page cache to do the coalescing which is why I call it caching).
In short, for many programs there is not much of a difference. Sadly, some programs are especially stupid, and one exacmple of this is "as", if I remember correctly. At least some versions of the GNU assembler did a "write()" system call for every instruction, so you ended up with _huge_ amounts of NFS packets. Now, that's arguably a misfeature in the program, but on the other hand we _could_ be faster.
Anyway, the first thing you should check out is that you use a rsize and wsize of 8192, not the default 1024. Just add "rsize=8192,wsize=8192" to your NFS mount options in your /etc/fstab if you don't have them already.
And remember, there _is_ life after 2.0. We'll get this issue worked out soon enough, so don't be too worried about it.
Linus
| |