Date: Thu, 24 Mar 2016 10:22:31 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, Bryan Drewery <bdrewery@freebsd.org>, "cem@FreeBSD.org" <cem@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r297201 - in head: share/man/man4 sys/dev/filemon Message-ID: <20160324092330.X2963@besplex.bde.org> In-Reply-To: <610790279.29237860.1458771051379.JavaMail.zimbra@uoguelph.ca> References: <201603222241.u2MMf7ub090070@repo.freebsd.org> <CAG6CVpUxC6Nov7ocy5eEpcQFLd%2BQdXUxZWs49kTesWZo_VqncQ@mail.gmail.com> <D2476F6F-8C58-489D-9654-DFF2AEB9941F@FreeBSD.org> <CAJ5_RoD1J_LOvN5hzSF_DsUHd_mtn=XZDYcZU5xOBiyRSVjVDg@mail.gmail.com> <610790279.29237860.1458771051379.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Mar 2016, Rick Macklem wrote: > Benjamin Kaduk wrote: >> On Tue, Mar 22, 2016 at 9:11 PM, Bryan Drewery <bdrewery@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160324092330.X2963>