Re: Race condition between repack and loose-objects maintenance task

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 29, 2022 at 01:03:54PM -0400, Taylor Blau wrote:
> I see that Stolee is already on the CC list, so perhaps he could chime
> in on the above.

I haven't looked at the maintenance code too closely as of yet, but I
have a plausible explanation for why maintenance is removing loose
*unreachable* objects.

Ordinarily the loose-objects task alone will not remove any loose
objects which don't already appear in a pack. That's because we first
try to run prune-packed, and then the equivalent of `git repack -d` to
consolidate loose objects together into a single pack.

But, we only do that for the first 50,000 loose objects. Anything else
gets left around and then is likely removed by the `git gc` task which
is run separately, and after the loose-objects task.

Using cruft packs won't change the race fundamentally, but storing the
unreachable objects in a cruft pack will mean that you can keep more
objects around stored together in a single pack. In other words, making
it safe to increase the grace period beyond what you would ordinarily be
able to do with the classic pruning mechanism.

Thanks,
Taylor



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux