On Wed, Mar 27, 2013 at 8:33 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Sitaram Chamarty <sitar...@gmail.com> writes:
>
>> On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano <gits...@pobox.com> wrote:
>>
>>> To be paranoid, you may want to set transfer.fsckObjects to true,
>>> perhaps in your ~/.gitconfig.
>>
>> do we have any numbers on the overhead of this?
>>
>> Even a "guesstimate" will do...
>
> On a reasonably slow machine:
>
> $ cd /project/git/git.git && git repack -a -d
> $ ls -hl .git/objects/pack/*.pack
> -r--r--r-- 1 junio src 44M Mar 26 13:18
> .git/objects/pack/pack-c40635e5ee2b7094eb0e2c416e921a2b129bd8d2.pack
>
> $ cd .. && git --bare init junk && cd junk
> $ time git index-pack --strict --stdin <../git.git/.git/objects/pack/*.pack
> real 0m13.873s
> user 0m21.345s
> sys 0m2.248s
>
> That's about 3.2 Mbps?
>
> Compare that with the speed your other side feeds you (or your line
> speed could be the limiting factor) and decide how much you value
> your data.
Thanks. I was also interested in overhead on the server just as a %-age.
I have no idea why but when I did some tests a long time ago I got
upwards of 40% or so, but now when I try these tests for git.git
cd <some empty dir>
git init --bare
# git config transfer.fsckobjects true
git fetch file:///full/path/to/git.git refs/*:refs/*
then, the difference in elapsed time 18s -> 22s, so about 22%, and CPU
time is 31 -> 37, so about 20%. I didn't measure disk access
increases, but I guess 20% is not too bad.
Is it likely to be linear in the size of the repo, by and large?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
