From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, karthik nayak <karthik.188@gmail.com>
Subject: Re: [PATCH v2 3/3] refs/files: use heuristic to decide whether to repack with `--auto`
Date: Wed, 04 Sep 2024 08:24:44 -0700 [thread overview]
Message-ID: <xmqqmskncugz.fsf@gitster.g> (raw)
In-Reply-To: <49f953142b1b20a63102b87a1d96f5bc1f79da82.1725439407.git.ps@pks.im> (Patrick Steinhardt's message of "Wed, 4 Sep 2024 10:53:08 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> Introduce a heuristic that decides whether or not it is worth to pack
> loose references. The important factors to decide here are the number of
> loose references in comparison to the overall size of the "packed-refs"
> file. The bigger the "packed-refs" file, the longer it takes to rewrite
> it and thus we scale up the limit of allowed loose references before we
> repack.
>
> As is the nature of heuristics, this mechansim isn't obviously
> "correct", but should rather be seen as a tradeoff between how much
> resources we spend packing refs and how inefficient the ref store
> becomes. For all I can say, we have successfully been using the exact
> same heuristic in Gitaly for several years by now.
This seems to hit the balance between the thoroughness of repack
(leaving fewer loose refs is good) and the frequencey (doing repack
less often is good) in a quite sensible way.
I also have to wonder if it adds a good component to the heuristics
to leave younger loose refs (wrt mtime) out of packed-refs, with the
expectation that they are more likely to be updated again soon than
refs that were written long time ago and stayed the same value.
Thanks.
next prev parent reply other threads:[~2024-09-04 15:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 13:48 [PATCH 0/2] refs/files: use heuristic to decide whether to repack with `--auto` Patrick Steinhardt
2024-09-02 13:48 ` [PATCH 1/2] t0601: merge tests for auto-packing of refs Patrick Steinhardt
2024-09-02 13:48 ` [PATCH 2/2] refs/files: use heuristic to decide whether to repack with `--auto` Patrick Steinhardt
2024-09-03 9:00 ` karthik nayak
2024-09-03 9:23 ` Patrick Steinhardt
2024-09-03 18:23 ` Junio C Hamano
2024-09-04 7:42 ` Patrick Steinhardt
2024-09-04 16:15 ` Junio C Hamano
2024-09-04 8:49 ` Patrick Steinhardt
2024-09-05 8:44 ` karthik nayak
2024-09-04 8:52 ` [PATCH v2 0/3] refs/files: use heuristics " Patrick Steinhardt
2024-09-04 8:53 ` [PATCH v2 1/3] wrapper: introduce `log2u()` Patrick Steinhardt
2024-09-04 8:53 ` [PATCH v2 2/3] t0601: merge tests for auto-packing of refs Patrick Steinhardt
2024-09-04 8:53 ` [PATCH v2 3/3] refs/files: use heuristic to decide whether to repack with `--auto` Patrick Steinhardt
2024-09-04 15:24 ` Junio C Hamano [this message]
2024-09-05 9:58 ` Patrick Steinhardt
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmskncugz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=ps@pks.im \
/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.
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 NNTP newsgroup(s).