home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / ultrix / 8207 < prev    next >
Encoding:
Text File  |  1992-11-10  |  2.2 KB  |  45 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
  3. From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
  4. Subject: Re: Is local caching configurable?
  5. Message-ID: <1992Nov10.143148.18071@decuac.dec.com>
  6. Sender: news@decuac.dec.com (USENET News System)
  7. Nntp-Posting-Host: hussar.dco.dec.com
  8. Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
  9. References: <776@sandia.UUCP> <1992Nov10.071109.19304@arb-phys.uni-dortmund.de>
  10. Date: Tue, 10 Nov 1992 14:31:48 GMT
  11. Lines: 32
  12.  
  13. wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
  14. >This is quite normal, the data are cached three times when writing on NFS;
  15. >first normal Unix write cache; second the NFS server process and third
  16. >the write cache on the server.
  17.  
  18.     On the client, writes are cached only until the block is
  19. full, to prevent abysmal performance on small writes. Once the block
  20. is full, the client sends the NFS write request to the server, and
  21. waits for the response. In true non-protocol-violating-NFS the server
  22. does not ACK the write until it is committed to stable storage. Your
  23. remark implies that the server can cache the write like a normal
  24. UNIX filesystem asynchronous I/O, which is not the case. Some versions
  25. of NFS do this, but they are not adhering strictly to the protocol,
  26. though they gain a great deal in performance that way. The "NFS server
  27. process" (are you referring to nfsd?) is simply a holder process that
  28. is used as a kernel device to block until the I/O completes.
  29.  
  30.  
  31. >Of course you pay for the better write performance via NFS by loading
  32. >the server and using up it's memory. You may speed up your local write
  33. >access by adding more memory (bigger buffer pool) to your machine.
  34.  
  35.     Again, in a true NFS configuration, you're going to be more
  36. bounded by performance of the I/O subsystem on the server than by
  37. the server's memory. If you start using asychronous NFS (in ULTRIX
  38. to do this you have to patch your kernel with unsupported code) you
  39. then start using the buffer cache on the server as a *write* cache
  40. instead of just a read cache. Since ULTRIX has fixed sized buffers,
  41. you don't "use up the server's memory" - but you will affect the
  42. cache access patterns.
  43.  
  44. mjr.
  45.