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

Re: FSFS packing functionally complete

From: Listman <listman_at_burble.net>
Date: Thu, 27 Nov 2008 02:46:36 -0800

sounds like a nice feature, thx!

just in case the performance hit is significant is there switch to
disable this?

On Nov 26, 2008, at 6:11 PM- Nov 26, 2008, Hyrum K. Wright wrote:

> Hi all.
>
> As of r34446, the implementation of packing on fsfs is functionally
> complete on
> the fsfs-pack branch. For those that don't know, packing consists
> of mushing
> all the individual rev files in a completed shard into one file, thus
> eliminating the inode penalty for that entire shard. Packing a
> trunk-generated
> copy of the ASF repository saved about 1 GB on a 24 GB repo. There
> may be
> additional performance benefits in dealing with a much smaller set
> of rev files
> (OS caching, etc.), but I haven't yet investigated that.
>
> This comes at a cost: the offsets of revisions in the pack file are
> stored
> separately, and thus require an additional open/seek to get that
> information.
> Also, determining whether a revision is stored in a pack file or not
> also
> requires additional I/O. I think that most of this can be
> eliminated with
> caching and heuristics, but those haven't yet been implemented.
>
> I'm not currently planning on including this functionality in 1.6,
> as it's kinda
> biggish feature, the optimizations aren't yet in place, and I feel
> like merging
> right before we branch 1.6.x could be a bit destabilizing. However,
> I could
> easily be talked into it. :)
>
> Anyway, I'm soliciting feedback on the implementation and usage of
> this feature.
> Comments welcome.
>
> -Hyrum
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-27 11:46:51 CET

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.