On Mon, Jun 13, 2022 at 05:24:27PM -0400, Taylor Blau wrote: > A much more likely explanation for what is going on has to do with the > `--unpack-unreachable` option you're using. > > In your example, any unreachable object written within the last day is > written loose, and anything else older than that is simply discarded. If > the following happens, in order: > > - an unreachable object is detected, and marked for deletion > - that object then becomes reachable via some ref-update > - then the object becomes an ancestor of some push which depends on it > - _then_ the object is deleted by repack > > ...then the repository will be missing some objects which are in its > reachable set, and thus corrupt. IOW, the `--unpack-unreachable` option > (and its successor, cruft packs) are both racy with respect to > ref-updates. > > Are you able to find evidence of that race in your logging? I would bet > that is likely what is going on here. I'm not sure that's the case, because the object that is missing is the one that didn't exist before the repack started. In the scenario you describe, the pre-existing unreachable ancestor of it would be missing, not the newly incoming object. Right? -K
