[jira] [Resolved] (OAK-2527) Update SegmentMK header format definition

["Michael Dürig (JIRA)" <ji...@apache.org>]

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

Michael Dürig resolved OAK-2527.
--------------------------------
    Resolution: Fixed

Merged into 1.0 @ http://svn.apache.org/r1660328

> Update SegmentMK header format definition
> -----------------------------------------
>
>                 Key: OAK-2527
>                 URL: https://issues.apache.org/jira/browse/OAK-2527
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segmentmk
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>             Fix For: 1.0.12, 1.1.8
>
>
> Even though the Oak's [segment header format | http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html] defines a version, that version is not checked when running Oak. In effect this means current Oak versions pretend to be infinitely forward compatible. 
> To prevent older versions of Oak to run with incompatible, newer storage formats we need to devise a way for Oak to fail fast in that scenario. 
> One thing we could do to introduce versions checking retroactively is to redefine the segment header format from:
> {noformat}
> +--------+--------+--------+--------+--------+--------+--------+--------+
> | magic bytes: "0aK\n" in ASCII     |version |idcount |rootcount        |
> +--------+--------+--------+--------+--------+--------+--------+--------+
> {noformat}
> to: 
> {noformat}
> +--------+--------+--------+--------+--------+--------+--------+--------+
> | magic bytes: "0aK" ASCII |version |reserved|idcount |rootcount        |
> +--------+--------+--------+--------+--------+--------+--------+--------+
> {noformat}
> where version would be {{10}} for the current storage format and {{11}} for the next storage format. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)