NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/ultrix/8331

Text File | 1992-11-15 | 4.0 KB | 81 lines

Newsgroups: comp.unix.ultrix
Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!eff!sol.ctr.columbia.edu!spool.mu.edu!sgiblab!sgigate!sgi!fido!zola!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Subject: Re: Slow writes to Ultrix 4.3 NFS server
Message-ID: <[e-mail]>
Keywords: NFS server performance
Sender: [e-mail] (Net News)
Organization:  Silicon Graphics, Inc.  Mountain View, CA
References: <leb.721702653@Hypatia> <[e-mail]> <leb.721782917@Hypatia> <[e-mail]>
Date: Mon, 16 Nov 92 00:05:57 GMT
Lines: 68

In <[e-mail]> [e-mail] (John Hascall) writes:
| }>}I manage an SGI 4D/340 running IRIX 4.0.1 and a DECstation 5000/125 running
| }>}Ultrix 4.3.
| }>Anyway, several vendors' NFS servers mis-implement the standard (on purpose).
| }>The NFS standard requires that writes be done "synchronously".  Some vendors

Well, not actually.  It requires that it be written to 'stable storage'.
There have been many hundreds of hours spent on arguing this point.  SGI
feels that our uptime is good enough that by the time it makes it to RAM
on the server, it is in 'stable storage'.  We also provide an option
to do the 'synchronous to disk' version, which many people prefer.

Of course, you *do* realize that writes over NFS are rather unreliable
anyway (for what might be called production use), given the lack of any
decent locking alogorithm?  There are also a surprising number of people
who use soft mounts for writable NFS mounts, which are even less reliabele.
There is a pretty large spectrum of NFS options and reliability.

| }>allow you to set an option which makes NFS writes be done "asynchronously"
| }...
| }>                   *** SGI ships their systems with ASYNCH as the DEFAULT ***
| }>If you run asynch-writes (and we have modified our DEC servers to do this) and
| }>you don't have them on a UPS you are running a massive risk.

No worse than writes on your local disk, since they are of course
buffered also.

| }>The "safe" option to make your Ultrix boxes faster is to buy PrestoServe
| }>for your NFS servers.
|
| }Ahh.  The usual DEC solution is to charge their customers with add-on products
| }that amend the original deficiencies.
|
| That's a wee bit unfair -- it is the SGI product which is in violation
| if the standard.  (If you think the standard is deficient, blame Sun.)

There is no 'standard' in this sense for NFS, only implementations, or
such is my understanding from all the arguments/discussions.  The SPEC
folks have also spent a lot of time arguing about that for the LADDIS
test under development.

| }>(if you have an Ultrix *source* license, I can provide the 1-line patch)
|
| }If it's a one-line patch (to an additional add-on cost item again) why isn't it
| }an configurable option in the basic product?
|
| Because everyone beats up on DEC when they are non-standard conforming?
|
| }                                           Yet another linchpin in my case that
| }DEC is anti-customer.
|
| You may have good clean UPS power, but most workstations don't, so IMHO it
| is SGI who is hosing the customer here (I sure wouldn't want to be manning
| their customer service phone when some poor sucker takes a disk corruption
| hit because their NFS implementation is non-standard).

Again, no difference between NFS and local disk, in this case, so why make
such a big deal about it.  The only case I can see any justification for
the argument is if you have a system set up purely as an NFS server, similar
to Auspex (that is, where you don't have any local disk writes to speak of).
In that case, I would definitely expect a UPS, or sync writes.  However,
you explictly mention workstations, and for workstations, you will have
far more local writes than you will NFS writes, so the argument seems rather
silly.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]