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