[OAK-7922] Improve the operations and the reporting of the check command

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: segment-tar
• Assignee: Unassigned
• Reporter: Francesco Mari
• Created: 28/Nov/18 12:26
• Updated: 26/May/21 14:52

Description

The check command allows a user to check for both the head and the checkpoints. At the end of the execution the command outputs the consistent revisions for the head and the individual checkpoints, if any is found. Moreover, it prints an overall good revision. The consistent revisions for the head and the checkpoints could all be different. If both the head and all the checkpoints are assigned to a consistent revision, the overall good revision is the oldest of those revisions.

I wonder how useful all of this information is to a user of the command:

• I might have a revision where a checkpoint is consistent, but the head is not. In this case, I don't want to revert to that revision because my system will probably be unstable due to the inconsistent head.
• The overall good revision might still be partially inconsistent due to the way the command short-circuits the consistency check on the head and the checkpoints. If I revert to the overall good revision, the head might still be inconsistent or one of the checkpoints might be missing.

I propose to remove the --checkpoints and the --head flags and define the behaviour of the command as follows.

• The check command checks one super-root at a time in its entirety (both head and referenced checkpoints).
• The command exits as soon as a super-root is found where both the head and all the checkpoints are consistent.
• While searching, the command might find a super-root with a consistent head but one or more inconsistent checkpoint. In this case, the first of such revisions is printed, specifying which checkpoints are inconsistent.
• The user might specify a --no-checkpoints flag to skip checking the checkpoints in the steps above.

The optimisations currently implemented by the check command can be maintained. We don't need to fully traverse the head or the checkpoints if a well-known corrupted path is still corrupted in the current iteration. The approach proposed above enables additional optimisations:

• Since checkpoints are immutable, the command doesn't need to traverse a checkpoint that was inspected before. This is true regardless of the consistency of the checkpoint.
• If a super-root includes a checkpoint that was previously determined corrupted, the command can skip that super-root without further inspection.