Re: NFS + SVN problem?

Sean Bruno wrote:
> On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote:
> > I don't know if Dimitry tried this, but you could also try the
> > "nolockd" option, so that byte range locking is done locally in
> > the client and avoids the NLM.
> >
> > Good luck with it and please let us know how it goes, rick
> 
> This seems to allow SVN 1.7 to do whatever nonsense it is trying to
> do.
> I've modified my fstab on the test host in the cluster to:
> 
> dumpster:/vol/volshscratch /dumpster/scratch nfs
> rw,soft,intr,bg,nolockd,nosuid 0 0
> 
Yep. Unless you have multiple clients locking the same file concurrently,
doing locking locally within the client is the way to go. (Although I'm
not fond of "soft", I think the default timeout is pretty conservative,
so it would take a network partitioning or VERY SLOW server to trigger it.)
(The NLM and associated NSM protocols are fundamentally flawed in their
 design, so no implementation can be expected to make them work "correctly".
 Having said that, I am not familiar enough with the FreeBSD implementation
 to try and fix specific scenarios.
 I do have a patch submitted by John Dees that fixes the case where a process
 with read access to a file attempts to read lock it. This case fails for the
 code in head, because the nlm always tests for write access. I do plan on
 getting this patch into head at some point.)

Oh, and don't hesitate to try NFSv4. It should do the locking correctly without
needing "nolockd" and the more testing it gets, the better.;-)

rick

> Removing soft,intr had no effect. This, I suspect will be problematic
> for clusteradm_at_ if we start updating hosts in the cluster.
> 
> Sean