Re: Performance issue: initial git clone causes massive repack

From: Nicolas Pitre <nico@cam.org>
Date: Apr 6, 2009, 16:14 UTC
Message-ID: <alpine.LFD.2.00.0904061207110.6741@xanadu.home>
In-Reply-To: <9e4733910904060828m414dfe7v66b19f7b4c5b670e@mail.gmail.com>

On Mon, 6 Apr 2009, Jon Smirl wrote:

Show 10 quoted lines

> On Mon, Apr 6, 2009 at 11:14 AM, Nicolas Pitre <nico@cam.org> wrote:
> > This means that, when those objects are about to be stored in the new
> > pack, their raw data is simply copied straight from the original pack
> > using the offset and size noted above.  In other words, those objects
> > are simply never redeltified nor redeflated at all, and all the work
> > that was previously done to find the best delta match is preserved with
> > no extra cost.
> 
> Does this process cause random reads all over a 2GB pack file? Busy
> servers can't keep a 2GB pack in memory.

The creation of a new pack follows the same object recency rule as the ones it copies from, so the various reads should be perfectly sequential.

> sendfile() the 2GB pack to client is way more efficient. (assuming the
> pack is marked as being ok to send).

Git is not a FTP server. Otherwise we would have stayed with the rsync protocol.

Nicolas