Skip to content

check --repair: a full check rebuilds a corrupt chunks index from all packs twice #10434

Description

@ThomasWaldmann

Split out of #10318 (point 3), refs #8476.

Problem

With a corrupt chunks index and no pack errors, a full borg check --repair rebuilds the index from all packs twice:

  1. Repository.check() rebuilds the index from every pack and stores it
    (repository.py:1700, slow_rebuild=True, write_immediately=True).
  2. ArchiveChecker.check() then invalidates that index and rebuilds it from every pack again
    (archive.py:2324, slow_rebuild=repair), and finish() stores it again.

Both walks validate every object (metadata slot read + decryption per object), so the packs are read and
decrypted twice and the index is written twice.

Proposal

In a full check, leave the rebuild to the archives phase: Repository.check() already gets repo_only
from check_cmd.py, so it can rebuild the index only if repo_only is set.

This is simpler than letting the archives phase reuse the index the repository check built: with
--repair, the archives phase rebuilds from the packs even if the stored index is intact, so reusing it
would need an extra "index was just rebuilt" signal between the two phases.

Consequences:

  • In a full check, the "Repository index was corrupted and has been rebuilt from the packs." message and the
    count of skipped byte ranges move to the archives phase (note_dropped_objects).
  • If the archives phase gets interrupted, the index stays corrupt and is rebuilt on next use, as with
    today's "rebuild interrupted" path.

Related question

If some packs are corrupt, Repository.check() does not rebuild the index (refs #8572), but in a full
--repair the archives phase rebuilds it from all packs anyway (objects failing validation are left out).
So that guard only has an effect for --repository-only --repair. Decide whether that is intended.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions