[
https://issues.apache.org/jira/browse/OAK-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486813#comment-15486813
]
Thomas Mueller commented on OAK-4740:
-------------------------------------
> One would argue why a binary ID should be bigger than ~16K
Some background info: See https://wiki.apache.org/jackrabbit/DataStore. Small
binaries are stored inline. Binaries larger than the threshold are stored
externally. The best threshold (which binaries are stored inline) depends on
many factors, for example the file system block sizes of 4K, but for S3 (for
example) it might make sense to use a larger value. I have seen 32 KB as well.
It is a configurable setting, so limiting the size is problematic.
> 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)
