From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from hawkwind.utcs.toronto.edu ([128.100.102.51]) by archone.tamu.edu with SMTP id <22533>; Fri, 30 Aug 1991 12:18:23 -0500
Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <2699>; Fri, 30 Aug 1991 13:17:45 -0400
To: The rc Mailing List <rc@archone.tamu.edu>
Subject: Re: 1 (global) history file 
In-reply-to: john's message of Wed, 28 Aug 91 13:42:59 -0400.
             <9108290342.2508.rc.bagoy@syd.dit.csiro.au> 
Date: Fri, 30 Aug 1991 12:17:43 -0500
From: Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>
Message-Id: <91Aug30.131745edt.2699@hawkwind.utcs.toronto.edu>

|I really hope someone besides me can be encouraged to have a dig through
|some NFS source for ideas about this.  Any takers?

 Okay, it's time for some NFS trivia. NFS has no notion of an O_APPEND
write; in fact, NFS doesn't even have a notion of a 'current file
position', being a stateless protocol (har har). NFS writes specify the
file, position in the file, and data to write. O_APPEND is implemented
by looking up the file's current size, and setting the position to
write to to that.

 This means that if two different machines are writing in O_APPEND mode
to the same file, there is no guarantee that both won't try writing to
the same offset, thinking they're appending cleanly. Worse, if two
machines are writing to the same file normally, they can and will stomp
all over each other's data in a merry dance, as the current position is
maintained entirely by the client.

 NFS is basically a crock. Avoid it if possible. Real disks for real
performance and real Unix filesystem semantics.

	- cks, who knows far too much about the insides of the NFS code
	       for his own good.