You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2017/08/07 08:24:00 UTC
[jira] [Commented] (OAK-6519) Properly handle tail compactions in
deduplication caches
[ https://issues.apache.org/jira/browse/OAK-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16116248#comment-16116248 ]
Michael Dürig commented on OAK-6519:
------------------------------------
The changes proposed on OAK-6507 might resolve this issues as well. See https://issues.apache.org/jira/browse/OAK-6507?focusedCommentId=16116247&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16116247
> Properly handle tail compactions in deduplication caches
> --------------------------------------------------------
>
> Key: OAK-6519
> URL: https://issues.apache.org/jira/browse/OAK-6519
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Labels: compaction, gc
> Fix For: 1.8, 1.7.6
>
>
> This is a follow up to OAK-3349, which introduced tail compactions:
> The deduplication caches currently only take the full generations into account and ignore the tail generations. Cache generations need to be a monotonically increasing, ordered sequence consisting of the full and tail part of the gc generation. See {{FileStoreBuilder.EvictingWriteCacheManager.evictOldGeneration}}. Optimally we find a way to decouple the segment generation from the cache generations as these are really separate concerns.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)