Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!decprl!decprl!boyd
From: boyd@prl.dec.com (Boyd Roberts)
Newsgroups: comp.unix.wizards
Subject: Re: Another reason I hate NFS: Silent data loss!
Message-ID: <1991Jun17.084533.15905@prl.dec.com>
Date: 17 Jun 91 08:45:33 GMT
References: <4339.Jun1501.31.5191@kramden.acf.nyu.edu> <17105@darkstar.ucsc.edu>
Sender: news@prl.dec.com (USENET News System)
Organization: Digital Equipment Corporation - Paris Research Laboratory
Lines: 41
Nntp-Posting-Host: prl313.prl.dec.com

In article <17105@darkstar.ucsc.edu>, jik@cats.ucsc.edu (Jonathan I. Kamens) writes:
> My point is that the problem is fixable, and it isn't even difficult to fix. 
> Whether Sun (not to mention other vendors) has or will ever fix it is another
> question entirely....
> 

Sure, the problem is fixable.  The protocol is the problem!
It would appear that's the last thing Sun are likely to change.

All this nonsense about statelessness is just a smoke screen.
As soon as anyone proposes a change the immediate response is
`but then it's not _stateless_'.  We'll as far as I'm concerned:

    s/stateless/bug-full/

The whole thing is a charade.  You see that real disk there?  What's
contained on it.  Is it files?  Is it data?  Is it state?  Yes is it!

I could never understand this nonsense.  What makes them so sure that
when a crashed server comes up your data will still be intact?  If
a server crashes your system calls should error, no re-trying;  error --
plain and simple.  How will NFS ensure that the kernel or fsck or
the buffer cache won't have trashed my file as a result of the
crash?  Don't say `inode generation number',  it's just not a defense.

That UDP `protocol' really sucks the mop.  Soft/hard mounts.  What a joke.
What's needed is a connection based stream protocol.  Then you know the
difference between remote slow and remote dead.  It's all a question
of flow control.  NFS has none.  Not even sequence numbers.  

We run a lot of NFS here, and it's as flakey as C shell.  Two of the machines
here just go to sleep every once in a while, when the traffic gets a little
strong.  God knows why.  It's going to take a lot of pondering to track it
down.  Even then, it's probably a fundamental design problem that can't,
or won't, be fixed.



Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''