git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Valentin Nechayev <netch@netch.kiev.ua>
To: git@vger.kernel.org
Subject: [PATCH] gc: avoid permanent repacking if pack size limit is in effect
Date: Sun, 28 Apr 2019 11:01:38 +0300	[thread overview]
Message-ID: <20190428080138.GM599@netch.kiev.ua> (raw)

With pack.packSizeLimit, a really huge repository can suffer from
repacking on any operation with it, because git detects too many
packs and tries merging them.

Setting gc.autoPackLimit cures the symptom but causes small pack
merge to be avoided at all, which isn't the good behavior we want.

Fix this by counting only packs that are relatively small. With
current filesystem behavior, the margin of 1/4 of pack size limit
looks a good default.
---
 builtin/gc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/builtin/gc.c b/builtin/gc.c
index 8943bcc3..0273d6e5 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -48,6 +48,7 @@ static const char *gc_log_expire = "1.day.ago";
 static const char *prune_expire = "2.weeks.ago";
 static const char *prune_worktrees_expire = "3.months.ago";
 static unsigned long big_pack_threshold;
+static unsigned long pack_size_limit = 0;
 static unsigned long max_delta_cache_size = DEFAULT_DELTA_CACHE_SIZE;
 
 static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
@@ -155,6 +156,7 @@ static void gc_config(void)
 	git_config_get_expiry("gc.logexpiry", &gc_log_expire);
 
 	git_config_get_ulong("gc.bigpackthreshold", &big_pack_threshold);
+	git_config_get_ulong("pack.packsizelimit", &pack_size_limit);
 	git_config_get_ulong("pack.deltacachesize", &max_delta_cache_size);
 
 	git_config(git_default_config, NULL);
@@ -229,9 +231,11 @@ static int too_many_packs(void)
 		if (p->pack_keep)
 			continue;
 		/*
-		 * Perhaps check the size of the pack and count only
-		 * very small ones here?
+		 * Check the size of the pack and count only
+		 * relatively small ones here.
 		 */
+		if (pack_size_limit > 0 && p->pack_size >= pack_size_limit / 4)
+			continue;
 		cnt++;
 	}
 	return gc_auto_pack_limit < cnt;
-- 
2.17.1


                 reply	other threads:[~2019-04-28  8:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20190428080138.GM599@netch.kiev.ua \
    --to=netch@netch.kiev.ua \
    --cc=git@vger.kernel.org \
    /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).