[ https://issues.apache.org/jira/browse/OAK-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714994#comment-16714994 ]
Francesco Mari commented on OAK-7914: ------------------------------------- [~rma61...@adobe.com], 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. See [this line|https://github.com/apache/jackrabbit-oak/blob/1.6/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/GCJournal.java#L77] and related comment for reference. I think that your attachment only includes log statements from {{FileStore}}. Have you observed log statements from {{org.apache.jackrabbit.oak.segment.file.GCJournal}} in your system? > 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 > Reporter: Francesco Mari > Priority: Critical > Fix For: 1.10 > > 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)