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 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.