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

[Bryan Drewery]

> On Mar 22, 2016, at 20:18, Conrad Meyer <cem at FreeBSD.org> wrote:
> 
>> On Tue, Mar 22, 2016 at 7:46 PM, Benjamin Kaduk <bjkfbsd at gmail.com> 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.
>>> ...
>> 
>> 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().
> 
> Right.  filemon is not the only case.  Another example would be TCP
> socket fds, e.g., when the connection is RST after write(2) queues
> data on the outgoing sockbuf but before it is transmitted.
> 

I'm really not saying it's the only case. I'm saying close(2) returning a dozen write(2) errors is not normal and is documented here because it is expected here.  Anyone could write a module or FS that returns some random error on close(2). That doesn't mean it should be documented directly in close(2).  Consider the next commit here also returns EFAULT and ENAMELEN, which definitely are special case.  There are only 2 filemon consumers, script(1) and bmake. For bmake there is a patch in testing to utilize the close(2) error, since it's currently ignored. For script(1) I need to fix it still.

If there are errors that are common and missing from close(2), please do document them.  As Benjamin referenced, most people never fathom that it can even fail.  I know that NFS errors are not widely documented too.

Bryan