jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Dulceanu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-7672) Introduce oak-run segment-copy for moving around segments in different storages
Date Thu, 09 Aug 2018 12:45:00 GMT

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

Andrei Dulceanu updated OAK-7672:
---------------------------------
    Description: 
Often there's the need to transform a type of {{SegmentStore}} (e.g. local TarMK) into *the
exact same* counter-part, using another persistence type (e.g. Azure Segment Store). While
{{oak-upgrade}} partially solves this through sidegrades (see OAK-7623), there's a gap in
the final content because of the level at which {{oak-upgrade}} operates (node store level).
Therefore, the resulting sidegraded repository doesn't contain all the (possibly stale, unreferenced)
data from the original repository, but only the latest head state. A side effect of this is
that the resulting repository is always compacted.

Introducing a new command in {{oak-run}}, namely {{segment-copy}}, would allow us to operate
at a lower level (i.e. segment persistence), dealing only with constructs from {{org.apache.jackrabbit.oak.segment.spi.persistence}}:
journal file, gc journal file, archives and archive entries. This way the only focus of this
process would be to "translate" a segment between two persistence formats, without caring
about the node logic stored inside (referenced/unreferenced node/property).

  was:
Often there's the need to transform a type of {{SegmentStore}} (e.g. local TarMK) into *the
exact same* counter-part, using another persistence type (e.g. Azure Segment Store). While
{{oak-upgrade}} partially solves this through sidegrades (see OAK-7623), there's a gap in
the final content because of the level at which {{oak-upgrade}} operates (node store level).
Therefore, the resulting sidegraded repository doesn't contain all the (possibly stale, unreferenced)
data from the original repository, but only the latest head state. A side effect of this is
that the resulting repository is always compacted.

Introducing a new command in {{oak-run}}, namely {{segment-copy}}, would allow us to operate
at a lower level (i.e. segment persistence), dealing only with constructs from {{org.apache.jackrabbit.oak.segment.spi.persistence}}:
journal file, archives and archive entries. This way the only focus of this process would
be to "translate" a segment between two persistence formats, without caring about the node
logic stored inside (referenced/unreferenced node/property).


> Introduce oak-run segment-copy for moving around segments in different storages
> -------------------------------------------------------------------------------
>
>                 Key: OAK-7672
>                 URL: https://issues.apache.org/jira/browse/OAK-7672
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: oak-run, segment-tar
>            Reporter: Andrei Dulceanu
>            Assignee: Andrei Dulceanu
>            Priority: Major
>              Labels: tooling
>             Fix For: 1.10, 1.9.7
>
>         Attachments: OAK-7672.patch
>
>
> Often there's the need to transform a type of {{SegmentStore}} (e.g. local TarMK) into
*the exact same* counter-part, using another persistence type (e.g. Azure Segment Store).
While {{oak-upgrade}} partially solves this through sidegrades (see OAK-7623), there's a gap
in the final content because of the level at which {{oak-upgrade}} operates (node store level).
Therefore, the resulting sidegraded repository doesn't contain all the (possibly stale, unreferenced)
data from the original repository, but only the latest head state. A side effect of this is
that the resulting repository is always compacted.
> Introducing a new command in {{oak-run}}, namely {{segment-copy}}, would allow us to
operate at a lower level (i.e. segment persistence), dealing only with constructs from {{org.apache.jackrabbit.oak.segment.spi.persistence}}:
journal file, gc journal file, archives and archive entries. This way the only focus of this
process would be to "translate" a segment between two persistence formats, without caring
about the node logic stored inside (referenced/unreferenced node/property).



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

Mime
View raw message