David Turner <novalis@xxxxxxxxxxx> writes:
> I'm a bit confused by the message "disabling bitmap writing, as some
> objects are not being packed". I see it the my gc.log file on my git
> server.
> 1. Its presence in the gc.log file prevents future automatic garbage
> collection. This seems bad. I understand the desire to avoid making
> things worse if a past gc has run into issues. But this warning is
> non-fatal; the only consequence is that many operations get slower. But
> a lack of gc when there are too many packs causes that consequence too
> (often a much worse slowdown than would be caused by the missing
> bitmap).
>
> So I wonder if it would be better for auto gc to grep gc.log for fatal
> errors (as opposed to warnings) and only skip running if any are found.
> Alternately, we could simply put warnings into gc.log.warning and
> reserve gc.log for fatal errors. I'm not sure which would be simpler.
I am not sure if string matching is really a good idea, as I'd
assume that these messages are eligible for i18n.
329e6e8794 ("gc: save log from daemonized gc --auto and print it
next time", 2015-09-19) wanted to notice that auto-gc is not
making progress and used the presense of error messages as a cue.
In your case, I think the auto-gc _is_ making progress, reducing
number of loose objects in the repository or consolidating many
packfiles into one, and the message is only about the fact that
packing is punting and not producing a bitmap as you asked, which
is different from not making any progress. I do not think log vs
warn is a good criteria to tell them apart, either.
In any case, as the error message asks the user to do, the user
eventually wants to correct the root cause before removing the
gc.log; I am not sure report_last_gc_error() is the place to correct
this in the first place.
> 2. I don't understand what would cause that message. That is, what bad
> thing am I doing that I should stop doing? I've briefly skimmed the
> code and commit message, but the answer isn't leaping out at me.
Enabling bitmap generation for incremental packing that does not
cram everything into a single pack is triggering it, I would
presume. Perhaps we should ignore -b option in most of the cases
and enable it only for "repack -a -d -f" codepath? Or detect that
we are being run from "gc --auto" and automatically disable -b? I
have a feeling that an approach along that line is closer to the
real solution than tweaking report_last_gc_error() and trying to
deduce if we are making any progress.