[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Sharded FSFS repositories - summary

From: John Szakmeister <john_at_szakmeister.net>
Date: 2007-03-17 20:29:59 CET

Justin Erenkrantz wrote:
> On 3/17/07, John Szakmeister <john@szakmeister.net> wrote:
>> If we're going to make this configurable, with a reasonable default, can
>> we default with something that's more reasonable for typical and mobile
>> users? And for those who are clearly out of the norm, such as Apache,
>> they can specify something more suitable to their environment?
> I would be *very* cautious about having any customizability at all for
> a few reasons:
> 1) What consequences would there be if the user changes it after the
> repos goes live? All of a sudden their repos could be corrupt: FSFS
> would think their repos is empty when it may have been under a new
> sharding scheme. Ouch.

Oh, I wasn't suggesting it be configurable on the fly. I was thinking
more like how svndiff is done. You specify it at the time of creation,
and it's recorded. It's not meant to be tweaked after the fact.

> 2) What performance penalty are we going to add by introducing a new
> file? This is yet another file that needs to be open'd, read'd, and
> close'd. IIRC, there is no config file for FSFS right now - so this
> would mandate the introduction of a new one. Needless to say, on a
> high-traffic site, this is going to introduce unnecessary I/O
> overhead. (Yes, the OS's cache may minimize this, but there's still a
> non-zero cost.)

I'd envision such a facility would be done along with the format... but
that probably breaks compatibility.

> So, I'd rather we just hard-code a setting that works: if an admin
> wants to change the #define, they can - but they have to dork with the
> source to do so. -- justin

I mentioned it only because the idea had been tossed out there
initially. I much prefer one less knob to turn, and one less concern to
have about the configuration of people's repositories.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 17 20:30:32 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.