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

Re: fs-rep-sharing branch

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Wed, 22 Oct 2008 21:30:36 -0500

David Glasser wrote:
> On Wed, Oct 22, 2008 at 1:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> David Glasser wrote:
>>> *nod*, reasonable. I'd still argue that (for FSFS) rep-sharing seems
>>> to be a net loss, though.
>> All the code to do rep-sharing should be wrapped up in FS-format-version
>> conditionals -- should we expose rep-sharing as an option (in the format
>> file) to the administrator and let him/her decide if the space savings is
>> worth it?
>
> Might be a good idea. Note that (unlike sharding) I think that the
> use of rep-sharing can be essentially turned on and off at will (as
> long as reuse numbers are always parsed), so I'd advocate for putting
> this in the new fsfs.conf rather than the format file. (Or y'all
> could decide that I made a false dichotomy between format options and
> configuration and ditch the fsfs.conf.)

rep-sharing can be turned on and off pretty much at will. The cache can be
blown away without any negative consequences, and the parser can be taught to
ignore the reuse numbers.

As far as fsfs.conf vs. the format file, what dichotomy did you choose? My
feeling would be that values which should remain constant for the life of the
repo (such as shard size) should go in the format file, while values which can
be changed in a live repo should live in fsfs.conf. Does that feeling match
reality?

-Hyrum

Received on 2008-10-23 04:30:56 CEST

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.