Re: [PATCH] repack: Add options to preserve and prune old pack files
- From
- Martin Fick <mfick@codeaurora.org>
- Date
- Mar 9, 2017, 18:45 UTC
- Message-ID
- <4065744.f4TKuYAukl@mfick1-lnx>
- In-Reply-To
- <1d816bbb08b228ece9a74ffcdfb7a5b1@codeaurora.org>
On Thursday, March 09, 2017 10:50:21 AM jmelvin@codeaurora.org wrote:
Show 48 quoted lines
> 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