You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Andreas Schmid <an...@ira.uka.de> on 2005/12/13 14:32:03 UTC
Re: working copy on NFS
> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote:
>
>>On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote:
>>
>>>The book mentions that the repository should be created on a local
>>>filesystem.
>>
>>Is it also true for FSFS?
>>
>>
>>>What about the working copy?
>>
>>No problem, except for the well-known problems of NFS.
>>
>
>
>
> Actually, we explicitly say it work in the FAQ:
> "
> Working copies can be stored on NFS (one common scenario is when your
> home directory is on a NFS server). On Linux NFS servers, due to the
> volume of renames used internally in Subversion when checking out files,
> some users have reported that 'subtree checking' should be disabled
> (it's enabled by default). Please see NFS Howto Server Guide and
> exports(5) for more information on how to disable subtree checking.
> "
>
> And on IRC, it has been used as a reason why we do locking the way we
> do.
> So if it doesn't actually work to store a working copy on NFS, we
> should either
>
> 1. Fix it
>
> or
>
> 2. Use real locks, and stop claiming storing working copy works on NFS
> on nfs implementations where locking doesn't work.
>
> (I actually think #2 is the better solution, because i think that we
> shouldn't work around everybody elses bugs, particularly when it causes
> large performance loss for us)
>
It doesn't work for me either, a checkout fails with the comment:
svn: Stale NFS file handle
svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries'
read-only
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: working copy on NFS
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-12-15 at 08:27 -0600, Ben Collins-Sussman wrote:
> Right. There are a lot of lousy NFS implementations out there, and a
> lot of good ones too. And some admins know how to properly administer
> 'statd' and 'lockd', and some don't. If those daemons are working
> properly, it actually allows filesystem locking to work ok. (I'm
> running a working copy on NFS with no problems.)
>
But we use magic lock files specifically so nfs locking doesn't have to
work.
If we are going to rely on NFS locking working, why aren't we just using
apr_file_lock?
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: working copy on NFS
Posted by Daniel Berlin <db...@dberlin.org>.
On Thu, 2005-12-15 at 08:27 -0600, Ben Collins-Sussman wrote:
> Right. There are a lot of lousy NFS implementations out there, and a
> lot of good ones too. And some admins know how to properly administer
> 'statd' and 'lockd', and some don't. If those daemons are working
> properly, it actually allows filesystem locking to work ok. (I'm
> running a working copy on NFS with no problems.)
>
But we use magic lock files specifically so nfs locking doesn't have to
work.
If we are going to rely on NFS locking working, why aren't we just using
apr_file_lock?
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: working copy on NFS
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Right. There are a lot of lousy NFS implementations out there, and a
lot of good ones too. And some admins know how to properly administer
'statd' and 'lockd', and some don't. If those daemons are working
properly, it actually allows filesystem locking to work ok. (I'm
running a working copy on NFS with no problems.)
On 12/14/05, Kjell H Andersen <kh...@lentic.net> wrote:
> I'm using a system where the working copy is on a nfs share. It works
> like a breeze, but I think the nfs locking feature (I think, I'm not a
> NFS expert) must be enabled. The repository (fsfs) is accessed through
> Apache which again reads the database through a nfs share. Same
> requirement to the nfs and locking stuff.
> What I'm saying is that it can work with both working copy and
> repository on nfs shares, you just have to configure it right.
>
> Kjell
>
> Andreas Schmid wrote:
> >> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote:
> >>
> >>> On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote:
> >>>
> >>>> The book mentions that the repository should be created on a local
> >>>> filesystem.
> >>>
> >>> Is it also true for FSFS?
> >>>
> >>>
> >>>> What about the working copy?
> >>>
> >>> No problem, except for the well-known problems of NFS.
> >>>
> >>
> >>
> >>
> >> Actually, we explicitly say it work in the FAQ:
> >> "
> >> Working copies can be stored on NFS (one common scenario is when your
> >> home directory is on a NFS server). On Linux NFS servers, due to the
> >> volume of renames used internally in Subversion when checking out files,
> >> some users have reported that 'subtree checking' should be disabled
> >> (it's enabled by default). Please see NFS Howto Server Guide and
> >> exports(5) for more information on how to disable subtree checking.
> >> "
> >>
> >> And on IRC, it has been used as a reason why we do locking the way we
> >> do.
> >> So if it doesn't actually work to store a working copy on NFS, we
> >> should either
> >>
> >> 1. Fix it
> >>
> >> or
> >> 2. Use real locks, and stop claiming storing working copy works on NFS
> >> on nfs implementations where locking doesn't work.
> >>
> >> (I actually think #2 is the better solution, because i think that we
> >> shouldn't work around everybody elses bugs, particularly when it causes
> >> large performance loss for us)
> >>
> >
> > It doesn't work for me either, a checkout fails with the comment:
> >
> > svn: Stale NFS file handle
> > svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries'
> > read-only
> >
> > Andreas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: working copy on NFS
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Right. There are a lot of lousy NFS implementations out there, and a
lot of good ones too. And some admins know how to properly administer
'statd' and 'lockd', and some don't. If those daemons are working
properly, it actually allows filesystem locking to work ok. (I'm
running a working copy on NFS with no problems.)
On 12/14/05, Kjell H Andersen <kh...@lentic.net> wrote:
> I'm using a system where the working copy is on a nfs share. It works
> like a breeze, but I think the nfs locking feature (I think, I'm not a
> NFS expert) must be enabled. The repository (fsfs) is accessed through
> Apache which again reads the database through a nfs share. Same
> requirement to the nfs and locking stuff.
> What I'm saying is that it can work with both working copy and
> repository on nfs shares, you just have to configure it right.
>
> Kjell
>
> Andreas Schmid wrote:
> >> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote:
> >>
> >>> On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote:
> >>>
> >>>> The book mentions that the repository should be created on a local
> >>>> filesystem.
> >>>
> >>> Is it also true for FSFS?
> >>>
> >>>
> >>>> What about the working copy?
> >>>
> >>> No problem, except for the well-known problems of NFS.
> >>>
> >>
> >>
> >>
> >> Actually, we explicitly say it work in the FAQ:
> >> "
> >> Working copies can be stored on NFS (one common scenario is when your
> >> home directory is on a NFS server). On Linux NFS servers, due to the
> >> volume of renames used internally in Subversion when checking out files,
> >> some users have reported that 'subtree checking' should be disabled
> >> (it's enabled by default). Please see NFS Howto Server Guide and
> >> exports(5) for more information on how to disable subtree checking.
> >> "
> >>
> >> And on IRC, it has been used as a reason why we do locking the way we
> >> do.
> >> So if it doesn't actually work to store a working copy on NFS, we
> >> should either
> >>
> >> 1. Fix it
> >>
> >> or
> >> 2. Use real locks, and stop claiming storing working copy works on NFS
> >> on nfs implementations where locking doesn't work.
> >>
> >> (I actually think #2 is the better solution, because i think that we
> >> shouldn't work around everybody elses bugs, particularly when it causes
> >> large performance loss for us)
> >>
> >
> > It doesn't work for me either, a checkout fails with the comment:
> >
> > svn: Stale NFS file handle
> > svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries'
> > read-only
> >
> > Andreas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: working copy on NFS
Posted by Kjell H Andersen <kh...@lentic.net>.
I'm using a system where the working copy is on a nfs share. It works
like a breeze, but I think the nfs locking feature (I think, I'm not a
NFS expert) must be enabled. The repository (fsfs) is accessed through
Apache which again reads the database through a nfs share. Same
requirement to the nfs and locking stuff.
What I'm saying is that it can work with both working copy and
repository on nfs shares, you just have to configure it right.
Kjell
Andreas Schmid wrote:
>> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote:
>>
>>> On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote:
>>>
>>>> The book mentions that the repository should be created on a local
>>>> filesystem.
>>>
>>> Is it also true for FSFS?
>>>
>>>
>>>> What about the working copy?
>>>
>>> No problem, except for the well-known problems of NFS.
>>>
>>
>>
>>
>> Actually, we explicitly say it work in the FAQ:
>> "
>> Working copies can be stored on NFS (one common scenario is when your
>> home directory is on a NFS server). On Linux NFS servers, due to the
>> volume of renames used internally in Subversion when checking out files,
>> some users have reported that 'subtree checking' should be disabled
>> (it's enabled by default). Please see NFS Howto Server Guide and
>> exports(5) for more information on how to disable subtree checking.
>> "
>>
>> And on IRC, it has been used as a reason why we do locking the way we
>> do.
>> So if it doesn't actually work to store a working copy on NFS, we
>> should either
>>
>> 1. Fix it
>>
>> or
>> 2. Use real locks, and stop claiming storing working copy works on NFS
>> on nfs implementations where locking doesn't work.
>>
>> (I actually think #2 is the better solution, because i think that we
>> shouldn't work around everybody elses bugs, particularly when it causes
>> large performance loss for us)
>>
>
> It doesn't work for me either, a checkout fails with the comment:
>
> svn: Stale NFS file handle
> svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries'
> read-only
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: working copy on NFS
Posted by Kjell H Andersen <kh...@lentic.net>.
I'm using a system where the working copy is on a nfs share. It works
like a breeze, but I think the nfs locking feature (I think, I'm not a
NFS expert) must be enabled. The repository (fsfs) is accessed through
Apache which again reads the database through a nfs share. Same
requirement to the nfs and locking stuff.
What I'm saying is that it can work with both working copy and
repository on nfs shares, you just have to configure it right.
Kjell
Andreas Schmid wrote:
>> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote:
>>
>>> On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote:
>>>
>>>> The book mentions that the repository should be created on a local
>>>> filesystem.
>>>
>>> Is it also true for FSFS?
>>>
>>>
>>>> What about the working copy?
>>>
>>> No problem, except for the well-known problems of NFS.
>>>
>>
>>
>>
>> Actually, we explicitly say it work in the FAQ:
>> "
>> Working copies can be stored on NFS (one common scenario is when your
>> home directory is on a NFS server). On Linux NFS servers, due to the
>> volume of renames used internally in Subversion when checking out files,
>> some users have reported that 'subtree checking' should be disabled
>> (it's enabled by default). Please see NFS Howto Server Guide and
>> exports(5) for more information on how to disable subtree checking.
>> "
>>
>> And on IRC, it has been used as a reason why we do locking the way we
>> do.
>> So if it doesn't actually work to store a working copy on NFS, we
>> should either
>>
>> 1. Fix it
>>
>> or
>> 2. Use real locks, and stop claiming storing working copy works on NFS
>> on nfs implementations where locking doesn't work.
>>
>> (I actually think #2 is the better solution, because i think that we
>> shouldn't work around everybody elses bugs, particularly when it causes
>> large performance loss for us)
>>
>
> It doesn't work for me either, a checkout fails with the comment:
>
> svn: Stale NFS file handle
> svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries'
> read-only
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org