Re: [PATCH 3/7] midx.c: prevent `expire` from removing the cruft pack
- From
Derrick Stolee <derrickstolee@github.com>
- Date
- Sep 22, 2022, 14:08 UTC
- Message-ID
- <37ffe1a6-bed9-70ce-2c66-b7a2d8c45ba9@github.com>
- In-Reply-To
- <3ae9903d2df491e291ab975c56ec78aa13d95655.1663638929.git.me@ttaylorr.com>
On 9/19/2022 9:55 PM, Taylor Blau wrote:
> The `expire` sub-command unlinks any packs that are (a) contained in the > MIDX, but (b) have no objects referenced by the MIDX.
It is important to note that this can only happen if all objects in the pack have duplicates in other pack-files.
Show 7 quoted lines
> This sub-command ignores `.keep` packs, which remain on-disk even if > they have no objects referenced by the MIDX. Cruft packs, however, > aren't given the same treatment: if none of the objects contained in the > cruft pack are selected from the cruft pack by the MIDX, then the cruft > pack is eligible to be expired. > > This is less than desireable, since the cruft pack has important
s/desireable/desirable/ (according to my spell-checker)
Show 9 quoted lines
> metadata about the individual object mtimes, which is useful to > determine how quickly an object should age out of the repository when > pruning. > > Ordinarily, we wouldn't expect the contents of a cruft pack to > duplicated across non-cruft packs (and we'd expect to see the MIDX > select all cruft objects from other sources even less often). But > nonetheless, it is still possible to trick the `expire` sub-command into > removing the `.mtimes` file in this circumstance.
I was initially unconvinced that this scenario was super-critical to keeping the .mtimes file, but I was able to think of cases where objects are duplicated out of the cruft pack due to de-thinning or otherwise inefficiently packing unreachable objects into these other pack-files.
Thanks, -Stolee