You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/10/06 19:47:31 UTC

[jira] Commented: (CASSANDRA-473) Major compaction still leaves large set of files

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

Jonathan Ellis commented on CASSANDRA-473:
------------------------------------------

okay, so here's what is going on.  there is a feature involved, and a bug :)

the feature is that you will end up with multiple files if you try to major compact but don't have enough room.  cassandra can't r/m the old files until the new ones are finished (in the worst case), so it will cut down the compaction set to something it knows will fit in the remaining space.

the bug is that using subList in doCompaction is causing the java.util.Collections$UnmodifiableCollection.remove error, since like arrays.asList, the list objects returned by subList don't support remove().

> Major compaction still leaves large set of files
> ------------------------------------------------
>
>                 Key: CASSANDRA-473
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-473
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.5
>            Reporter: Chris Goffinet
>             Fix For: 0.5
>
>         Attachments: 473.patch, system.log
>
>
> We did a major compaction on roughly 1000-2000 files. The disk drive had a capacity of 1.6TB. The disk usage with Cassandra was 1.1TB. I saw this error, maybe this is why compaction did not finish? Attaching system.log

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.