home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / ultrix / 8452 < prev    next >
Encoding:
Text File  |  1992-11-20  |  4.1 KB  |  91 lines
  1. Newsgroups: comp.unix.ultrix
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!LRZnews!petav
  3. From: petav@Physik.TU-Muenchen.DE (Peter Averkamp)
  4. Subject: Re: Slow writes to Ultrix 4.3 NFS server
  5. Message-ID: <petav.722282161@e20.physik.TU-Muenchen.DE>
  6. Keywords: NFS server performance
  7. Sender: news@news.lrz-muenchen.de (Mr. News)
  8. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  9. References: <leb.721702653@Hypatia> <Bxos0B.GqM@news.iastate.edu>
  10. Date: Fri, 20 Nov 1992 17:56:01 GMT
  11. Lines: 78
  12.  
  13. john@iastate.edu (John Hascall) writes:
  14.  
  15. >leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman) writes:
  16. >}I manage an SGI 4D/340 running IRIX 4.0.1 and a DECstation 5000/125 running
  17. >}Ultrix 4.3.  The user login directories of both machines are NFS mounted to 
  18. >}each other.  I have found that when the DEC box writes files to the SGI, 
  19. >}performance is good, however when the SGI tries to write to the DEC, throughput
  20. >}is just awful.
  21.  
  22. >Is this in the FAQ?  If not it should be...
  23.  
  24. >Anyway, several vendors' NFS servers mis-implement the standard (on purpose).
  25. >The NFS standard requires that writes be done "synchronously".  Some vendors
  26. >allow you to set an option which makes NFS writes be done "asynchronously"
  27. >which can gain you a massive performance increase -- but if your server has
  28. >a catastrophic crash (and can't flush the disk buffers) you can have data
  29. >integrity problems.  *** SGI ships their systems with ASYNCH as the DEFAULT ***
  30. >If you run asynch-writes (and we have modified our DEC servers to do this) and
  31. >you don't have them on a UPS you are running a massive risk.
  32.  
  33. >The "safe" option to make your Ultrix boxes faster is to buy PrestoServe
  34. >for your NFS servers.
  35.  
  36. >John
  37. >(if you have an Ultrix *source* license, I can provide the 1-line patch)
  38. >-- 
  39. >John Hascall                   ``An ill-chosen word is the fool's messenger.''
  40. >Systems Software Engineer
  41. >Project Vincent
  42. >Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
  43.  
  44. There has been a long discussion about all this over and over some time
  45. ago. Being tired of people talking about things many of them never have
  46. tried out, i have put together an object-code patch for the versions
  47. 4.2 and 4.2a, so more people could try and take the risk and make their 
  48. own experiences. I have mailed it to about 20 sites with a pledge to
  49. inform me if >>anything<< >>ever<< goes wrong with a patched server. Up
  50. to now, all i got were thanks from happy users. I know that 20 is very
  51. bad statistics, so I'd like to see if there are even more dare-devils
  52. out there taking this data-loss risk...
  53. We don't have 4.3 yet, but you might try to use mine or figure out your
  54. own patch. By the time we get 4.3, i'll update it; maybe some other
  55. kind soul will do this before. I have binary patches for VAX/Ultrix(4.1)
  56. also.
  57.  
  58. Now here's what you might want to do:
  59.  
  60. cd /sys/MIPS/BINARY
  61. cp nfs_server.o nfs_server.o.orig
  62. uuencode nfs_server.o.orig nfs_server.o|sed -e 's/P$ \!B0\!/P$ \!B0 /'|uudecode
  63.  
  64. the patched nfs_server.o's sums:
  65. sum for 4.2  should be: 62555   104
  66. sum for 4.2a should be: 15177   104
  67. (The 'sum' of the uuencode-line is:18397  1, obtained by echo -n "stuff"|sum)
  68. And finally, please mail:petav@e20.physik.tu-muenchen.de simply
  69. saying that you've done it and if or what went wrong. I am really 
  70. interested in getting better statistics to hear about anything that
  71. ever went wrong, caused by the patch.
  72.  
  73. Please,Please be aware that using this will kick you completely off
  74. limits; do not complain about anything to your dec service person if
  75. you use a patched system. Do not blame or flame me! This is a
  76. completely experimental modification that's only there to amuse those
  77. who play with it. No Warranties, not even those for failure.
  78.  
  79. Many thanks to John Hascall who kicked off this whole issue and was so
  80. kind to verify the patches against a source-patched object.
  81.  
  82.  
  83.     Peter Averkamp
  84.  
  85.  
  86. --
  87. Peter Averkamp,                      | email:
  88. Physics Department E20               | petav@radon.e20.physik.tu-muenchen.de
  89. Techn. Univ. of Munich               | Phone: ++49 (89) 3209-2408
  90. D-8046 Garching, Germany             | Fax:   ++49 (89) 3209-2338
  91.