On Mon, Dec 12, 2011 at 11:56 PM, Dimitry Andric wrote:
>
> A very late addition to this: I got Subversion 1.7 to work properly over
> NFSv3, by making sure rpc.lockd runs on both server and client.
>
> E.g, set rpc_lockd_enable to YES in rc.conf; this is off by default,
> even if you have nfs_cli
On Tue, 2011-12-13 at 07:53 -0800, Rick Macklem wrote:
> Dimitry Andric wrote:
> > On 2011-11-23 19:26, 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 lo
Dimitry Andric wrote:
> On 2011-11-23 19:26, 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.
> >>
On 2011-11-23 19:26, 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 l
> 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@ if we start updating hosts in the cluster
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 i
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
Dimitry Andric wrote:
> On 2011-11-23 17:41, Sean Bruno wrote:
> > Not sure what this all means, but when I attempt to check out HEAD
> > on an
> > NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> > getting an odd failure error.
> >
> >
> > FreeBSD bhyve.freebsd.org 10.0-CURRENT
Dinitry Andric wrote:
> On 2011-11-23 17:41, Sean Bruno wrote:
> > Not sure what this all means, but when I attempt to check out HEAD
> > on an
> > NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> > getting an odd failure error.
> >
> >
> > FreeBSD bhyve.freebsd.org 10.0-CURRENT
Sean Bruno wrote:
> Not sure what this all means, but when I attempt to check out HEAD on
> an
> NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
> getting an odd failure error.
>
>
> FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0
> r227883:
> Wed Nov 23 06:08:40
On 2011-11-23 17:41, Sean Bruno wrote:
Not sure what this all means, but when I attempt to check out HEAD on an
NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
getting an odd failure error.
FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227883:
Wed Nov 23 06:0
Not sure what this all means, but when I attempt to check out HEAD on an
NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
getting an odd failure error.
FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227883:
Wed Nov 23 06:08:40 PST 2011
sbr...@bhyve.freebsd.org:/u
12 matches
Mail list logo
