Standards Update, IEEE 1003.4: Real-time Extensions

[Nick Bender]

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

In article <13218 at cs.utexas.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
= Submitted-by: brnstnd at kramden.acf.nyu.edu (Dan Bernstein)
= 
= In article <551 at usenix.ORG> chip at tct.uucp (Chip Salzenberg) writes:
= > According to brnstnd at 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 at bis.com


Volume-Number: Volume 21, Number 188