On Mon, Jun 13, 2022 at 05:18:25PM -0400, Taylor Blau wrote: > Hi Konstantin, > > On Mon, Jun 13, 2022 at 04:31:45PM -0400, Konstantin Ryabitsev wrote: > > As far as I know, the maintenance steps we are running shouldn't result in any > > missing objects, so I'm curious if it's something we're doing wrong (using > > unsafe flags) or if git isn't properly accounting for some objects that come > > in during the repack stage. We're seeing this happen fairly routinely, so it's > > not just a random fluke. > > [...] > > So I doubt that repack is doing something weird here, though it would be > extremely interseting if you were able to pause the `repack` process at > a specific point, push new objects into the repository, and reliably > demonstrate the corruption. 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. Thanks, Taylor
