On Nov 11, 2007, at 11:21 PM, Nicolas Pitre wrote:

quoted text
> On Sun, 11 Nov 2007, bob wrote:
>
>> I applied the patch and these commands:
>>
>> cd rmwHtmlOld
>> rm -fr .git
>> git init
>> git config core.compression 0
>> git add .
>
> Note that I did "git config core.compression 0" simply to disable
> zlib compression altogether when creating the test repo just so it  
> gets
> created faster.  even then, auto-generating and cloning a 8GB test
> repository isn't particularly quick.
	I wasn't sure why you used that, but figured that I should put it
	in, because you did.  And you are very correct that these tests
	can take a very long time.
quoted text
>
>> I then got the same error as before, "Bus error".  Rats!
>
> Do you get that with a 32-bit or 64-bit build of Git?
	On that machine, I changed the config.mak to generate nothing
	but a 64-bit build.  And activity monitor shows it as 64-bit
	when I am running it. Also, off_t is 64 bit on regular
	MacOSX and as a 64-bit program supported by the
	latest MacOSX.
quoted text
>
>> Then I modified your script since I do not have seq or
>> your test-genrandom.
>
> test-genrandom is built with Git.  It is just not installed anywhere.
>
>> I substituted:
>>
>> dd count=XX  if=/dev/random of=file_$i
>>
>> where XX is adjusted to meet dd's requirements.  Also,
>
> Again I used test-genrandom instead of /dev/random or /dev/urandom
> simply because the former is much faster.
	I didn't know that it existed, since I am not that familiar with the
	internals and source directory for git.
quoted text
>
>> I found after searching for a while, that the following
>> works just like your seq command:
>>
>> xyzzy="1 2 3 4"
>> for i in $xyzzy
>> do
>> ...
>> done
>>
>> Your script then ran flawlessly.
>
> However 'seq -w 1 2 63' should be replaced  with "01 03 05 07 09 11 13
> 15" and so on up to 63, and 'seq -w 2 2 64' is "02 04 06 08 10 12 16"
> and so on.
	That I missed but the files added up to quite a bit over 8gigs,
	because my count calculation was off.  So, I thought that it
	was adequate for the testing.  Based on above, it was
	quite a few files less as well.
quoted text
>
>> I looked through index-pack.c some more, but it is
>> very hard to figure it out without doing a lot of research
>> since there doesn't seem to be anything that describes
>> the layout of a pack.  The link towards the end of the user's
>> manual doesn't work for me.
>
> Look at Documentation/technical/pack-format.txt in the Git source  
> tree.
Thanks.
quoted text
>
>> The difference between your test and my data is that
>> instead of having a few large files, I have 11,500 files
>> of varying sizes.  On average though, the file size is
>> about 370k.
>
> Are you saying that the test repo with big files works for you but not
> your own data set?
	That is correct, but you are probably correct that this is a separate
	problem, because it is only occurring on the 64-bit side.  The 32-bit
	side is running without error.
quoted text
>
> Would you please recap what your problem is?
	With more testing last night, I believe that the problem on the 32-bit
	side has been fixed.  But the 'Bus error' on 64-bit side persists.  I
	agree that I was combining it and probably shouldn't have.
quoted text
> With my one line patch you should not get the "serious inflate
> inconsistency" error anymore.  The bus error must be another issue.
I no longer do on the 32-bit side.
quoted text
>
>
> Nicolas



I am going to wait on the 64-bit problem until MacOSX 10.5 (Leopard)
settles down a bit.  It has a few bugs in it.  I will submit the  
crashreporter
issue to Apple. Currently, I don't have the time to commit a lot to  
git right
now.

As Apple comes out with new subreleases, I will retry my data.
If it doesn't get resolved after a subrelease or two, then I dig  
deeper and
hopefully have more time to devote to it at that point.

Thank you, I do appreciate your help and your patience.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html