[
https://issues.apache.org/jira/browse/OAK-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457938#comment-15457938
]
Francesco Mari commented on OAK-4740:
-------------------------------------
I made a mistake in my previous comment. The current implementation might store
a binary ID in a different segment only if its length is bigger that 4K, which
is anyway a disproportionate size for a binary ID. Just for fun, a "small"
binary ID with a length of 4K would be able to address {{2^32768}} different
binaries. If we would be able to take a picture of every atom in the universe,
we could assign a binary ID to each of them and still have some spare ones for
our selfies. The original issue reporting long binary IDs is OAK-1842, but a
proper fix for this problem was provided in OAK-3107.
> TarReader recovery skips generating the index and binary graphs
> ---------------------------------------------------------------
>
> Key: OAK-4740
> URL: https://issues.apache.org/jira/browse/OAK-4740
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Reporter: Alex Parvulescu
> Assignee: Francesco Mari
> Fix For: Segment Tar 0.0.16
>
>
> As noticed from the tar recovery bits [0] the resulting tar file would lack
> the binary reference graph and index graph. This has implications on the DSGC
> (not properly reporting binary references would result in binaries being
> GC'ed) and GC operations.
> / cc [~frm], [~mduerig]
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/TarReader.java#L216
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)