Re: propagating repo corruption across clone

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Mar 27, 2013, 15:47 UTC
Message-ID: <CAMK1S_jH-OJnH=XeCnEKvY6TkjZHZg_DLJ3KaVHNi9k0WA1REA@mail.gmail.com>
In-Reply-To: <7v1ub0rijl.fsf@alter.siamese.dyndns.org>

On Wed, Mar 27, 2013 at 8:33 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 28 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> On Wed, Mar 27, 2013 at 9:17 AM, Junio C Hamano <gitster@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?