home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / clients / 257 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  4.5 KB
  1. Path: sparky!uunet!usc!rpi!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!steinar
  2. From: steinar@ifi.uio.no (Steinar Kj{rnsr|d)
  3. Newsgroups: comp.client-server
  4. Subject: Re: NFS slowness
  5. Message-ID: <CMM.0.90.2.726329963.steinar@fram.ifi.uio.no>
  6. Date: 6 Jan 93 14:19:23 GMT
  7. References: <1993Jan4.175456.20845@spectrum.xerox.com>
  8. Sender: steinar@ifi.uio.no (Steinar Kj{rnsr|d)
  9. Organization: Dept. of Informatics, University of Oslo, Norway
  10. Lines: 81
  11. Nntp-Posting-Host: fram.ifi.uio.no
  12. In-Reply-To: weltman@adoc.xerox.com (Rob Weltman)'s message of Mon, 4 Jan
  13.         1993 17:54:56 GMT
  14. Originator: steinar@fram.ifi.uio.no
  15.  
  16. In article <1993Jan4.175456.20845@spectrum.xerox.com> weltman@adoc.xerox.com (Rob Weltman) writes:
  17.  
  18. >   I received a number of informative responses to my question
  19. > about why large NFS writes are so slow, and a few suggestions on
  20. > how to improve performance, and where to look for more info on
  21. > tuning NFS. The following are all the responses (hope that's OK
  22. > to post; everybody responded directly to me, so people on the
  23. > net can't really know what's been communicated).
  24. > 
  25. > Rob
  26. > 
  27.  
  28. For the sake of completeness, I would like to add a few comments to
  29. one of Guy Harris' very informative answers, partly cited below:
  30.  
  31. >> 
  32. >> From auspex.com!guy Thu Dec 31 11:08:24 1992
  33. >> From:    guy@auspex.com (Guy Harris)
  34. >> To:    jmm@imatron.com
  35. >> Subject: Re:  NFS and RPC discussion.
  36. >> Cc:    weltman@parc.xerox.com
  37. >> Status: RO
  38. >> Content-Length: 5983
  39. >> X-Lines: 116
  40. >>
  41. >> [stuff deleted]
  42. >>
  43. >> Normally, at least on most UNIX systems, "some form of storage that
  44. >> survives a server crash" means "the disk", because the UNIX buffer cache
  45. >> or page pool is *not* necessarily preserved if the system crashes and
  46. >> reboots (although a crash *might* cause the OS to try to sync data out
  47. >> to disk, that isn't guaranteed to work).
  48. >> 
  49. >> The Prestoserve board acts as "some form of storage that survives a
  50. >> server crash", but can be written to faster than can a disk; it's static
  51. >> RAM with a battery backup (so that even if the crash is caused by a
  52. >> power failure, the data will still survive the crash).
  53. >> 
  54. >> Some vendors, including SGI, HP, and Auspex, have an *option* for their
  55. >> NFS server code that allows the system administrator to specify that
  56. >> writes to a particular file system by the NFS server should *not* wait
  57. >> until the data makes it to "some form of storage that survives a server
  58. >> crash" before being marked as "done". 
  59.  
  60. True. However, if not exactly documented, it's piece-of-cake to patch up this 
  61. functionality on any UNIX system with NFS code derived from the original SUN 
  62. src. The patch can be applied directly to the binaries. (in fact, we use 
  63. Emacs for this purpose ..) The NFS server source-module in question is 
  64. 'nfs_server.c', and all that needs to be done is to change the flag 
  65. IO_SYNC (=4)  to zero, two or three places down the code if I remember right. 
  66.  
  67. As said above, the net effect is that NFS writes are now asynchronous, more 
  68. or less like local buffered writes. Instead of the (expensive?)
  69. Prestoserve card, you are now using the server's buffer cache for
  70. write caching, of course with the potential (but small) risk of loosing data 
  71. when the server crashes.
  72.  
  73. We have been running with this patch on all our DECstation and SPARC
  74. NFS servers for long time now, and have encountered no problems due to
  75. server crashes so far. Initially, we ran the original Legato NFS
  76. benchmark (nhfsstone) and measured NFS write throughput with the patch
  77. installed and compared the results with those supplied by Legato to
  78. document the functionality of the Prestoserve card. Not surprisingly,
  79. the throughput was equally good (and even slightly better some times).
  80. And the interactive performance improvement is really BIG, believe me!
  81.  
  82. >> We (Auspex) do not make that the default; we use it here only for
  83. >> diskless clients' swap space.  SGI *does* make it the default, claiming
  84. >> that crashes are rare enough that you're not actually going to lose any
  85. >> data.  Sun and SGI folk spend a fair bit of time yelling at one another
  86. >> about this....
  87. >> 
  88.  
  89. Yes they do, and rumours says that when speaking of NFS "write-security", 
  90. the SGI folks thinks it's better to have UDP checksumming turned *ON* 
  91. than running with the IO_SYNC flag set. Although affecting NFS performance,
  92. this is another issue though.
  93.  
  94.  ! Steinar Kjaernsroed    Dpt. of Informatics    email:steinar@ifi.uio.no
  95.  !            University of Oslo,               or
  96.  |                      NORWAY                        ..!mcsun!ifi!steinar
  97.