Re: git-reflog 70 minutes at 100% cpu and counting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 16 Dec 2009, Eric Paris wrote:

> On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> > On Mon, 14 Dec 2009, Eric Paris wrote:
> > 
> > > The alternative repo is slowing pushing up to that same location.  That
> > > tar is 855838982, so just a tad bit smaller.
> > 
> > It doesn't appear to be complete yet, and not progressing either.
> 
> The alternative repo is now available (but the original is down)
> 
> I tried to run git gc --aggressive last night while I slept and got this
> as output, maybe it helps point to a solution/problem?  The git reflog
> portion ran for 5 hours and 36 minutes and appears to have finished.

Yes.  I was able to reproduce your issue.  And because of the *horrible* 
repository packing, the reflog expiration process is taking ages when 
determining object reachability at a rate of one reflog entry every 2 
seconds or so.  With 4214 entries for the fsnotify-syscall branch, and 
1352 entries for the fsnotify branch, this already takes up asignificant 
portion of the actual run time.  I'm sure if your repository was 
properly packed this would take less than a minute.

Now, repacking doesn't work because...

> $ git gc --aggressive
> error: Could not read d936ff8a7b0841b51ddf96afa24a30b016824cb2
> error: Could not read 29b6c2fb1390b4fd350a5ecc78f1156fc5d91e9f

Those objects are indeed missing from the repository.  Without them your 
repository is "broken".  Either you can find them somewhere else and 
copy them over, or salvage as much as you can by fetching the 
interesting branches into another freshly made repository.  This is 
unfortunate because I would have liked to see by how much this 
repository would have shrunk after a successful repack.

Of course, usage of alternates is recommended _only_ with repositories 
that are stable, i.e. don't ever add repositories to 
.git/objects/info/alternates if those repositories are rewinded/rebased 
and/or branches in them are deleted/replaced.  That could be a reason 
why some objects are now missing from the repository using alternates.


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]