On Mon, Jul 16, 2018 at 01:16:45PM -0700, Elijah Newren wrote: > >> The basic problem here, at least for us, is that gc has enough > >> information to know it could expunge some objects, but because of how > >> it is structured in terms of several substeps (reflog expiration, > >> repack, prune), the information is lost between the steps and it > >> instead writes them out as unreachable objects. If we could prune (or > >> avoid exploding) loose objects that are only reachable from reflog > >> entries that we are expiring, then the problem goes away for us. (I > >> totally understand that other repos may have enough unreachable > >> objects for other reasons that Peff's suggestion to just pack up > >> unreachable objects is still a really good idea. But on its own, it > >> seems like a waste since it's packing stuff that we know we could just > >> expunge.) > > > > No, we should have expunged everything that could be during the "repack" > > and "prune" steps. We feed the expiration time to repack, so that it > > knows to drop objects entirely instead of exploding them loose. > > Um, except it doesn't actually do that. The testcase I provided shows > that it leaves around 10000 objects that are totally deletable and > were only previously referenced by reflog entries -- entries that gc > removed without removing the corresponding objects.
What's your definition of "totally deletable"? If the pack they were in is less than 2 weeks old, then they are unreachable but "fresh", and are intentionally retained. If it was older than 2 weeks, they should have been deleted. If you don't like that policy, you can set gc.pruneExpire to something lower (including "now", but watch out, as that can race with other operations!). But I don't think that's an implementation short-coming. It's intentional to keep those objects. It's just that the format they're in is inefficient and confuses later gc runs. -Peff
