[
https://issues.apache.org/jira/browse/OAK-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4106:
---------------------------------
Attachment: OAK-4106-01.patch
I changed the way {{reclaimedSize}} is computed. Now it accounts only for tar
files which existed when cleanup started. Another thing that needed
modification was the place in which {{initialSize}} is computed. Since
{{FileStore.cleanup()}} starts by closing the current writer (and adding it to
the readers list), this in turn means that index/graph/binary references will
be appended to the file, thus increasing its size. Computing {{initialSize}}
before this step led to {{reclaimedSize < 0}} when there wasn't something to
clean up.
OAK-4657 will add an IT which verifies that {{reclaimedSize >=0}} when
concurrent writes occur.
> 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
>
> Attachments: OAK-4106-01.patch
>
>
> 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)
