From: Martin Fick <mfick@codeaurora.org>
To: repo-discuss@googlegroups.com
Cc: jmelvin@codeaurora.org, jgit-dev@eclipse.org, git@vger.kernel.org
Subject: Re: Preserve/Prune Old Pack Files
Date: Wed, 04 Jan 2017 09:11:55 -0700 [thread overview]
Message-ID: <5172470.bsscxDU4yv@mfick1-lnx> (raw)
In-Reply-To: <24abd0ed58c25ce832014f9bd5bb2090@codeaurora.org>
I am replying to this email across lists because I wanted to
highlight to the git community this jgit change to repacking
that we have up for review
https://git.eclipse.org/r/#/c/87969/
This change introduces a new convention for how to preserve
old pack files in a staging area
(.git/objects/packs/preserved) before deleting them. I
wanted to ensure that the new proposed convention would be
done in a way that would be satisfactory to the git
community as a whole so that it would be more easy to
provide the same behavior in git eventually. The preserved
pack files (and accompanying index and bitmap files), are not
only moved, but they are also renamed so that they no longer
will match recursive finds looking for pack files.
I look forward to any review (it need not happen on the
change, replies to this email would be fine also), in
particular with respect to the approach and naming
conventions.
Thanks,
-Martin
On Tuesday, January 03, 2017 02:46:12 PM
jmelvin@codeaurora.org wrote:
> We’ve noticed cases where Stale File Handle Exceptions
> occur during git operations, which can happen on users of
> NFS repos when repacking is done on them.
>
> To address this issue, we’ve added two new options to the
> JGit GC command:
>
> --preserve-oldpacks: moves old pack files into the
> preserved subdirectory instead of deleting them after
> repacking
>
> --prune-preserved: prunes old pack files from the
> preserved subdirectory after repacking, but before
> potentially moving the latest old pack files to this
> subdirectory
>
> The strategy is to preserve old pack files around until
> the next repack with the hopes that they will become
> unreferenced by then and not cause any exceptions to
> running processes when they are finally deleted (pruned).
>
> Change is uploaded for review here:
> https://git.eclipse.org/r/#/c/87969/
>
> Thanks,
> James
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
next parent reply other threads:[~2017-01-04 16:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <24abd0ed58c25ce832014f9bd5bb2090@codeaurora.org>
2017-01-04 16:11 ` Martin Fick [this message]
2017-01-09 6:21 ` Preserve/Prune Old Pack Files Jeff King
2017-01-09 7:01 ` Mike Hommey
2017-01-09 10:55 ` Jeff King
2017-01-09 16:20 ` Martin Fick
2017-01-09 16:17 ` Martin Fick
2017-01-10 9:14 ` Jeff King
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=5172470.bsscxDU4yv@mfick1-lnx \
--to=mfick@codeaurora.org \
--cc=git@vger.kernel.org \
--cc=jgit-dev@eclipse.org \
--cc=jmelvin@codeaurora.org \
--cc=repo-discuss@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox