On 7 Nov 1998, SL Baur wrote:
Justin Vallon <vallon(a)mindspring.com> writes in
xemacs-beta(a)xemacs.org:
> I seem to remember somewhere that NFS writes may be postponed until
> close().
This brings back bad memories of old flame wars. I don't think NFS
will do this, but I know AFS can raise errors on close. If Dejanews
has restored enough old netnews, there should be megabytes on this
topic in the old archives.
> That is, close() may give errors such as disk full, etc, because
> for performance reasons, write() is only done locally and disk allocation
> is not done until close [or a later write].
Something like that, as I recall.
HP/UX 10.20, man close:
ERRORS
close() fails if the any of following conditions are encountered:
...
[ENOSPC] Not enough space on the file system. This error
can occur when closing a file on an NFS file
system. [When a write() system call is executed
on a local file system and if a new buffer needs
to be allocated to hold the data, the buffer is
mapped onto the disk at that time. A full disk is
detected at this time and write() returns an
error. When the write() system call is executed
on an NFS file system, the new buffer is allocated
without communicating with the NFS server to see
if there is space for the buffer (to improve NFS
performance). It is only when the buffer is
written to the server (at file close or the buffer
is full) that the disk-full condition is
detected.]
So, it appears that at least the HP NFS write() call can be cached and the
cache is not write-through. Hence, a flush would most likely be required,
or else stat() may be using a stale last-modify time.
-Justin
vallon(a)mindspring.com