On 01:11 Tue 28 Oct , Robin H. Johnson wrote:
> On Tue, Oct 28, 2008 at 07:21:10AM +0000, Ciaran McCreesh wrote:
> > More likely you're just having problems with the connection lasting for
> > too long. 'git fetch' will resume (on a per-object basis, which is
> > fine so long as there aren't too many huge packs).
> It's a single ~910MiB pack. I'll play with it and see how we can make it
> better, maybe limiting the pack sizes to 50Mb/ea.
I did a few repacks and found that there's a linear relationship between
the log of the pack size and the repo size. If repo size is in GB and
pack size is in MB:
repo_size=m*(log(pack_size))+c, where m=-0.35, c=3.3
Using that, it's straightforward to optimize on whichever parameter you
care about while still considering the other one. I also attached two
graphs showing this more visually, one in log form and the other not.
The clear preference is the largest pack size where we rarely encounter
clone problems. Perhaps we should just cut the pack into fractions
(900/2, 900/3, etc) until we no longer hear about problems cloning.
One major issue is that apparently partial downloads of a single pack
don't resume. Ideally, we should just get that fixed upstream and use a
single huge pack. Thoughts?
Developer, Gentoo Linux