[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: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 22 Oct 2008 13:20:15 -0700

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.)

(By the way, I hope people are applying the same standard of analysis
to the FSFS caching that I added for 1.6. That one defaults to being
very similar to 1.5, and only becomes significantly different if
memcached use is explicitly configured; my profiling showed noticeable
but not enormous speed benefits to using memcached in some cases, and
slowdowns in other cases.)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 22:20:27 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.