All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: Repository corruption if objects pushed in the middle of repack
Date: Mon, 13 Jun 2022 17:32:21 -0400	[thread overview]
Message-ID: <20220613213221.iekmfjihho5ujfq2@meerkat.local> (raw)
In-Reply-To: <YqerC883GiwHiiZU@nand.local>

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

  reply	other threads:[~2022-06-13 21:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13 20:31 Repository corruption if objects pushed in the middle of repack Konstantin Ryabitsev
2022-06-13 21:18 ` Taylor Blau
2022-06-13 21:24   ` Taylor Blau
2022-06-13 21:32     ` Konstantin Ryabitsev [this message]
2022-06-13 21:36       ` Taylor Blau
2022-06-13 21:45         ` Konstantin Ryabitsev
2022-06-13 22:26           ` Chris Torek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220613213221.iekmfjihho5ujfq2@meerkat.local \
    --to=konstantin@linuxfoundation.org \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.