Re: [egit-dev] egit repository problem

[Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>]

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. 

-- 
Matthias