Date: Thu, 1 Mar 2012 19:25:24 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Garrett Wollman <wollman@bimajority.org> Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? Message-ID: <1549796645.224931.1330647924122.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20303.45967.708688.414986@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote: > <<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. > Wow, those are big UDP datagrams, but if they work, cool... > rpc.lockd is running, for what it's worth. > Doesn't matter. With the "nolockd" option, the client mount never uses it. > > 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.) > Well, it happens to be easy to block all the nfsd threads when they are between processing of RPCs. There are times (not very frequent) when this is necessary for NFSv4, so the code is already there to do it. I don't know how to delay replies and that might be messy. I can resurrect the patch for you, because it is simply two new options on the nfssvc() syscall to suspend and resume the threads, that are done by mountd before/after updating exports. (I think the main concern is that, if mountd crashes while processing the exports update, the resume will never happen, at least not until mountd is restarted. I think rwatson@ had an additional concern when this was discussed at the BSDCan developer summit, but I can't recall what it was?) Just email if you want the patch to test, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1549796645.224931.1330647924122.JavaMail.root>