home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / clients / 260 < prev    next >
Encoding:
Text File  |  1993-01-07  |  1.5 KB  |  37 lines

  1. Newsgroups: comp.client-server
  2. Path: sparky!uunet!mcsun!sun4nl!dascnl!bambam!gjm
  3. From: gjm@dasc.nl (Gijs J. Mos)
  4. Subject: Re: NFS and RPC
  5. Message-ID: <gjm.726403310@bambam>
  6. Keywords: NFS,RPC
  7. Organization: Data Sciences B.V.
  8. References: <1992Dec30.155939.13344@spectrum.xerox.com> <1ig6ltINNe2d@shelley.u.washington.edu> <16274@auspex-gw.auspex.com>
  9. Date: Thu, 7 Jan 1993 10:41:50 GMT
  10. Lines: 24
  11.  
  12. guy@Auspex.COM (Guy Harris) writes:
  13.  
  14. >>NFS is "stateless",
  15.  
  16. >True (modulo debate about the meaning of "stateless").
  17.  
  18. >>which means that each "write" from the client side
  19. >>will result in an open/write/close on the server.  The opens/closes slow
  20. >>it down quite a bit over the file-transfers you were comparing it to.
  21.  
  22. >False, at least in the UNIX NFS servers I've seen.  In those, there
  23. >aren't any "open"s or "close"s done by the NFS server.  Instead, the NFS
  24. [stuff describing UNIX implementations deleted]
  25.  
  26. On Stratus NFS the NFS server regularly opens the file. This is indeed a very
  27. slow operation that involves directory access. To make things usable the
  28. NFS server doesn't close files immediately after each write or read. Instead
  29. the files are kept open for a certain period. The time files are kept open is
  30. an installation parameter for the NFS server.  It is normally 30 seconds
  31. or so. This means that a write/read benchmark that writes/reads a stream
  32. of blocks as fast as it can incurs only one open.
  33.  
  34. Gijs Mos
  35. gjm@dasc.nl
  36. #include <stddisclaimer.h>       This might not be the view of my employer.
  37.