Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!fletcher
From: nick@bis.com (Nick Bender)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Summary: write does *not always work*
Message-ID: <13270@cs.utexas.edu>
Date: 5 Oct 90 19:21:41 GMT
References: <543@usenix.ORG> <544@usenix.ORG> <551@usenix.ORG> <13218@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Organization: Batterymarch Investment Systems
Lines: 31
Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: nick@bischeops.uucp (Nick Bender)

In article <13218@cs.utexas.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
= Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
= 
= In article <551@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
= > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
= > >NFS (as it is currently implemented) shows what goes wrong when
= > >reliability disappears.
= > In a discussion of filesystem semantics, NFS is a straw man.  Everyone
= > knows it's a botch.
= > If AFS and RFS don't convince one that a networked filesystem
= > namespace can work well, then nothing will.
= 
= Exactly! This example proves my point. What's so bad about NFS---why it
= doesn't fit well into the filesystem---is that it doesn't make the
= remote filesystem reliable and local. If you show me Joe Shmoe's RFS
= with reliable, local, static I/O objects, I'll gladly include it in the
= filesystem.
= 
= ---Dan

Any program which assumes that write(2) always works is broken. Period.
That's why you sometimes get long streams of "filesystem full" on your
console when some brain-damaged utility doesn't check a return value.
In my view this is not a reason to call NFS a botch.

nick@bis.com


Volume-Number: Volume 21, Number 188