From: Martin Fick <mfick@codeaurora.org>
To: jmelvin@codeaurora.org
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, nasserg@codeaurora.org, peff@peff.net,
sbeller@google.com
Subject: Re: [PATCH] repack: Add options to preserve and prune old pack files
Date: Thu, 09 Mar 2017 11:45:06 -0700 [thread overview]
Message-ID: <4065744.f4TKuYAukl@mfick1-lnx> (raw)
In-Reply-To: <1d816bbb08b228ece9a74ffcdfb7a5b1@codeaurora.org>
On Thursday, March 09, 2017 10:50:21 AM
jmelvin@codeaurora.org wrote:
> On 2017-03-07 13:33, Junio C Hamano wrote:
> > James Melvin <jmelvin@codeaurora.org> writes:
> >> These options are designed to prevent stale file handle
> >> exceptions during git operations which can happen on
> >> users of NFS repos when repacking is done on them. 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).
> >
> > I find it a very sensible strategy to work around NFS,
> > but it does not explain why the directory the old ones
> > are moved to need to be configurable. It feels to me
> > that a boolean that causes the old ones renamed
> > s/^pack-/^old-&/ in the same directory (instead of
> > pruning them right away) would risk less chances of
> > mistakes (e.g. making "preserved" subdirectory on a
> > separate device mounted there in a hope to reduce disk
> > usage of the primary repository, which may defeat the
> > whole point of moving the still-active file around
> > instead of removing them).
>
> Moving the preserved pack files to a separate directory
> only helped make the pack directory cleaner, but I agree
> that having the old* pack files in the same directory is
> a better approach as it would ensure that it's still on
> the same mounted device. I'll update the logic to reflect
> that.
>
> As for the naming convention of the preserved pack files,
> there is already some logic to remove "old-" files in
> repack. Currently this is the naming convention I have
> for them:
>
> pack-<sha1>.old-<ext>
> pack-7412ee739b8a20941aa1c2fd03abcc7336b330ba.old-pack
>
> One advantage of that is the extension is no longer an
> expected one, differentiating it from current pack files.
>
> That said, if that is not a concern, I could prefix them
> with "preserved" instead of "old" to differentiate them
> from the other logic that cleans up "old-*". What are
> your thoughts on that?
>
> preserved-<sha1>.<ext>
> preserved-7412ee739b8a20941aa1c2fd03abcc7336b330ba.pack
Some other proposals so that the preserved files do not get
returned by naive finds based on their extensions,
preserved-<sha1>.<ext>-preserved
preserved-7412ee739b8a20941aa1c2fd03abcc7336b330ba.pack-
preserved
or:
preserved-<sha1>.preserved-<ext>
preserved-7412ee739b8a20941aa1c2fd03abcc7336b330ba.preserved-
pack
or maybe even just:
preserved-<ext>-<sha1>
preserved-pack-7412ee739b8a20941aa1c2fd03abcc7336b330ba
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2017-03-09 18:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 16:40 [PATCH] repack: Add options to preserve and prune old pack files James Melvin
2017-03-07 20:33 ` Junio C Hamano
2017-03-09 17:50 ` jmelvin
2017-03-09 18:45 ` Martin Fick [this message]
2017-03-10 21:52 ` jmelvin
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=4065744.f4TKuYAukl@mfick1-lnx \
--to=mfick@codeaurora.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jmelvin@codeaurora.org \
--cc=nasserg@codeaurora.org \
--cc=peff@peff.net \
--cc=sbeller@google.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;
as well as URLs for NNTP newsgroup(s).