On Wed, 23 Mar 2016, Rick Macklem wrote:
Benjamin Kaduk wrote:
On Tue, Mar 22, 2016 at 9:11 PM, Bryan Drewery <bdrew...@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.
I remember a long usenet thread which I didn't really understand at the
time (around 1990?) about close() returning EDQUOT.
FreeBSD actually documents close() returning ENOSPC. This error is
almost never checked for of course. FreeBSD doesn't documented EDQUOT,
at least in old versions.
close() can also return EINTR, and FreeBSD documents this too. This
error is almost never checked for of course. It is even harder to
handle completely. In at least old versions of POSIX, the state of
the fd when close returns EINTR is unspecifed. FreeBSD now documents
that the fd is deallocated after all errors in close() except EBADF.
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;-).
I'm still getting better performance in all cases tested with the no-
commit-on-close "optimization" turned off. But I only tested cases with
the fs mounted with noasync on both the client and server. It makes
sense that the optimization is negative in this case -- the commit-on-close
doesn't really commit, since it is still async. So doesn't cause much
delay. It moves doing the write RPCs earlier, which is better for
throughput though worse for latency. It then gains without any losses
(except perhaps weakening the approximation to "ctoc") by preventing the
client discarding its cached data.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
