diff options
author | Derrick Stolee <derrickstolee@github.com> | 2023-05-02 15:27:21 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2023-05-02 17:48:22 +0200 |
commit | 756f1bcd29a711075cbaecb02c923328e86a41a4 (patch) | |
tree | 512798237ba1bc3b564ba20567f194791728b88f /pack-bitmap.h | |
parent | The fifteenth batch (diff) | |
download | git-756f1bcd29a711075cbaecb02c923328e86a41a4.tar.xz git-756f1bcd29a711075cbaecb02c923328e86a41a4.zip |
fsck: verify checksums of all .bitmap files
If a filesystem-level corruption occurs in a .bitmap file, Git can react
poorly. This could take the form of a run-time error due to failing to
parse an EWAH bitmap or be more subtle such as returning the wrong set
of objects to a fetch or clone.
A natural first response to either of these kinds of errors is to run
'git fsck' to see if any files are corrupt. This currently ignores all
.bitmap files.
Add checks to 'git fsck' for all .bitmap files that are currently
associated with a multi-pack-index or pack file. Verify their checksums
using the hashfile API.
We iterate through all multi-pack-indexes and pack-files to be sure to
check all .bitmap files, not just the one that would be read by the
process. For example, a multi-pack-index bitmap overrules a pack-bitmap.
However, if the multi-pack-index is removed, the pack-bitmap may be
selected instead. Be thorough to include every file that could become
active in such a way. This includes checking files in alternates.
There is potential that we could extend this effort to check the
structure of the reachability bitmaps themselves, but it is very
expensive to do so. At minimum, it's as expensive as generating the
bitmaps in the first place, and that's assuming that we don't use the
trivial algorithm of verifying each bitmap individually. The trivial
algorithm will result in quadratic behavior (number of objects times
number of bitmapped commits) while the bitmap building operation
constructs a lattice of commits to build bitmaps incrementally and then
generate the final bitmaps from a subset of those commits.
If we were to extend 'git fsck' to check .bitmap file contents more
closely like this, then we would likely want to hide it behind an option
that signals the user is more willing to do expensive operations such as
this.
For testing, set up a repository with a pack-bitmap _and_ a
multi-pack-index bitmap. This requires some file movement to avoid
deleting the pack-bitmap during the repack that creates the
multi-pack-index bitmap. We can then verify that 'git fsck' is checking
all files, not just the "active" bitmap.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pack-bitmap.h')
-rw-r--r-- | pack-bitmap.h | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/pack-bitmap.h b/pack-bitmap.h index f0180b5276..84591f041b 100644 --- a/pack-bitmap.h +++ b/pack-bitmap.h @@ -111,4 +111,6 @@ int bitmap_is_midx(struct bitmap_index *bitmap_git); const struct string_list *bitmap_preferred_tips(struct repository *r); int bitmap_is_preferred_refname(struct repository *r, const char *refname); +int verify_bitmap_files(struct repository *r); + #endif |