Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!panda!genrad!decvax!tektronix!uw-beaver!tc.fluke!jeff
From: jeff@tc.fluke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: NFS reliability
Message-ID: <49@sputnik.tc.fluke.COM>
Date: Wed, 12-Nov-86 17:35:44 EST
Article-I.D.: sputnik.49
Posted: Wed Nov 12 17:35:44 1986
Date-Received: Sat, 15-Nov-86 05:28:45 EST
References: <1823@rlvd.UUCP>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 33

In article <1823@rlvd.UUCP> mike@louis.UUCP () writes:

>Recently we have been doing a study of NFS fileservers and we have
>come across unreliability in NFS (i.e writing something to a remote
>file and finding something different when reading it back) when the
>server was under extreme load. Now we are starting to notice the same
>behaviour on our existing Sun fileservers. 

>The question is, have other noticed this and does anyone know why
>it happens? And, of course, does anyone know how to stop it?

>Mike Woods

We have also experienced a (rare) phenonenon which does seem limited to
NFS files: a file may have a (logical) block's worth of data written as nulls.
It appears to happen under some ill-defined conditions of simultaneous access.
We've only seen it with /usr/spool/mail files and RCS *,v files (ouch!).

We've suffered another you-don't-get-back-what-you-wrote bug, but it is
NOT limited just to the NFS.  (If you serve diskless clients, they will
also see panic: ifree's.)  Turns out to be a problem with the Xylogics 450
disk controller under heavy load; we fixed it by putting each disk on a
separate controller.
-- 
        Jeff Stearns       (206) 356-5064
        John Fluke Mfg. Co.
        P.O. Box C9090  Everett WA  98043  
        {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff
-- 
	Jeff Stearns       (206) 356-5064
	John Fluke Mfg. Co.
	P.O. Box C9090  Everett WA  98043  
	{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff