You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lukas Ruf <ru...@rawip.org> on 2004/03/22 12:57:03 UTC
How to overcome the NFS limitation
Dear all,
is there any way to overcome the NFS problem for a repository?
My configuration:
- Linux 2.6.x Gateway for Web & SVN
- Sun Solaris 2.8 NFS server
- Heterogeneous clients (Win, Mac, Linux, Sun)
On the NFS server, no additional servers are allowed to be run.
Hence, I mount on the directories on the gateway. My gateway is
backed up only once per day. Our NFS server disposes of a nice RAID-5
file system that is exported to the Gateway. Since a plethora of
people are using the gateway, I would like to make use of the NFS
exported filesystem to minimize the risk of loosing data as much as
possible.
Has anybody had a similar problem -- and found a solution that works
as I wish it to work?
Please excuse my ignorance. I am switching from CVS to SVN only now:
I deal primarily with Linux kernel stuff: own patches have to be kept
in synch with different kernel versions (2.4.20 .. 25, 2.6.2 .. 3
etc.). If anyone has had to work with svn in a similar configuration
I would be more than happy if he or she could share his/her
experiences -- or help me finding appropriate links on the web....
Thanks in advance.
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Derek Scherger <de...@echologic.com>.
John Peacock wrote:
> Lukas Ruf wrote:
>
>> What were the cost of porting Svn to e.g. postgres or similar -- can
>> they support the required NFS?
>
>
> I don't know if PostgreSQL or MySQL have limitations on NFS storage.
> The major cost to add those databases as backend to Subversion is time;
> it will happen, but no one has any idea when, AFAIK.
Me neither but it would seem odd to run a database server on one machine and have it write
to disks on another. Running postgres on the machine with the big disks and connecting to
it over the network would seem more typical. But of course that would involve running
some other server on the raid machine in which case you could just run subversion there
instead.
--
Cheers,
Derek
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by John Peacock <jp...@rowman.com>.
Lukas Ruf wrote:
> What were the cost of porting Svn to e.g. postgres or similar -- can
> they support the required NFS?
I don't know if PostgreSQL or MySQL have limitations on NFS storage. The major
cost to add those databases as backend to Subversion is time; it will happen,
but no one has any idea when, AFAIK.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Lukas Ruf <ru...@rawip.org>.
John,
thanks for the reply.
> John Peacock <jp...@rowman.com> [2004-03-22 14:51]:
>
> Lukas Ruf wrote:
> >is there any way to overcome the NFS problem for a repository?
>
> This is a limitation of BerkeleyDB, not just Subversion's use of the
> same:
>
> http://www.sleepycat.com/docs/ref/env/remote.html
>
I read that. So, there is nothing to overcome this limitation? :-(
What were the cost of porting Svn to e.g. postgres or similar -- can
they support the required NFS?
> The best thing to do is to get another server to act as the
> repository host.
>
As a university, I will not get the money to buy a new RAID system
"just" for the repository.
> You can use the hotbackup facilities to keep the backups on the NFS
> mount, but in practice that is as good as it gets...
>
Thanks! I will take a closer look at it.
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by John Peacock <jp...@rowman.com>.
Lukas Ruf wrote:
> is there any way to overcome the NFS problem for a repository?
This is a limitation of BerkeleyDB, not just Subversion's use of the same:
http://www.sleepycat.com/docs/ref/env/remote.html
The best thing to do is to get another server to act as the repository host.
You can use the hotbackup facilities to keep the backups on the NFS mount, but
in practice that is as good as it gets...
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Chris Wein <cw...@mobilygen.com>.
The base script is in the source tree in tools/dev/stress.pl. It is a
little tricky to use it in this configuration as the script is not
really set up for it. For the NFS setup you need to use either svnserve
or Apache (no file:// url's). However, the script needs svnadmin to
create the repository meaning you need local file access. What I did
first is run the scripts on the Solaris box using the url of
svn://localhost/. I subsequently modified the script (but lost the
changes...ugh) to populate on the Solaris box and exit, and on the Linux
boxes to assume the repository was populated and just go ahead and run
using a URL of svn://repos/. Anyway, both worked fine.
On Fri, 2004-03-26 at 01:10, Lukas Ruf wrote:
> > On Thu, 2004-03-25 at 15:19, John Pybus wrote:
> > > Nuutti Kotivuori wrote:
> > > > Chris Wein wrote:
> > > >
> > > >>We have exactly this setup. A Solaris box running svnserve
> > > >>mounting the repository from a NetApp via NFS3. No other
> > > >>machines mount the repository and all svnadmin etc. is done from
> > > >>the Sun box.
> > > >
> > > >
> > > > And it works fine? No repository corruption? Has it gotten a lot
> > > > of usage? Have you run the BerkeleyDB testsuite?
> > >
> > > Actually, the sleepycat page you linked in your previous email
> > > only warns against remote file systems not *fully supporting posix
> > > semantics*, and goes on to warn about specific problems with NFS
> > > implementations on some Linux & FreeBSD releases. Solaris has
> > > about as solid an NFS implementation as you're going to come
> > > across. If the svn server is indeed the only client of the
> > > storage then I'm not surprised it works.
> >
> > Chris Wein <cw...@mobilygen.com> [2004-03-26 00:33]:
> >
> > I have not run the DB test suite on it yet but did run aggressive
> > stress testing of svn against a repository (I had to mod the stress
> > test a bit to do this over the svn:// protocol instead of file://
> > since the script wants to create a repository too). I tried to run
> > the DB tests but ran into a TCL problem with not being able to find
> > the TCL_GetErrno symbol.
> >
> > So, following up we are EXTREMELY careful to have only the Solaris
> > box access the repository as well as making sure that it is running
> > NFSv3. Also note that Perforce has exactly the same limitations and
> > warns against Linux and FreeBSD but explicitly states that Solaris
> > 2.5.x and above is fine. Of course, it does not run sleepycat but
> > the root limitations are probably the same.
> >
>
> Chris, can you send me the stress test programs you used -- or any
> pointer to them? Thanks!
>
> wbr,
> Lukas
> --
> Lukas Ruf | Wanna know anything about raw |
> <http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
> eMail Style Guide: <http://www.rawip.org/style.html>|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Chris Wein
Software Engineer
Mobilygen Corp.
E-Mail : cwein@mobilygen.com
Phone : 408-869-4035
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Lukas Ruf <ru...@rawip.org>.
> On Thu, 2004-03-25 at 15:19, John Pybus wrote:
> > Nuutti Kotivuori wrote:
> > > Chris Wein wrote:
> > >
> > >>We have exactly this setup. A Solaris box running svnserve
> > >>mounting the repository from a NetApp via NFS3. No other
> > >>machines mount the repository and all svnadmin etc. is done from
> > >>the Sun box.
> > >
> > >
> > > And it works fine? No repository corruption? Has it gotten a lot
> > > of usage? Have you run the BerkeleyDB testsuite?
> >
> > Actually, the sleepycat page you linked in your previous email
> > only warns against remote file systems not *fully supporting posix
> > semantics*, and goes on to warn about specific problems with NFS
> > implementations on some Linux & FreeBSD releases. Solaris has
> > about as solid an NFS implementation as you're going to come
> > across. If the svn server is indeed the only client of the
> > storage then I'm not surprised it works.
>
> Chris Wein <cw...@mobilygen.com> [2004-03-26 00:33]:
>
> I have not run the DB test suite on it yet but did run aggressive
> stress testing of svn against a repository (I had to mod the stress
> test a bit to do this over the svn:// protocol instead of file://
> since the script wants to create a repository too). I tried to run
> the DB tests but ran into a TCL problem with not being able to find
> the TCL_GetErrno symbol.
>
> So, following up we are EXTREMELY careful to have only the Solaris
> box access the repository as well as making sure that it is running
> NFSv3. Also note that Perforce has exactly the same limitations and
> warns against Linux and FreeBSD but explicitly states that Solaris
> 2.5.x and above is fine. Of course, it does not run sleepycat but
> the root limitations are probably the same.
>
Chris, can you send me the stress test programs you used -- or any
pointer to them? Thanks!
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Chris Wein <cw...@mobilygen.com>.
I have not run the DB test suite on it yet but did run aggressive stress
testing of svn against a repository (I had to mod the stress test a bit
to do this over the svn:// protocol instead of file:// since the script
wants to create a repository too). I tried to run the DB tests but ran
into a TCL problem with not being able to find the TCL_GetErrno symbol.
So, following up we are EXTREMELY careful to have only the Solaris box
access the repository as well as making sure that it is running NFSv3.
Also note that Perforce has exactly the same limitations and warns
against Linux and FreeBSD but explicitly states that Solaris 2.5.x and
above is fine. Of course, it does not run sleepycat but the root
limitations are probably the same.
C
ps. if anyone has a pointer as to why I can't get the TCL stuff to work
I would appreciate it...
On Thu, 2004-03-25 at 15:19, John Pybus wrote:
> Nuutti Kotivuori wrote:
> > Chris Wein wrote:
> >
> >>We have exactly this setup. A Solaris box running svnserve mounting
> >>the repository from a NetApp via NFS3. No other machines mount the
> >>repository and all svnadmin etc. is done from the Sun box.
> >
> >
> > And it works fine? No repository corruption? Has it gotten a lot of
> > usage? Have you run the BerkeleyDB testsuite?
>
> Actually, the sleepycat page you linked in your previous email only
> warns against remote file systems not *fully supporting posix
> semantics*, and goes on to warn about specific problems with NFS
> implementations on some Linux & FreeBSD releases. Solaris has about as
> solid an NFS implementation as you're going to come across. If the svn
> server is indeed the only client of the storage then I'm not surprised
> it works.
>
> John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Chris Wein
Software Engineer
Mobilygen Corp.
E-Mail : cwein@mobilygen.com
Phone : 408-869-4035
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by John Pybus <jo...@zoology.oxford.ac.uk>.
Nuutti Kotivuori wrote:
> Chris Wein wrote:
>
>>We have exactly this setup. A Solaris box running svnserve mounting
>>the repository from a NetApp via NFS3. No other machines mount the
>>repository and all svnadmin etc. is done from the Sun box.
>
>
> And it works fine? No repository corruption? Has it gotten a lot of
> usage? Have you run the BerkeleyDB testsuite?
Actually, the sleepycat page you linked in your previous email only
warns against remote file systems not *fully supporting posix
semantics*, and goes on to warn about specific problems with NFS
implementations on some Linux & FreeBSD releases. Solaris has about as
solid an NFS implementation as you're going to come across. If the svn
server is indeed the only client of the storage then I'm not surprised
it works.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Nuutti Kotivuori <na...@iki.fi>.
Chris Wein wrote:
> We have exactly this setup. A Solaris box running svnserve mounting
> the repository from a NetApp via NFS3. No other machines mount the
> repository and all svnadmin etc. is done from the Sun box.
And it works fine? No repository corruption? Has it gotten a lot of
usage? Have you run the BerkeleyDB testsuite?
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Chris Wein <cw...@mobilygen.com>.
We have exactly this setup. A Solaris box running svnserve mounting the
repository from a NetApp via NFS3. No other machines mount the
repository and all svnadmin etc. is done from the Sun box.
And to address Derek Scherger's point about just running the server on
the raid machine anyway, the reason of course is that many RAIDs don't
run Unix in the traditional sense (like our NetApp).
Chris
On Tue, 2004-03-23 at 05:47, Nuutti Kotivuori wrote:
> Lukas Ruf wrote:
> > is there any way to overcome the NFS problem for a repository?
>
> Well, it is time to read with a fine comb what is actually being said:
>
> http://www.sleepycat.com/docs/ref/env/remote.html
>
> First of all - even if you do this, there must be only one machine
> accessing the repository at a time - this shouldn't be a problem for
> you if you run a separate server and just want the storage to be on an
> NFS mounted filesystem.
>
> What needs to be supported:
>
> - Locking: Linux mounting Solaris with NFSv3 should handle this.
>
> - Fsync: If the filesystem is not async mounted, fsync call should
> bring the data to disk even over NFSv3, so it should be okay.
>
> - Memory mapping: Should work in general. Not 100% sure if different
> processes see the same memory space - if not, then that is a
> problem.
>
> - Mutexes: No idea really. I am not even sure what kind of mutexing
> does Berkeley DB use.
>
> So, if you manage to somehow assure that all of these points are
> fulfilled, you should be able to have your repository over NFS.
>
> But - this is just trying to be helpful - if *anything* goes wrong,
> your data is hosed and you have to go for backups. In the worst case,
> you might not even notice it at first, only later on.
>
> If you are willing to experiment, you could try to run the Berkeley DB
> testsuite over NFSv3 first - I'm not sure if it manages to tickle all
> the access cases, but atleast some it does.
>
> -- Naked
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
--
Chris Wein
Software Engineer
Mobilygen Corp.
E-Mail : cwein@mobilygen.com
Phone : 408-869-4035
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to overcome the NFS limitation
Posted by Nuutti Kotivuori <na...@iki.fi>.
Lukas Ruf wrote:
> is there any way to overcome the NFS problem for a repository?
Well, it is time to read with a fine comb what is actually being said:
http://www.sleepycat.com/docs/ref/env/remote.html
First of all - even if you do this, there must be only one machine
accessing the repository at a time - this shouldn't be a problem for
you if you run a separate server and just want the storage to be on an
NFS mounted filesystem.
What needs to be supported:
- Locking: Linux mounting Solaris with NFSv3 should handle this.
- Fsync: If the filesystem is not async mounted, fsync call should
bring the data to disk even over NFSv3, so it should be okay.
- Memory mapping: Should work in general. Not 100% sure if different
processes see the same memory space - if not, then that is a
problem.
- Mutexes: No idea really. I am not even sure what kind of mutexing
does Berkeley DB use.
So, if you manage to somehow assure that all of these points are
fulfilled, you should be able to have your repository over NFS.
But - this is just trying to be helpful - if *anything* goes wrong,
your data is hosed and you have to go for backups. In the worst case,
you might not even notice it at first, only later on.
If you are willing to experiment, you could try to run the Berkeley DB
testsuite over NFSv3 first - I'm not sure if it manages to tickle all
the access cases, but atleast some it does.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org