From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Subject: Re: NFS corruption discovery
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Fri, 21 Aug 1992 01:59:53 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Doesn't Digital offer something you call "NVRAM" which is used with
>software similar that used with to Legato's PrestoServ?  Doesn't ULTRIX
>while using that "NVRAM" reply to the NFS client before the data is on
>the disk?  Using the reasoning that the "NVRAM" is "stable storage",
>and so you can call the early reply not really asynchronous?

	NVRAM is pretty stable storage. It will survive a power hit
or something like that. For all intents and purposes I'm willing to
call that as stable as a disk drive (more stable than some weird caching
drives can be I suppose).

	When running with PrestoServ (we license the technology from
Legato) you are acking to the client that the data has been copied
to stable storage, before it's written to disk. You can quibble all
day about what is or isn't "stable storage" but for damn sure I'd
rather have my data being written to a battery-backed NVRAM cache
than into an unprotected buffer cache like can happen on an, *ahem*,
SGI.

	Vern, I've seen you around long enough to know you understand
these issues. If you're trying to sow fear uncertainty and doubt about
the effectiveness of NVRAM, why don't you grace us with some arguments
for how asynch NFS on an SGI is better?

>I have been wondering how much that DEC "NVRAM" costs.  Is it standard
>in all systems?

	It's standard on some and it's a memory option on others. The
memory option is pretty slick, since it's at memory bus speed, not
on the I/O bus like the Sun PrestoCache board. So you don't chew up
bus bandwidth.

	We get a %300 improvement in NFS ops with Presto on one of
our servers. Asynch NFS can get you as much as %700, but it assumes
you're running with a UPS and that no dweezil ever powers your
CPU off suddenly on you. UPS' are not the only component of a workable
asynch NFS server.

>When all else is equal, an NFS server with more stable storage is more
>reliable.  However, all else is rarely equal.  For example, Ultrix is
>reputed to had much more serious bugs in its NFS server implementation
>than any NVRAM or synchronous writes might affect.  Actually, "reputed"
>is too weak.  I've seen enough interoperability complaints from SGI
>customers.  I have no doubt DEC will fix those bugs soon, but the point
>remains.

	Gee, Vern, it's so nice of SGI to list our bugs here. Why don't
you also describe which version numbers of ULTRIX you're talking about?
I personally know of no major bugs in our NFS implementation in the current
rev, or I'd be working to get them fixed.

	I can handle a little bit of pointed "give and take" on an
interesting topic, but it's not sporting behavior to post "so and
so's operating system has *BUGS*" kind of crap unless you care to list
specific problems with the current rev of the software, and you're
willing to take your lumps if I start listing any bugs I can think of
in SGI's. So let's call it quits here while this discussion still
has a gleam of technical merit.

>It is at best disingenuous to confound UDP checksums which protect
>against failures on the client, the server, and the network relays,
>gateways, bridges, and cables in between, with sychronous server writes
>which protect only against server failures.  Both may be desirable by
>customers, but equating them is wrong.

	Equating them is just fine, *IF* they are being sold as an
option that defaults to being *ON* and *IF* the ramifications of
asynch NFS are not being explained to the customer. That is what
I would consider at least mean-spirited if not unethical.

	Saying "asynch NFS + UPS is safe" is also not accurate,
unless you can *GUARANTEE* me that I can't run an application on
your system that will crash it before it can sync the buffer cache.
I dunno what "crashme" does on an SGI these days, but asynch
NFS is a loss, unless you're using it for /tmp or you don't care
about your data. Or you don't care about your customer's data,
that is.

mjr.