On Thursday, March 09, 2017 10:50:21 AM jmelvin@xxxxxxxxxxxxxx wrote: > On 2017-03-07 13:33, Junio C Hamano wrote: > > James Melvin <jmelvin@xxxxxxxxxxxxxx> 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