[
https://issues.apache.org/jira/browse/OAK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385653#comment-15385653
]
Michael Dürig commented on OAK-4105:
------------------------------------
TBH I find this 10% error a bit concerning. This means that the main consumer
of approximate size (disk space monitoring {{checkDiskSpace()}}) is also based
on bogus information.
Maybe we should take an entirely different approach:
* remove {{approximateSize}} again
* reduce the lock surface of the {{size()}} method. This should be simple
enough by creating a copy of the readers / writer inside the lock and do the
actual size calculation on that snapshot but outside of the lock.
In that case I would resolve this issue as won't fix and start with a fresh
issue.
[~frm], WDYT?
> Implement FileStore.size through FileStore.approximateSize
> ----------------------------------------------------------
>
> Key: OAK-4105
> URL: https://issues.apache.org/jira/browse/OAK-4105
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: segment-tar
> Reporter: Michael Dürig
> Assignee: Andrei Dulceanu
> Priority: Minor
> Labels: resilience
> Fix For: Segment Tar 0.0.6
>
> Attachments: OAK-4105-01.patch, OAK-4105-02.patch
>
>
> {{FileStore.size()}} is prone to lock contention and should not be called too
> often. As OAK-2879 already introduced an approach for tracking the current
> size of the file store without having to lock, we might as well promote his
> to be "the official" implementation.
> [~frm] WDYT?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
