forked from git/git
-
Notifications
You must be signed in to change notification settings - Fork 196
Objects treated as missing despite being present, due to race with geometric repacking #2207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
newren
wants to merge
4
commits into
gitgitgadget:ps/odb-generic-corrupt-objects
Choose a base branch
from
newren:midx-removed-pack-recovery
base: ps/odb-generic-corrupt-objects
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
36bf2ce
replay: fail gracefully when a merge input is unreadable
newren 3f3b756
mktree: plug per-tree leak in --batch mode
newren 79ce753
mktree: do not use OBJECT_INFO_QUICK when checking objects
newren 9b0966d
packfile: recover when a multi-pack-index names a removed pack
newren File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1786,7 +1786,7 @@ static int want_object_in_pack_mtime(const struct object_id *oid, | |
| struct multi_pack_index *m = get_multi_pack_index(files->packed); | ||
|
newren marked this conversation as resolved.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Jeff King wrote on the Git mailing list (how to reply to this email): On Sat, Aug 29, 2026 at 07:00:31AM +0000, Elijah Newren via GitGitGadget wrote:
> + /*
> + * Recovery for a concurrent-repack race: a stale MIDX may still name a
> + * vanished owning pack even though the object survives in another pack
> + * the same MIDX covers. The regular fallback above skips MIDX-covered
> + * packs, and repreparing the on-disk pack set does not reload the
> + * borrowed, cached MIDX, so scan its packs directly for the survivor.
> + *
> + * Do this only on the second read, by which point repreparing packs has
> + * already had a chance to find an object merely relocated into a new,
> + * uncovered pack; only a genuine hidden duplicate reaches here.
> + */
> + if (midx_result == MIDX_FILL_OWNER_UNAVAILABLE &&
> + (flags & OBJECT_INFO_SECOND_READ)) {
> + struct multi_pack_index *m = store->midx;
> + uint32_t i;
> +
> + for (i = 0; i < m->num_packs + m->num_packs_in_base; i++) {
> + struct packed_git *p;
> +
> + if (prepare_midx_pack(m, i))
> + continue;
> + p = nth_midxed_pack(m, i);
> + if (p && packfile_fill_entry(p, oid, e, bad_pack))
> + return 1;
> + }
> + }
So I think this workaround is fine to do (as long as we are not going to
actually refresh the midx on SECOND_READ, which I agree is probably a
bigger change).
I always get confused about m->num_packs and m->num_packs_in_base, and
whether we are looking at the packs in a midx slice versus the whole
thing. I _think_ what you have here is correct, because we are iterating
from 0 up to the total number of packs, and prepare_midx_pack() etc will
look back through the incremental slices as necessary.
But I wonder if it would be simpler to just iterate over the actual pack
list in the usual way, since we already do that in this function. I
_thought_ this would work:
diff --git a/odb/source-packed.c b/odb/source-packed.c
index 90d88c0a12..86e6a80d2f 100644
--- a/odb/source-packed.c
+++ b/odb/source-packed.c
@@ -33,40 +33,19 @@ static int find_pack_entry(struct odb_source_packed *store,
for (l = store->packs.head; l; l = l->next) {
struct packed_git *p = l->pack;
- if (!p->multi_pack_index && packfile_fill_entry(p, oid, e, bad_pack)) {
+ /* ...explain tricky race case here... */
+ if (p->multi_pack_index &&
+ (midx_result != MIDX_FILL_OWNER_UNAVAILABLE ||
+ !(flags & OBJECT_INFO_SECOND_READ)))
+ continue;
+
+ if (packfile_fill_entry(p, oid, e, bad_pack)) {
if (!store->skip_mru_updates)
packfile_list_prepend(&store->packs, p);
return 1;
}
}
- /*
- * Recovery for a concurrent-repack race: a stale MIDX may still name a
- * vanished owning pack even though the object survives in another pack
- * the same MIDX covers. The regular fallback above skips MIDX-covered
- * packs, and repreparing the on-disk pack set does not reload the
- * borrowed, cached MIDX, so scan its packs directly for the survivor.
- *
- * Do this only on the second read, by which point repreparing packs has
- * already had a chance to find an object merely relocated into a new,
- * uncovered pack; only a genuine hidden duplicate reaches here.
- */
- if (midx_result == MIDX_FILL_OWNER_UNAVAILABLE &&
- (flags & OBJECT_INFO_SECOND_READ)) {
- struct multi_pack_index *m = store->midx;
- uint32_t i;
-
- for (i = 0; i < m->num_packs + m->num_packs_in_base; i++) {
- struct packed_git *p;
-
- if (prepare_midx_pack(m, i))
- continue;
- p = nth_midxed_pack(m, i);
- if (p && packfile_fill_entry(p, oid, e, bad_pack))
- return 1;
- }
- }
-
return 0;
}
but it doesn't because we don't always load the midx'd packs into the
pack list (we do it on-demand as they become useful to us). So I think
you'd essentially end up needing to do a loop like the one you have
anyway to prepare_midx_pack() on them all.
And we want to avoid doing that if we can find it outside the midx
(since that was the whole point of waiting for SECOND_READ). Which would
happen...in that loop. So we really do want to have our own
midx-specific loop like you have here.
Sorry, I know that was a lot of text to end up at "you have already
written it the best way", but it took me a while to reason through it.
The patch looks good to me. ;)
-Peff |
||
| struct pack_entry e; | ||
|
|
||
| if (m && fill_midx_entry(m, oid, &e, NULL)) { | ||
| if (m && midx_fill_entry(m, oid, &e, NULL) == MIDX_FILL_HIT) { | ||
| want = want_object_in_pack_one(e.p, oid, exclude, found_pack, found_offset, found_mtime); | ||
| if (want != -1) | ||
| return want; | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jeff King wrote on the Git mailing list (how to reply to this email):