home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / ultrix / 8333 < prev    next >
Encoding:
Text File  |  1992-11-15  |  3.5 KB  |  73 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!think.com!spool.mu.edu!sol.ctr.columbia.edu!destroyer!news.iastate.edu!john
  3. From: john@iastate.edu (John Hascall)
  4. Subject: Re: Slow writes to Ultrix 4.3 NFS server
  5. Message-ID: <BxsGJ1.A58@news.iastate.edu>
  6. Keywords: NFS server performance
  7. Sender: news@news.iastate.edu (USENET News System)
  8. Organization: Iowa State University, Ames, IA
  9. References: <leb.721782917@Hypatia> <BxqyCu.791@news.iastate.edu> <sdlhiig@zuni.esd.sgi.com>
  10. Date: Mon, 16 Nov 1992 03:04:12 GMT
  11. Lines: 60
  12.  
  13. attribution-long-gone writes:
  14. }}>}I manage an SGI 4D/340 running IRIX 4.0.1 and a DECstation 5000/125 running
  15. }}>}Ultrix 4.3.
  16.  
  17. john@iastate.edu (John Hascall) writes:
  18. >Anyway, several vendors' NFS servers mis-implement the standard (on purpose).
  19. >The NFS standard requires that writes be done "synchronously".
  20.  
  21. olson@anchor.esd.sgi.com (Dave Olson) writes:
  22. }Well, not actually.  It requires that it be written to 'stable storage'.
  23. }There have been many hundreds of hours spent on arguing this point.  SGI
  24. }feels that our uptime is good enough that by the time it makes it to RAM
  25. }on the server, it is in 'stable storage'.  We also provide an option
  26. }to do the 'synchronous to disk' version, which many people prefer.
  27.  
  28. Here's what the standard [RFC1094] says:
  29.  All of the procedures in the NFS protocol are assumed to be synchronous.  When
  30.  a procedure returns to the client, the client can assume that the operation
  31.  has completed and any data associated with the request is now on stable
  32.  storage.  For example, a client WRITE request may cause the server to update
  33.  data blocks, filesystem information blocks (such as indirect blocks), and file
  34.  attribute information (size and modify times).  When the WRITE returns to the
  35.  client, it can assume that the write is safe, even in case of a server crash...
  36.          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  37.  
  38. }No worse than writes on your local disk, since they are of course
  39. }buffered also.
  40.  
  41. Yes, but you have a pretty good clue when your local machine crashes, it is
  42. possible to have a server reboot and the for the client to not know this.
  43.  
  44. }There is no 'standard' in this sense for NFS, only implementations, or
  45. }such is my understanding from all the arguments/discussions.
  46.  
  47. RFC1094  NFS: Network File System Protocol specification. Sun Microsystems, Inc.
  48.          1989 March; 27 p.
  49.  
  50. }Again, no difference between NFS and local disk, in this case, so why make
  51. }such a big deal about it.  The only case I can see any justification for
  52. }the argument is if you have a system set up purely as an NFS server, similar
  53. }to Auspex (that is, where you don't have any local disk writes to speak of).
  54. }In that case, I would definitely expect a UPS, or sync writes.  However,
  55. }you explictly mention workstations, and for workstations, you will have
  56. }far more local writes than you will NFS writes, so the argument seems rather
  57. }silly.
  58.  
  59. I don't think this is universally true by any means.  For example, we have
  60. a number of SGI labs (not setup by me!) on campus with N machines (N typically
  61. 15-25) which all mount each other's disks for home directories, so there is
  62. only a 1/Nth chance your home dir is local.
  63.  
  64. I am, of course, playing the devil's advocate here -- we do run asynch writes
  65. on our NFS servers -- but, at least we went into it with our eyes wide open.
  66.  
  67. John
  68. -- 
  69. John Hascall                   ``An ill-chosen word is the fool's messenger.''
  70. Systems Software Engineer
  71. Project Vincent
  72. Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
  73.