[
https://issues.apache.org/jira/browse/CASSANDRA-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190937#comment-14190937
]
Aleksey Yeschenko commented on CASSANDRA-8004:
----------------------------------------------
Still looking at it. Other than a failing CrcCheckChanceTest, things mostly
look good - or rather as good as we can make them in 2.1, without major
internal changes (hopefully we'll be able to redesign the APIs surrounding
compaction in 3.x).
Need a bit more time to make sure it doesn't break anything else though (incl.
3rd party compaction strategies, in unexpected ways).
> Run LCS for both repaired and unrepaired data
> ---------------------------------------------
>
> Key: CASSANDRA-8004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8004
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Labels: compaction
> Fix For: 2.1.2
>
>
> If a user has leveled compaction configured, we should run that for both the
> unrepaired and the repaired data. I think this would make things a lot easier
> for end users
> It would simplify migration to incremental repairs as well, if a user runs
> incremental repair on its nice leveled unrepaired data, we wont need to drop
> it all to L0, instead we can just start moving sstables from the unrepaired
> leveling straight into the repaired leveling
> Idea could be to have two instances of LeveledCompactionStrategy and move
> sstables between the instances after an incremental repair run (and let LCS
> be totally oblivious to whether it handles repaired or unrepaired data). Same
> should probably apply to any compaction strategy, run two instances and
> remove all repaired/unrepaired logic from the strategy itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
