jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-7922) Improve the operations and the reporting of the check command
Date Tue, 04 Jun 2019 15:34:07 GMT

     [ https://issues.apache.org/jira/browse/OAK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Davide Giannella updated OAK-7922:
----------------------------------
    Fix Version/s: 1.16.0

> Improve the operations and the reporting of the check command
> -------------------------------------------------------------
>
>                 Key: OAK-7922
>                 URL: https://issues.apache.org/jira/browse/OAK-7922
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>            Priority: Major
>             Fix For: 1.14.0, 1.16.0
>
>         Attachments: OAK-7922-01.patch
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message