svn commit: r297201 - in head: share/man/man4 sys/dev/filemon

[Rick Macklem]

Benjamin Kaduk wrote:
> On Tue, Mar 22, 2016 at 9:11 PM, Bryan Drewery <bdrewery at freebsd.org> wrote:
> 
> >
> >
> >
> > The manpage for close(2) does document some errors, one being ENOSPC.  The
> > close(2) behavior of returning write(2), really VOP_WRITE(9), errors though
> > is specific to filemon since all of the writes are hidden and this is the
> > only place to return an error.  I have a review open to resolve a similar
> > issue in alq(9) as well since all of the writes are asynchronous and
> > there's no API to retrieve any error from.
> >
> 
> filemon is not unique in this regard; the AFS filesystem buffers writes
> locally and in some cases errors writing to the remote server can be
> delayed until close().  Of course, very few softwares actually check the
> return value of close, so this can cause trouble sometimes...
> 
Sorry, but I can't resist a little ancient history...
When NFS first showed up in the mid-1980s, the clients would flush writes
upon close() in order to detect write errors (usually ENOSPC) and return
them to the app. (typically a user trying to save their text edit when the
server was out of space or the user was out of quota). At least this way,
the editor could tell the user that their text file wasn't saved.

Somehow, the flush writes upon close to detect this morphed into "close
to open consistency", which was an AFS concept and not an NFS one
(which most NFS clients only implement approximately, given attribute
 caching and modify time precision, but that's another story;-).

rick

> -Ben
>