[
https://issues.apache.org/jira/browse/CASSANDRA-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054859#comment-13054859
]
Sylvain Lebresne commented on CASSANDRA-2521:
---------------------------------------------
bq. Repair still keep data around while running, but that may be solved with
CASSANDRA-2816.
This is the expected behavior. Or more precisely, it all depends on what we're
talking about. When repair is working with a sstable, we cannot and we should
not delete it. Even if they have been compacted, if we're in the middle of
streaming them, we should not delete it, there is nothing we can do about it.
Now, I've tried to make it so that as soon as a file is not needed by repair
anymore, it is deleted and thus if what you're talking about is sstable that
get kept around forever, then it is a bug in the patch. To have a -Compacted
file around don't mean the sstable can be deleted and it will never be.
> Move away from Phantom References for Compaction/Memtable
> ---------------------------------------------------------
>
> Key: CASSANDRA-2521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2521
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Sylvain Lebresne
> Fix For: 1.0
>
> Attachments:
> 0001-Use-reference-counting-to-decide-when-a-sstable-can-.patch,
> 0001-Use-reference-counting-to-decide-when-a-sstable-can-v2.patch,
> 0002-Force-unmapping-files-before-deletion-v2.patch, 2521-v3.txt
>
>
> http://wiki.apache.org/cassandra/MemtableSSTable
> Let's move to using reference counting instead of relying on GC to be called
> in StorageService.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
