[ 
https://issues.apache.org/jira/browse/CASSANDRA-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329158#comment-14329158
 ] 

Joshua McKenzie commented on CASSANDRA-7066:
--------------------------------------------

I much prefer the idea of us building a simple custom abstraction that handles 
our view of the state of sstable deletion rather than an amalgamation of system 
tables + file names or parsing ancestor sets in sstable metadata - both of 
those options sound overly complex to address the question of "are we done with 
this sstable?".

>From a Windows perspective, I'm immediately in favor of limiting any renaming 
>we do on grounds of ntfs being picky about that.

What you're proposing, [~benedict], sounds easier to reason about, more simple, 
and more elegant than the other options. I'm in favor.

> Simplify (and unify) cleanup of compaction leftovers
> ----------------------------------------------------
>
>                 Key: CASSANDRA-7066
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7066
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Priority: Minor
>              Labels: compaction
>             Fix For: 3.0
>
>
> Currently we manage a list of in-progress compactions in a system table, 
> which we use to cleanup incomplete compactions when we're done. The problem 
> with this is that 1) it's a bit clunky (and leaves us in positions where we 
> can unnecessarily cleanup completed files, or conversely not cleanup files 
> that have been superceded); and 2) it's only used for a regular compaction - 
> no other compaction types are guarded in the same way, so can result in 
> duplication if we fail before deleting the replacements.
> I'd like to see each sstable store in its metadata its direct ancestors, and 
> on startup we simply delete any sstables that occur in the union of all 
> ancestor sets. This way as soon as we finish writing we're capable of 
> cleaning up any leftovers, so we never get duplication. It's also much easier 
> to reason about.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to