Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 31 Mar 2014 17:47:18 +0000 (UTC)
From: "Yuki Morishita (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12705654.1396273832112.37593.1396288038130@arcas>
In-Reply-To: <JIRA.12705654.1396273832112@arcas>
References: <JIRA.12705654.1396273832112@arcas>
Subject: [jira] [Commented] (CASSANDRA-6958) upgradesstables does not
 maintain levels for existing SSTables
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yuki Morishita commented on CASSANDRA-6958:
-------------------------------------------

We need to cover standalone offline upgrade (sstableupgrade) as well.

> upgradesstables does not maintain levels for existing SSTables
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-6958
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6958
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Wei Deng
>            Assignee: Marcus Eriksson
>             Fix For: 2.0.7
>
>         Attachments: 0001-Use-LeveledCompactionTask-for-upgradesstables-when-L.patch
>
>
> Initially ran into this issue on a DSE 3.2 (C* 1.2) to DSE 4.0 (C* 2.0) upgrade, and then I was able to reproduce it when testing an upgrade from C* 2.0.5 to C* 2.1-beta so the problem still exists in the latest code.
> Basically after you've upgraded to the new version and run "nodetool upgradesstables" on a CF/table that has been using LCS, then all of the non-L0 SSTables will be changed to L0 in the upgraded SSTables. In other words, they don't maintain their level and will have to go through the compaction again. The problem is that if you've got thousands of non-L0 SSTables before the upgrade, then all of these files showing up in L0 will push the system to do STCS and start to build some huge L0 tables. If a user doesn't budget enough free space (for example, if they used the recommended guideline and only budgeted 10% of free space because LCS is in use), then this STCS in L0 effect will have them run out of space.


--
This message was sent by Atlassian JIRA
(v6.2#6252)