[
https://issues.apache.org/jira/browse/OAK-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411752#comment-15411752
]
Michael Dürig edited comment on OAK-4106 at 8/8/16 3:38 PM:
------------------------------------------------------------
[~mduerig] After reviewing FileStore.cleanup(), with the additions brought in
by OAK-4579, I think the problem with the unaccounted size increase from
concurrent commits cannot happen anymore. This was the case before since it was
based on approximateSize, but now initialSize and finalSize (needed in
reclaimed computation) are correctly computed with FileStore.size() which
reflects 100% the size of the repository.
Therefore the only thing to address here is IMO the case in which finalSize
happens to be greater than initialSize (due to concurrent commits + cleanup not
reclaiming anything). This should set reclaimed to zero and not to some
unintuitive negative number, reflecting the actual situation encountered, where
there wasn't any gain after cleanup and the repository also grew in the
meantime.
WDYT?
was (Author: dulceanu):
[~mduerig] After reviewing FileStore.cleanup(), with the additions brought in
by https://issues.apache.org/jira/browse/OAK-4579, I think the problem with the
unaccounted size increase from concurrent commits cannot happen anymore. This
was the case before since it was based on approximateSize, but now initialSize
and finalSize (needed in reclaimed computation) are correctly computed with
FileStore.size() which reflects 100% the size of the repository.
Therefore the only thing to address here is IMO the case in which finalSize
happens to be greater than initialSize (due to concurrent commits + cleanup not
reclaiming anything). This should set reclaimed to zero and not to some
unintuitive negative number, reflecting the actual situation encountered, where
there wasn't any gain after cleanup and the repository also grew in the
meantime.
WDYT?
> Reclaimed size reported by FileStore.cleanup is off
> ---------------------------------------------------
>
> Key: OAK-4106
> URL: https://issues.apache.org/jira/browse/OAK-4106
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Andrei Dulceanu
> Priority: Minor
> Labels: cleanup, gc
> Fix For: Segment Tar 0.0.10
>
>
> The current implementation simply reports the difference between the
> repository size before cleanup to the size after cleanup. As cleanup runs
> concurrently to other commits, the size increase contributed by those is not
> accounted for. In the extreme case where cleanup cannot reclaim anything this
> can even result in negative values being reported.
> We should either change the wording of the respective log message and speak
> of before and after sizes or adjust our calculation of reclaimed size
> (preferred).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
