cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-473) Major compaction still leaves large set of files
Date Tue, 06 Oct 2009 17:47:31 GMT


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:
>             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.

View raw message