[
https://issues.apache.org/jira/browse/OAK-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717510#comment-16717510
]
Tom Blackford commented on OAK-7914:
------------------------------------
{quote}I'm not able to reproduce this issue. There is a guard in the code
handling the {{gc.log}} that prevents it from being updated if the compaction
phase fails and doesn't install a new head revision\{quote}
Hey [~frm] - thanks for checking... yeah - I think the issue was that the
ownership of the file was sending the logging off - we were indeed seeing the
error [1] until I fixed that, and then once I corrected that the original issue
seemed to go away,
Apologies for the false alarm.
[1]
{code:java}
16.11.2018 02:45:38.645 *ERROR* [TarMK revision gc
[/mnt/crx/author/crx-quickstart/repository/segmentstore]]
org.apache.jackrabbit.oak.segment.file.GCJournal Error writing gc journal
java.nio.file.AccessDeniedException:
/mnt/crx/author/crx-quickstart/repository/segmentstore/gc.log at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at
sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107){code}
> Cleanup updates the gc.log after a failed compaction
> ----------------------------------------------------
>
> Key: OAK-7914
> URL: https://issues.apache.org/jira/browse/OAK-7914
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Affects Versions: 1.6.15
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Priority: Critical
> Fix For: 1.6.16
>
> Attachments: compaction.log
>
>
> The {{gc.log}} is always updated during the cleanup phase, regardless of the
> result of the compaction phase. This might cause a scenario similar to the
> following.
> - A repository of 100GB, of which 40GB is garbage, is compacted.
> - The estimation phase decides it's OK to compact.
> - Compaction produces a new head state, adding another 60GB.
> - Compaction fails, maybe because of too many concurrent commits.
> - Cleanup removes the 60GB generated during compaction.
> - Cleanup adds an entry to the {{gc.log}} recording the current size of the
> repository, 100GB.
> Now, let's imagine that compaction is run shortly after that. The amount of
> content added to the repository is negligible. For the sake of simplicity,
> let's say that the size of the repository hasn't changed. The following
> happens.
> - The repository is 100GB, of which 40GB is the same garbage that wasn't
> removed above.
> - The estimation phase decides it's not OK to compact, because the {{gc.log}}
> reports that the latest known size of the repository is 100GB, and there is
> not enough content to remove.
> This is in fact a bug, because there are 40GB worth of garbage in the
> repository, but estimation is not able to see that anymore. The solution
> seems to be not to update the {{gc.log}} if compaction fails. In other words,
> {{gc.log}} should contain the size of the *compacted* repository over time,
> and no more.
> Thanks to [~rma61...@adobe.com] for reporting it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
