git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Gregory Szorc <gregory.szorc@gmail.com>
Cc: Eric Wong <e@80x24.org>, git@vger.kernel.org
Subject: Re: Warnings in gc.log can prevent gc --auto from running
Date: Mon, 29 Jul 2019 06:07:45 -0400	[thread overview]
Message-ID: <20190729100745.GA2755@sigill.intra.peff.net> (raw)
In-Reply-To: <qhdnuh$5m5r$1@blaine.gmane.org>

On Thu, Jul 25, 2019 at 07:18:57PM -0700, Gregory Szorc wrote:

> I think I've found some undesirable behavior with regards to the
> behavior of `git gc --auto`. The tl;dr is that a warning message written
> to gc.log can result in `git gc --auto` effectively disabling itself for
> gc.logExpiry. The problem is easier to trigger in 2.22 as a result of
> enabling bitmap indices for bare repositories by default and the
> behavior can easily result in performance degradation, especially on
> servers.

Yuck, thanks for reporting this.

As you note, this is a special case of a much larger problem. The other
common case is the "oops, you still have a lot of loose objects after
repacking" warning. There's more discussion and some patches here:

  https://public-inbox.org/git/20180716172717.237373-1-jonathantanmy@google.com/

though I don't think any of the work that came out of that fundamentally
solves the issue.

> I don't prescribe to know the best way to solve this problem. I just
> know it is a footgun sitting in the default Git configuration. And the
> footgun became a lot easier to fire with the introduction of warning
> messages related to bitmap indices and again when bitmap indices were
> enabled by default for bare repositories in Git 2.22.

IMHO one way to mitigate this is to simply warn less. In particular, if
we are auto-enabling bitmaps, then it doesn't necessarily make sense for
us to warn about them being disabled.

In the case of .keep files, we've already got 7328482253 (repack:
disable bitmaps-by-default if .keep files exist, 2019-06-29), which
should be in the next released version of Git. But I suspect that's
racy with respect to somebody creating .keep files, and as you note
there are other config options that might prevent us from generating
bitmaps.

Instead, it may make sense to turn the --write-bitmap-index option of
pack-objects into a tri-state: true/false/auto. Then pack-objects would
know that we are in best-effort mode, and would avoid warning in that
case. That would also let git-repack express its intentions better to
git-pack-objects, so we could replace 7328482253, and keep more of the
logic in pack-objects, which is ultimately what has to make the decision
about whether it can generate bitmaps.

-Peff

  reply	other threads:[~2019-07-29 10:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  2:18 Warnings in gc.log can prevent gc --auto from running Gregory Szorc
2019-07-29 10:07 ` Jeff King [this message]
2019-07-29 12:50   ` Ævar Arnfjörð Bjarmason
2019-07-31  4:28     ` Jeff King
2019-07-31  5:37       ` [PATCH 0/3] handling warnings due to auto-enabled bitmaps Jeff King
2019-07-31  5:37         ` [PATCH 1/3] t7700: clean up .keep file in bitmap-writing test Jeff King
2019-07-31  5:39         ` [PATCH 2/3] repack: silence warnings when auto-enabled bitmaps cannot be built Jeff King
2019-07-31 20:26           ` Junio C Hamano
2019-07-31 21:11             ` Jeff King
2019-07-31  5:40         ` [PATCH 3/3] repack: simplify handling of auto-bitmaps and .keep files Jeff King
2019-07-31 22:34           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190729100745.GA2755@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gregory.szorc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).