Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] egit repository problem

On Sat, Jul 2, 2011 at 15:51, Matthias Sohn
<matthias.sohn@xxxxxxxxxxxxxx> wrote:
> 2011/7/2 Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>
>>
>> 2011/7/2 Shawn Pearce <spearce@xxxxxxxxxxx>
>>>
>>> On Fri, Jul 1, 2011 at 15:40, Matthias Sohn
>>> <matthias.sohn@xxxxxxxxxxxxxx> wrote:
>>> > The EGit Hudson CI build reports possible repository corruption [1]:
>>> >
>>> > Cloning repository origin
>>> > $ git clone -o origin git://egit.eclipse.org/egit.git
>>> > /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace
>>> >
>>> > ERROR: Error cloning remote repo 'origin' : Could not clone
>>> > git://egit.eclipse.org/egit.git
>>> > ERROR: Cause: Error performing git clone -o origin
>>> > git://egit.eclipse.org/egit.git
>>> > /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace
>>> > Command returned status code 128: Initialized empty Git repository in
>>> > /opt/users/hudsonbuild/.hudson/jobs/egit.gerrit/workspace/.git/
>>> > remote: aborting due to possible repository corruption on the remote
>>> > side.
>>> > fatal: error in sideband demultiplexer
>>>
>>> Time to run `git fsck --full` on egit.eclipse.org inside of the
>>> egit.git repository.
>>>
>>> I'll bet the problem is actually that the repository has a HUGE number
>>> of pack files (due to Gerrit Code Review being used on it), hasn't
>>> been repacked in a long time (because I forgot to repack it), and the
>>> Git implementation on that box croaks when the number of pack files
>>> exceeds the number of file descriptors the ulimit allows to be open at
>>> once in a process. :-)
>>>
>>> JGit can serve the repository just fine, we've long had file
>>> descriptor handling in place. Newer C Gits can do this too (I fixed it
>>> when Android had this problem). Either upgrade the Git version on
>>> egit.eclipse.org or repack the repostiory. (Or both)
>>
>> I tried repacking as described in [1] but this fails:
>> Auto packing your repository for optimum performance. You may also
>> run "git gc" manually. See "git help gc" for more information.
>> fatal: object a87f1cf0116078ffab0a8bb4b56fbcf9ff9342e4 is corrupted
>> error: failed to run repack
>> [1]+  Exit 255                git gc --auto --aggressive --prune
>> It succeeded to pack the refs but we still have 1322 pack files.
>>
>> [1] http://groups.google.com/group/repo-discuss/web/repository-repacking
>
> ok, now I got it: increased ulimit temporarily and then configured packing
> parameters and successfully ran gc on all repositories.
> This fixed the fetch and clone problems via git protocol.
> I found that none of the repositories was configured to write reflogs,
> also fixed that.

Thanks Matthias.

-- 
Shawn.


Back to the top