Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 5 Feb 2015 12:44:35 +0000 (UTC)
From: "Marcus Eriksson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12772443.1423073560000.265807.1423140275264@Atlassian.JIRA>
In-Reply-To: <JIRA.12772443.1423073560000@Atlassian.JIRA>
References: <JIRA.12772443.1423073560000@Atlassian.JIRA>
 <JIRA.12772443.1423073560705@arcas>
Subject: [jira] [Updated] (CASSANDRA-8739) Don't check for overlap with
 sstables that have had their start positions moved in LCS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Eriksson updated CASSANDRA-8739:
---------------------------------------
    Attachment: 0001-8739.patch

What I meant was that when we pick compaction candidates, we make sure that we don't cause overlap in the next level by checking the boundaries of the currently compacting sstables.

The issue is smaller than I first thought though, since DataTracker.getCompacting() actually contains the original SSTR instances which don't have their start positions moved.

The only time it fails is if L1 is empty, attaching patch to properly get the L0 compacting

> Don't check for overlap with sstables that have had their start positions moved in LCS
> --------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8739
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8739
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>             Fix For: 2.1.3
>
>         Attachments: 0001-8739.patch
>
>
> When picking compaction candidates in LCS, we check that we won't cause any overlap in the higher level. Problem is that we compare the files that have had their start positions moved meaning we can cause overlap. We need to also include the tmplink files when checking this.
> Note that in 2.1 overlap is not as big problem as earlier, if adding an sstable would cause overlap, we send it back to L0 instead, meaning we do a bit more compaction but we never actually have overlap.


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