home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / nfs / 2118 < prev    next >
Encoding:
Text File  |  1992-08-20  |  4.4 KB  |  94 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!gatech!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: NFS corruption discovery
  5. Message-ID: <1992Aug21.015953.10705@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: <1992Aug19.225010.18306@den.mmc.com> <1992Aug20.042224.11176@decuac.dec.com> <oqme28g@rhyolite.wpd.sgi.com>
  10. Date: Fri, 21 Aug 1992 01:59:53 GMT
  11. Lines: 81
  12.  
  13. vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  14.  
  15. >Doesn't Digital offer something you call "NVRAM" which is used with
  16. >software similar that used with to Legato's PrestoServ?  Doesn't ULTRIX
  17. >while using that "NVRAM" reply to the NFS client before the data is on
  18. >the disk?  Using the reasoning that the "NVRAM" is "stable storage",
  19. >and so you can call the early reply not really asynchronous?
  20.  
  21.     NVRAM is pretty stable storage. It will survive a power hit
  22. or something like that. For all intents and purposes I'm willing to
  23. call that as stable as a disk drive (more stable than some weird caching
  24. drives can be I suppose).
  25.  
  26.     When running with PrestoServ (we license the technology from
  27. Legato) you are acking to the client that the data has been copied
  28. to stable storage, before it's written to disk. You can quibble all
  29. day about what is or isn't "stable storage" but for damn sure I'd
  30. rather have my data being written to a battery-backed NVRAM cache
  31. than into an unprotected buffer cache like can happen on an, *ahem*,
  32. SGI.
  33.  
  34.     Vern, I've seen you around long enough to know you understand
  35. these issues. If you're trying to sow fear uncertainty and doubt about
  36. the effectiveness of NVRAM, why don't you grace us with some arguments
  37. for how asynch NFS on an SGI is better?
  38.  
  39. >I have been wondering how much that DEC "NVRAM" costs.  Is it standard
  40. >in all systems?
  41.  
  42.     It's standard on some and it's a memory option on others. The
  43. memory option is pretty slick, since it's at memory bus speed, not
  44. on the I/O bus like the Sun PrestoCache board. So you don't chew up
  45. bus bandwidth.
  46.  
  47.     We get a %300 improvement in NFS ops with Presto on one of
  48. our servers. Asynch NFS can get you as much as %700, but it assumes
  49. you're running with a UPS and that no dweezil ever powers your
  50. CPU off suddenly on you. UPS' are not the only component of a workable
  51. asynch NFS server.
  52.  
  53. >When all else is equal, an NFS server with more stable storage is more
  54. >reliable.  However, all else is rarely equal.  For example, Ultrix is
  55. >reputed to had much more serious bugs in its NFS server implementation
  56. >than any NVRAM or synchronous writes might affect.  Actually, "reputed"
  57. >is too weak.  I've seen enough interoperability complaints from SGI
  58. >customers.  I have no doubt DEC will fix those bugs soon, but the point
  59. >remains.
  60.  
  61.     Gee, Vern, it's so nice of SGI to list our bugs here. Why don't
  62. you also describe which version numbers of ULTRIX you're talking about?
  63. I personally know of no major bugs in our NFS implementation in the current
  64. rev, or I'd be working to get them fixed.
  65.  
  66.     I can handle a little bit of pointed "give and take" on an
  67. interesting topic, but it's not sporting behavior to post "so and
  68. so's operating system has *BUGS*" kind of crap unless you care to list
  69. specific problems with the current rev of the software, and you're
  70. willing to take your lumps if I start listing any bugs I can think of
  71. in SGI's. So let's call it quits here while this discussion still
  72. has a gleam of technical merit.
  73.  
  74. >It is at best disingenuous to confound UDP checksums which protect
  75. >against failures on the client, the server, and the network relays,
  76. >gateways, bridges, and cables in between, with sychronous server writes
  77. >which protect only against server failures.  Both may be desirable by
  78. >customers, but equating them is wrong.
  79.  
  80.     Equating them is just fine, *IF* they are being sold as an
  81. option that defaults to being *ON* and *IF* the ramifications of
  82. asynch NFS are not being explained to the customer. That is what
  83. I would consider at least mean-spirited if not unethical.
  84.  
  85.     Saying "asynch NFS + UPS is safe" is also not accurate,
  86. unless you can *GUARANTEE* me that I can't run an application on
  87. your system that will crash it before it can sync the buffer cache.
  88. I dunno what "crashme" does on an SGI these days, but asynch
  89. NFS is a loss, unless you're using it for /tmp or you don't care
  90. about your data. Or you don't care about your customer's data,
  91. that is.
  92.  
  93. mjr.
  94.