[
https://issues.apache.org/jira/browse/CASSANDRA-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273796#comment-14273796
]
Joshua McKenzie commented on CASSANDRA-8562:
--------------------------------------------
+1 on v2.
We should probably augment AbstractionCompactionTask.sstables from being a dumb
collection to an object that'll mark / unmark compaction status on sstables and
provide hooks for that as it should help prevent these types of errors. Right
now, marking compacted is in a different file/object scope than unmarking,
which is in a different file/scope than this one-off fix from removing sstables
and there's no real documentation in the code to imply that removing from
sstables means you also need to unmarkCompacting and when. That kind of split
leads to errors like this being *very* easy to introduce, and having a single
"smart-collection" shared amongst users of these sstables seems better than the
current granular coupling.
As with the compaction_failure_policy, that's outside the scope of this fix.
Depending on if you agree with the reasoning we can create another ticket for
that and pursue it (assuming there's not other changes in the works I don't
know about that would obviate the need for it ;))
> Fix checking available disk space before compaction starts
> ----------------------------------------------------------
>
> Key: CASSANDRA-8562
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8562
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 2.0.12, 2.1.3
>
> Attachments:
> 0001-Check-for-available-disk-space-before-starting-compa.patch,
> 8562-2.1-v2.txt
>
>
> When starting a compaction we check if there is enough disk space available
> to start it, otherwise we might (for STCS) reduce the compaction so that the
> result could fit. Now (since CASSANDRA-8329) we check for the directory to
> write to a lot later and this can reduce the compaction after we have created
> the scanners.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
