Date: Thu, 1 Mar 2012 12:36:15 -0500 From: Garrett Wollman <wollman@bimajority.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? Message-ID: <20303.45967.708688.414986@hergotha.csail.mit.edu> In-Reply-To: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> References: <20302.54862.344852.13627@hergotha.csail.mit.edu> <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 29 Feb 2012 22:13:47 -0500 (EST), Rick Macklem <rmacklem@uoguelph.ca> said: > Otherwise, maybe rsync is doing byte range locking. You could add > "nolockd" to the mount options (which avoids using the NLM) and see > if that helps. That may well have done it, although I changed too many variables to be certain. -o udp,rsize=262144,wsize=262144,nolockd,hard,nointr seems to be working without error. rpc.lockd is running, for what it's worth. > Unfortunately it is a well known issue that updating exports > is not done atomically. (I had a patch that suspended the nfsd > threads while exports were being updated, but it was felt to > be risky and zack@ was going to come up with a patch to fix this, > but I don't think he has committed anything.) That might be something that we at least would need. You don't need to suspend all of the nfsd threads, just delay responding to any request that fails access control until the filter programming is done. We may actually need to do something like that, if this machine is to be usable as a file server. (Can't have our users' jobs randomly breaking just because an administrator mounted a new filesystem.) -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20303.45967.708688.414986>