From: Taylor Blau <me@ttaylorr.com>
To: Gregory Szorc <gregory.szorc@gmail.com>
Cc: git@vger.kernel.org, stolee@gmail.com
Subject: Re: Race condition between repack and loose-objects maintenance task
Date: Wed, 29 Jun 2022 13:21:14 -0400 [thread overview]
Message-ID: <YryKCl5J1Em89d3e@nand.local> (raw)
In-Reply-To: <CAKQoGakSFaNm10ZeTKc8XtTcD0JW19CZP1OwA4j7W__iBQaJfg@mail.gmail.com>
On Wed, Jun 29, 2022 at 10:16:38AM -0700, Gregory Szorc wrote:
> > In either case, my recommendation would be to keep those unreachable
> > objects which haven't yet aged out of the repository around for longer,
> > which will decrease the likelihood of seeing the race.
>
> We had to lower gc.pruneExpire from its default of 1 hour because
> otherwise this would result in the creation of thousands of loose
> objects. This is normally acceptable. However, on NFS, the churn from
> lots of file creation and deletion resulted in acceptable performance
> degradation. We had to lower gc.pruneExpire to minimize the damage.
Makes sense. Having a shorter gc.pruneExpire makes the race much more
likely to occur in practice, so I'm glad that we have a plausible
confirmation that that's what's going on in your repository.
> > See Documentation/technical/cruft-packs.txt for more information about
> > cruft packs.
>
> Yes, I saw this new feature in the Git release this week and am hoping
> to roll it out to better mitigate this general problem! With cruft
> packs, I anticipate being able to restore a longer gc.pruneExpire
> value as they should mitigate the NFS performance badness we're
> working around. Thank you for confirming it should help with the
> problem.
That should definitely help. Let me know if you have any questions, and
thanks for trying it out!
Thanks,
Taylor
next prev parent reply other threads:[~2022-06-29 17:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 16:55 Race condition between repack and loose-objects maintenance task Gregory Szorc
2022-06-29 17:03 ` Taylor Blau
2022-06-29 17:10 ` Taylor Blau
2022-06-29 17:16 ` Gregory Szorc
2022-06-29 17:21 ` Taylor Blau [this message]
2022-06-30 0:44 ` Gregory Szorc
2022-06-30 3:19 ` Taylor Blau
2022-06-30 3:23 ` Taylor Blau
2022-06-30 20:12 ` Junio C Hamano
2022-07-05 18:43 ` Gregory Szorc
2022-07-06 8:50 ` Ævar Arnfjörð Bjarmason
2022-07-20 1:40 ` Gregory Szorc
2022-07-20 9:52 ` Ævar Arnfjörð Bjarmason
2022-07-26 16:22 ` Gregory Szorc
2022-07-26 18:11 ` Ævar Arnfjörð Bjarmason
2022-07-20 1:41 ` Gregory Szorc
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=YryKCl5J1Em89d3e@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gregory.szorc@gmail.com \
--cc=stolee@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.