You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Justin Johnson <ju...@gmail.com> on 2007/03/07 22:29:49 UTC
FSFS performance on NAS/NFS
I recently read the following statement on the dev list and wanted to
get some feedback.
"For those people who are using a NAS to store the repository, FSFS
really really really sucks."
The rest of that thread describes proposals on how to improve its performance.
In a conversation on the phone with CollabNet recently we were told
there should be no problem using FSFS repositories on NAS/NFS. The
comment above makes me think that isn't a good idea now. I know
CollabNet uses Berkeley and NAS for their repositories. Perhaps this
is one of the reasons why they aren't using FSFS.
Can anyone give any feedback on the above comment and make a
recommendation? We already are setting up hardware with NAS/NFS for
storage based on CollabNet's recommendation, so if it would be better
to go with Berkeley I'd like to know soon.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Jan Hendrik <ja...@myrealbox.com>.
Concerning Re: FSFS performance on NAS/NFS
Nathan Kidd wrote on 9 Mar 2007, 12:16, at least in part:
> Dave Camp wrote:
> > If you search the users list, you will find that many people are of
> > the opinion that you should only use BDB if you don't care about
> > your data. FSFS does not have the stability issues that svn + bdb
> > has. Most of the posts about "my BDB repository has crashed" are
> > usually answered with "switch to FSFS".
>
> I think that's a little unfair to BDB. Yes there are many reports of
> "my BDB repo has 'crashed'", but invariably it is a result of new
> users not understanding BDB's behaviour when an operation is
> improperly interrupted ("wedging"). This has nothing to do with
> "caring about your data" but ease of use with the server (i.e. data is
> not lost, you just need to manually run 'svnadmin recover'). An more
> experienced admin can set things up so this never becomes a problem.
> New BDB's auto-recover from "wedging" so it isn't an issue at all any
> more.
I can but support this. And probably it is worthwhile to have a good
look at the dates of the majority of those mails. I used Subversion
from version .27 till 1.0 on Windows 2K, served by Apache, and
wedged repositories were a problem indeed, though decreasingly. I
returned to Subversion at version 1.3/1.4, with otherwise same
environment, and never had a problem with a wedged repository
since. Of course BDB has grown in version, too, and I think that
makes part of the difference, with improved performance of
Subversion making for another part (e.g. less chance of timeouts
with larger commits on slower networks a/o machines).
JH
---------------------------------------
Freedom quote:
I may not agree with what you say,
but I will defend to the death your right to say it.
-- Voltaire
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Jeff Smith <js...@robotronics.com>.
On Friday 09 March 2007 11:15, Rahul Bhargava wrote:
> That's true, administering any database is non-trivial. That said
> BDB provides true transaction support.
> That has been mentioned as a key differentiator for Subversion.
> With FSFS if I am not mistaken you
> can not guarantee atomic update of properties and the revision
> database (if a file being committed
> has content and propset modified). That would require a database
> transaction spanning two tables
> and FSFS can only do atomic rename at file/dir level.
Well hey now wait a minute...
Why would FSFS be any less "atomic" of a commit than using BDB? Are
you understanding that all of this transaction (both data and
properties) go into the same FSFS file which is the single revision?
There is nothing there stopping it from being guaranteed, and is a
function of subversion, no the file storage mechanism. I would love
more explanation or clarification of implied effects of the
non-atomic update that you ever-so-lightly mentioned, thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Rahul Bhargava <me...@rahulbhargava.org>.
That's true, administering any database is non-trivial. That said BDB
provides true transaction support.
That has been mentioned as a key differentiator for Subversion. With
FSFS if I am not mistaken you
can not guarantee atomic update of properties and the revision database
(if a file being committed
has content and propset modified). That would require a database
transaction spanning two tables
and FSFS can only do atomic rename at file/dir level.
Erik Huelsmann wrote:
> On 3/9/07, Dave Camp <dc...@mac.com> wrote:
>> If you search the users list, you will find that many people are of
>> the opinion that you should only use BDB if you don't care about your
>> data. FSFS does not have the stability issues that svn + bdb has.
>> Most of the posts about "my BDB repository has crashed" are usually
>> answered with "switch to FSFS".
>
> Yes, but that has to do with the fact that unexperienced users
> shouldn't try to administer an environment as complex as bdb. The
> posting of the message itself is a sign the user may belong in the
> group of FSFS users.
>
> bye,
>
> Erik.
>
> PS: Admin overhead of FSFS is *much* lower that for BDB. That doesn't
> say our BDB backend isn't good for some (many) users.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Rahul Bhargava
http://www.rahulbhargava.org
Phone: (925) 265-8801(W)|895-2201(M)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
> On 3/9/07, Dave Camp <dc...@mac.com> wrote:
>> If you search the users list, you will find that many people are of
>> the opinion that you should only use BDB if you don't care about your
>> data. FSFS does not have the stability issues that svn + bdb has.
>> Most of the posts about "my BDB repository has crashed" are usually
>> answered with "switch to FSFS".
>
> Yes, but that has to do with the fact that unexperienced users
> shouldn't try to administer an environment as complex as bdb.
Or that the experienced users have had bad experiences with bdb...
I have, but it was many versions ago and in a different context so
perhaps it no longer applies. I still tend to not trust it for any data
that may grow during updates, requiring the values to be relocated.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/9/07, Dave Camp <dc...@mac.com> wrote:
> If you search the users list, you will find that many people are of
> the opinion that you should only use BDB if you don't care about your
> data. FSFS does not have the stability issues that svn + bdb has.
> Most of the posts about "my BDB repository has crashed" are usually
> answered with "switch to FSFS".
Yes, but that has to do with the fact that unexperienced users
shouldn't try to administer an environment as complex as bdb. The
posting of the message itself is a sign the user may belong in the
group of FSFS users.
bye,
Erik.
PS: Admin overhead of FSFS is *much* lower that for BDB. That doesn't
say our BDB backend isn't good for some (many) users.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/9/07, Dave Camp <da...@thinbits.com> wrote:
> > Les Mikesell wrote:
> >> Nathan Kidd wrote:
> >>> I think that's a little unfair to BDB. Yes there are many reports of
> >>> "my BDB repo has 'crashed'", but invariably it is a result of new
> >>> users not understanding BDB's behaviour when an operation is
> >>> improperly interrupted ("wedging"). This has nothing to do with
> >>> "caring about your data" but ease of use with the server (i.e. data is
> >>> not lost, you just need to manually run 'svnadmin recover'). An more
> >>> experienced admin can set things up so this never becomes a problem.
> >>> New BDB's auto-recover from "wedging" so it isn't an issue at all any
> >>> more.
> >>
> >> I think a lot of people have had bad experiences with BDB in other
> >> contexts in the past, so it's going to take a while to trust that it is
> >> any better this time around.
> >
> > Can you recall specific cases?
> >
> > I've been on the users lists since 1.0 and only recall (with admittedly
> > non-ECC memory :) issues that could be described by "yes, BDB is more
> > difficult to administer, and this is a case where the user/admin screwed
> > up". E.g.
> > * improper access/permissions so repo gets wedged
> > (fixed with BDB 4.4)
> > * system upgrade messed up so wrong version of bdb libs found
> > (still possible, but I think package maintainers are generally more
> > conscientious after the initial problems)
> > * (early 1.0) BDB config max settings needed upping as repo grew
> > (fixed since ~1.1)
> >
> > I agree that for the average user FSFS is just a better choice because
> > it "just works" (hey, I use these days too :), but I'd hate to see the
> > legit BDB complaint "more difficult to set up right" turn into "this
> > thing can't be trusted" based on handwavy say-so alone.
>
> I was one of those people and it wasn't "handwavy say-so". At the time, a
> fresh out-of-the-box svn install with BDB would eventually corrupt the DB
> (not just the wedging issue). Although it appeared to work fine for most
> people, there was a decent number of reports of serious problems. The svn
> devs even admitted on list it was an issue with how they were using bdb.
>
> Maybe things are better these days. But my source code is much to valuable
> to ever try that again.
The issue with how subversion is using BDB had to do with wedging. Not
with real dataloss. There were versions of BDB which had some real
trouble (v4.1), but at that time 4.0 was still quite regular. Later
4.2+ was rock solid again.
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Nathan Kidd wrote:
>>
>> Maybe things are better these days. But my source code is much to
>> valuable
>> to ever try that again.
>
> Ah, yes. That thread on your troubles a couple years ago was just the
> kind of thing I was referring to by "specific cases". Around that time
> there were noted problems on OS X and certain (new at that time) BDB
> versions.
So, the question for the future is, would you rather have to deal with
potential bugs in your filesystem _and_ BDB, or just the filesystem? My
theory has always been that if your filesystem isn't a good place to
store files you already have a big problem and things sitting on top of
it can't help that much.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Nathan Kidd <na...@spicycrypto.ca>.
Dave Camp wrote:
>>> Nathan Kidd wrote:
>> I've been on the users lists since 1.0 and only recall (with admittedly
>> non-ECC memory :) issues that could be described by "yes, BDB is more
>> difficult to administer, and this is a case where the user/admin screwed
>> up". E.g.
>> * improper access/permissions so repo gets wedged
>> (fixed with BDB 4.4)
>> * system upgrade messed up so wrong version of bdb libs found
>> (still possible, but I think package maintainers are generally more
>> conscientious after the initial problems)
>> * (early 1.0) BDB config max settings needed upping as repo grew
>> (fixed since ~1.1)
>>
>> I agree that for the average user FSFS is just a better choice because
>> it "just works" (hey, I use these days too :), but I'd hate to see the
>> legit BDB complaint "more difficult to set up right" turn into "this
>> thing can't be trusted" based on handwavy say-so alone.
>
> I was one of those people and it wasn't "handwavy say-so". At the time, a
> fresh out-of-the-box svn install with BDB would eventually corrupt the DB
> (not just the wedging issue). Although it appeared to work fine for most
> people, there was a decent number of reports of serious problems. The svn
> devs even admitted on list it was an issue with how they were using bdb.
>
> Maybe things are better these days. But my source code is much to valuable
> to ever try that again.
Ah, yes. That thread on your troubles a couple years ago was just the
kind of thing I was referring to by "specific cases". Around that time
there were noted problems on OS X and certain (new at that time) BDB
versions.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Dave Camp <da...@thinbits.com>.
> Les Mikesell wrote:
>> Nathan Kidd wrote:
>>> I think that's a little unfair to BDB. Yes there are many reports of
>>> "my BDB repo has 'crashed'", but invariably it is a result of new
>>> users not understanding BDB's behaviour when an operation is
>>> improperly interrupted ("wedging"). This has nothing to do with
>>> "caring about your data" but ease of use with the server (i.e. data is
>>> not lost, you just need to manually run 'svnadmin recover'). An more
>>> experienced admin can set things up so this never becomes a problem.
>>> New BDB's auto-recover from "wedging" so it isn't an issue at all any
>>> more.
>>
>> I think a lot of people have had bad experiences with BDB in other
>> contexts in the past, so it's going to take a while to trust that it is
>> any better this time around.
>
> Can you recall specific cases?
>
> I've been on the users lists since 1.0 and only recall (with admittedly
> non-ECC memory :) issues that could be described by "yes, BDB is more
> difficult to administer, and this is a case where the user/admin screwed
> up". E.g.
> * improper access/permissions so repo gets wedged
> (fixed with BDB 4.4)
> * system upgrade messed up so wrong version of bdb libs found
> (still possible, but I think package maintainers are generally more
> conscientious after the initial problems)
> * (early 1.0) BDB config max settings needed upping as repo grew
> (fixed since ~1.1)
>
> I agree that for the average user FSFS is just a better choice because
> it "just works" (hey, I use these days too :), but I'd hate to see the
> legit BDB complaint "more difficult to set up right" turn into "this
> thing can't be trusted" based on handwavy say-so alone.
I was one of those people and it wasn't "handwavy say-so". At the time, a
fresh out-of-the-box svn install with BDB would eventually corrupt the DB
(not just the wedging issue). Although it appeared to work fine for most
people, there was a decent number of reports of serious problems. The svn
devs even admitted on list it was an issue with how they were using bdb.
Maybe things are better these days. But my source code is much to valuable
to ever try that again.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Nathan Kidd wrote:
> Les Mikesell wrote:
>> Nathan Kidd wrote:
>>> I think that's a little unfair to BDB. Yes there are many reports of
>>> "my BDB repo has 'crashed'", but invariably it is a result of new
>>> users not understanding BDB's behaviour when an operation is
>>> improperly interrupted ("wedging"). This has nothing to do with
>>> "caring about your data" but ease of use with the server (i.e. data
>>> is not lost, you just need to manually run 'svnadmin recover'). An
>>> more experienced admin can set things up so this never becomes a
>>> problem. New BDB's auto-recover from "wedging" so it isn't an issue
>>> at all any more.
>>
>> I think a lot of people have had bad experiences with BDB in other
>> contexts in the past, so it's going to take a while to trust that it
>> is any better this time around.
>
> Can you recall specific cases?
In my case it was a web forum program written before such things were
commonplace by someone who preceded me. It stored the login names and
passwords in a bdb along with the list of topics and last-read messages.
After the original authors left (of course...) the topic list grew to
a point where the space originally allocated for the value was not
enough and it should have been relocated as they accumulated in a users
list. But, back then there must have been an off-by-one error in this
decision because it would randomly overwrite some nearby users who would
then not be able to log in.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Nathan Kidd <na...@spicycrypto.ca>.
Les Mikesell wrote:
> Nathan Kidd wrote:
>> I think that's a little unfair to BDB. Yes there are many reports of
>> "my BDB repo has 'crashed'", but invariably it is a result of new
>> users not understanding BDB's behaviour when an operation is
>> improperly interrupted ("wedging"). This has nothing to do with
>> "caring about your data" but ease of use with the server (i.e. data is
>> not lost, you just need to manually run 'svnadmin recover'). An more
>> experienced admin can set things up so this never becomes a problem.
>> New BDB's auto-recover from "wedging" so it isn't an issue at all any
>> more.
>
> I think a lot of people have had bad experiences with BDB in other
> contexts in the past, so it's going to take a while to trust that it is
> any better this time around.
Can you recall specific cases?
I've been on the users lists since 1.0 and only recall (with admittedly
non-ECC memory :) issues that could be described by "yes, BDB is more
difficult to administer, and this is a case where the user/admin screwed
up". E.g.
* improper access/permissions so repo gets wedged
(fixed with BDB 4.4)
* system upgrade messed up so wrong version of bdb libs found
(still possible, but I think package maintainers are generally more
conscientious after the initial problems)
* (early 1.0) BDB config max settings needed upping as repo grew
(fixed since ~1.1)
I agree that for the average user FSFS is just a better choice because
it "just works" (hey, I use these days too :), but I'd hate to see the
legit BDB complaint "more difficult to set up right" turn into "this
thing can't be trusted" based on handwavy say-so alone.
Cheers,
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Nathan Kidd wrote:
> Dave Camp wrote:
>> If you search the users list, you will find that many people are of
>> the opinion that you should only use BDB if you don't care about your
>> data. FSFS does not have the stability issues that svn + bdb has. Most
>> of the posts about "my BDB repository has crashed" are usually
>> answered with "switch to FSFS".
>
> I think that's a little unfair to BDB. Yes there are many reports of
> "my BDB repo has 'crashed'", but invariably it is a result of new users
> not understanding BDB's behaviour when an operation is improperly
> interrupted ("wedging"). This has nothing to do with "caring about your
> data" but ease of use with the server (i.e. data is not lost, you just
> need to manually run 'svnadmin recover'). An more experienced admin can
> set things up so this never becomes a problem. New BDB's auto-recover
> from "wedging" so it isn't an issue at all any more.
I think a lot of people have had bad experiences with BDB in other
contexts in the past, so it's going to take a while to trust that it is
any better this time around.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Nathan Kidd <na...@spicycrypto.ca>.
Dave Camp wrote:
> If you search the users list, you will find that many people are of the
> opinion that you should only use BDB if you don't care about your data.
> FSFS does not have the stability issues that svn + bdb has. Most of the
> posts about "my BDB repository has crashed" are usually answered with
> "switch to FSFS".
I think that's a little unfair to BDB. Yes there are many reports of
"my BDB repo has 'crashed'", but invariably it is a result of new users
not understanding BDB's behaviour when an operation is improperly
interrupted ("wedging"). This has nothing to do with "caring about your
data" but ease of use with the server (i.e. data is not lost, you just
need to manually run 'svnadmin recover'). An more experienced admin can
set things up so this never becomes a problem. New BDB's auto-recover
from "wedging" so it isn't an issue at all any more.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Dave Camp <dc...@mac.com>.
If you search the users list, you will find that many people are of
the opinion that you should only use BDB if you don't care about your
data. FSFS does not have the stability issues that svn + bdb has.
Most of the posts about "my BDB repository has crashed" are usually
answered with "switch to FSFS".
Dave
On Mar 7, 2007, at 2:29 PM, Justin Johnson wrote:
> I recently read the following statement on the dev list and wanted to
> get some feedback.
>
> "For those people who are using a NAS to store the repository, FSFS
> really really really sucks."
>
> The rest of that thread describes proposals on how to improve its
> performance.
>
> In a conversation on the phone with CollabNet recently we were told
> there should be no problem using FSFS repositories on NAS/NFS. The
> comment above makes me think that isn't a good idea now. I know
> CollabNet uses Berkeley and NAS for their repositories. Perhaps this
> is one of the reasons why they aren't using FSFS.
>
> Can anyone give any feedback on the above comment and make a
> recommendation? We already are setting up hardware with NAS/NFS for
> storage based on CollabNet's recommendation, so if it would be better
> to go with Berkeley I'd like to know soon.
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> 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
Re: FSFS performance on NAS/NFS
Posted by Matt Sickler <cr...@gmail.com>.
we have these things called "servers" for a reason.
NFS, samba, the windows shit, NAS are all FILE servers
svnserve and apache are SUBVERSION servers
dont try to use one to do the others job - its hacky and very slow
On 3/7/07, Justin Johnson <ju...@gmail.com> wrote:
>
> I recently read the following statement on the dev list and wanted to
> get some feedback.
>
> "For those people who are using a NAS to store the repository, FSFS
> really really really sucks."
>
> The rest of that thread describes proposals on how to improve its
> performance.
>
> In a conversation on the phone with CollabNet recently we were told
> there should be no problem using FSFS repositories on NAS/NFS. The
> comment above makes me think that isn't a good idea now. I know
> CollabNet uses Berkeley and NAS for their repositories. Perhaps this
> is one of the reasons why they aren't using FSFS.
>
> Can anyone give any feedback on the above comment and make a
> recommendation? We already are setting up hardware with NAS/NFS for
> storage based on CollabNet's recommendation, so if it would be better
> to go with Berkeley I'd like to know soon.
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: FSFS performance on NAS/NFS
Posted by Rahul Bhargava <me...@rahulbhargava.org>.
Hi Justin -
The thread you referenced indicates the file open/close bottlenecks when
going over
a network to a NFS server. If you have a separate GigE between your
Subversion server
machine and the NAS appliance, it could alleviate some of the network
performance
problem. Hopefully your NAS is not connected to the general network used
by the rest
of the company. If it did, anytime someone did a large download over the
network or max'd
out the bandwidth, your NFS performance will begin to really suck. My
recommendation
would be to have a separate GigE NIC on the SVN machine and use that to
connect to the NAS.
--
Rahul Bhargava
http://www.rahulbhargava.org
Phone: (925) 265-8801(W)|895-2201(M)
Justin Johnson wrote:
> On 3/8/07, eg <eg...@gmail.com> wrote:
>> Justin Johnson wrote:
>> >
>> > My question was specifically related to performance though. Is there
>> > anyone out there using FSFS repositories on NAS/NFS? Does the
>> > performance "really really really suck?" Should I go with Berkeley
>> > instead?
>> >
>>
>> I dont use it on NAS/NFS, so I cant give any useful feedback there.
>>
>> However, you might be interested to know that one of the developers has
>> recently proposed some changes to improve performace on NFS setups.
>>
>> For details, including a background on some of the issues, see the
>> thread :
>>
>> http://svn.haxx.se/dev/archive-2007-03/0067.shtml
>
> Right, that is the thread I referred to in my original post and the
> reason for my concern. :-)
>
> ---------------------------------------------------------------------
> 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
Re: FSFS performance on NAS/NFS
Posted by Justin Johnson <ju...@gmail.com>.
On 3/8/07, eg <eg...@gmail.com> wrote:
> Justin Johnson wrote:
> >
> > My question was specifically related to performance though. Is there
> > anyone out there using FSFS repositories on NAS/NFS? Does the
> > performance "really really really suck?" Should I go with Berkeley
> > instead?
> >
>
> I dont use it on NAS/NFS, so I cant give any useful feedback there.
>
> However, you might be interested to know that one of the developers has
> recently proposed some changes to improve performace on NFS setups.
>
> For details, including a background on some of the issues, see the thread :
>
> http://svn.haxx.se/dev/archive-2007-03/0067.shtml
Right, that is the thread I referred to in my original post and the
reason for my concern. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by eg <eg...@gmail.com>.
Justin Johnson wrote:
>
> My question was specifically related to performance though. Is there
> anyone out there using FSFS repositories on NAS/NFS? Does the
> performance "really really really suck?" Should I go with Berkeley
> instead?
>
I dont use it on NAS/NFS, so I cant give any useful feedback there.
However, you might be interested to know that one of the developers has
recently proposed some changes to improve performace on NFS setups.
For details, including a background on some of the issues, see the thread :
http://svn.haxx.se/dev/archive-2007-03/0067.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Justin Johnson wrote:
> CollabNet said there wouldn't be any data integrity issues with
> NAS/NFS and FSFS as long as only one server was accessing the
> repository and the version of NFS supported locking. Mounting on
> multiple servers concurrently and load balancing would require a
> clustered file system.
>
> My question was specifically related to performance though. Is there
> anyone out there using FSFS repositories on NAS/NFS? Does the
> performance "really really really suck?" Should I go with Berkeley
> instead?
That's going to be up to the NAS and your client NFS implementation -
and maybe the amount of RAM on each. NetApp filers have always been
very usable with NFS for maildir mailboxes which do a lot of small file
access - but that's on the expensive side.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Frode Tenneboe <fr...@saabgroup.com>.
On Thu, 2007-03-08 at 09:25 -0600, Justin Johnson wrote:
> My question was specifically related to performance though. Is there
> anyone out there using FSFS repositories on NAS/NFS? Does the
> performance "really really really suck?" Should I go with Berkeley
> instead?
We use FSFS over NSF on a NetApp FAS250 server. I have nothing to
compare against, but I find the performance more than sufficient
(especially since I also have the working directory on the same server).
-Frode
--
^ Frode Tennebø | email: Frode.Tennebo@saabgroup.com ^
| SAAB Microwave Systems AS | Isebakkeveien 49 |
| N-1788 Halden | Phone: +47 45 24 99 39 |
| with Standard.Disclaimer; use Standard.Disclaimer; |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Justin Johnson <ju...@gmail.com>.
CollabNet said there wouldn't be any data integrity issues with
NAS/NFS and FSFS as long as only one server was accessing the
repository and the version of NFS supported locking. Mounting on
multiple servers concurrently and load balancing would require a
clustered file system.
My question was specifically related to performance though. Is there
anyone out there using FSFS repositories on NAS/NFS? Does the
performance "really really really suck?" Should I go with Berkeley
instead?
Thanks,
Justin
On 3/7/07, Rahul Bhargava <me...@rahulbhargava.org> wrote:
> Well NFS locking can be tricky. NFSv3 protocol does not have built-in
> locking, it
> relies on another protocol NLM. Given the stateless nature of NFS
> protocol, NLM needs
> to store state on the server on who is locking what file range .
> Unfortunately there is no 'journal'
> on server-side to track that state during recovery. If the NFS server
> reboots it has to depend on
> a grace period for clients to come back and 'reclaim' their locks. If
> the NFS client fails to
> reach the server in the grace period (slow network etc), the server will
> wipe its state clean
> and essentially forget the locks that were held by the NFS client!
>
> In other words the recovery is not guaranteed to be 'safe' when clients
> and servers restart/fail.
> You may never encounter these issues but that does not mean you are safe
> under wacky
> failure scenarios.
>
> A single Apache server does not mean that there aren't multiple
> concurrent processes potentially accessing the
> NFS server.
>
> If you are using NFSv3 you may want to read this
> http://www.connectathon.org/talks06/talpey-cthon06-nsm.pdf on
> correctness issues with NLM. Not sure if NFSv4 bypasses all the issues.
>
> Les Mikesell wrote:
> > Rahul Bhargava wrote:
> >> Using NFS for any file system app like Subversion or CVS is
> >> dangerous. NFS clients typically cache file changes locally, that can
> >> cause weird errors (file size mismatches), the rename system call may
> >> not
> >> be atomic with NFS. If you are going to use a NAS array you are
> >> better off setting up iSCSI access rather than NFS.
> >
> > Note that client caching should only be a problem if you access
> > directly through the filesystem from multiple clients. If you mount
> > from a single server and use http or svnserve network acess from any
> > other clients everthing should work as long as nfs locks work on the
> > server.
> >
>
>
> --
> Rahul Bhargava
> http://www.rahulbhargava.org
> Phone: (925) 265-8801(W)|895-2201(M)
>
>
> ---------------------------------------------------------------------
> 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
Re: FSFS performance on NAS/NFS
Posted by Rahul Bhargava <me...@rahulbhargava.org>.
Well NFS locking can be tricky. NFSv3 protocol does not have built-in
locking, it
relies on another protocol NLM. Given the stateless nature of NFS
protocol, NLM needs
to store state on the server on who is locking what file range .
Unfortunately there is no 'journal'
on server-side to track that state during recovery. If the NFS server
reboots it has to depend on
a grace period for clients to come back and 'reclaim' their locks. If
the NFS client fails to
reach the server in the grace period (slow network etc), the server will
wipe its state clean
and essentially forget the locks that were held by the NFS client!
In other words the recovery is not guaranteed to be 'safe' when clients
and servers restart/fail.
You may never encounter these issues but that does not mean you are safe
under wacky
failure scenarios.
A single Apache server does not mean that there aren't multiple
concurrent processes potentially accessing the
NFS server.
If you are using NFSv3 you may want to read this
http://www.connectathon.org/talks06/talpey-cthon06-nsm.pdf on
correctness issues with NLM. Not sure if NFSv4 bypasses all the issues.
Les Mikesell wrote:
> Rahul Bhargava wrote:
>> Using NFS for any file system app like Subversion or CVS is
>> dangerous. NFS clients typically cache file changes locally, that can
>> cause weird errors (file size mismatches), the rename system call may
>> not
>> be atomic with NFS. If you are going to use a NAS array you are
>> better off setting up iSCSI access rather than NFS.
>
> Note that client caching should only be a problem if you access
> directly through the filesystem from multiple clients. If you mount
> from a single server and use http or svnserve network acess from any
> other clients everthing should work as long as nfs locks work on the
> server.
>
--
Rahul Bhargava
http://www.rahulbhargava.org
Phone: (925) 265-8801(W)|895-2201(M)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Les Mikesell <le...@gmail.com>.
Rahul Bhargava wrote:
> Using NFS for any file system app like Subversion or CVS is
> dangerous. NFS clients typically cache file changes locally, that can
> cause weird errors (file size mismatches), the rename system call may not
> be atomic with NFS. If you are going to use a NAS array you are
> better off setting up iSCSI access rather than NFS.
Note that client caching should only be a problem if you access directly
through the filesystem from multiple clients. If you mount from a
single server and use http or svnserve network acess from any other
clients everthing should work as long as nfs locks work on the server.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: FSFS performance on NAS/NFS
Posted by Rahul Bhargava <me...@rahulbhargava.org>.
Using NFS for any file system app like Subversion or CVS is
dangerous. NFS clients typically cache file changes locally, that can
cause weird errors (file size mismatches), the rename system call may not
be atomic with NFS. If you are going to use a NAS array you are
better off setting up iSCSI access rather than NFS.
Justin Johnson wrote:
> I recently read the following statement on the dev list and wanted to
> get some feedback.
>
> "For those people who are using a NAS to store the repository, FSFS
> really really really sucks."
>
> The rest of that thread describes proposals on how to improve its
> performance.
>
> In a conversation on the phone with CollabNet recently we were told
> there should be no problem using FSFS repositories on NAS/NFS. The
> comment above makes me think that isn't a good idea now. I know
> CollabNet uses Berkeley and NAS for their repositories. Perhaps this
> is one of the reasons why they aren't using FSFS.
>
> Can anyone give any feedback on the above comment and make a
> recommendation? We already are setting up hardware with NAS/NFS for
> storage based on CollabNet's recommendation, so if it would be better
> to go with Berkeley I'd like to know soon.
>
> Thanks,
> Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Rahul Bhargava
http://www.rahulbhargava.org
Phone: (925) 265-8801(W)|895-2201(M)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org