Looks like it may have been overlooked when CF directories were added, can you create a ticket on https://issues.apache.org/jira/browse/CASSANDRA
Thanks ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 3/07/2012, at 1:15 AM, Pieter Callewaert wrote: > Hi, > > While I was typing my mail I had the idea to try with the new directory > layout. > It seems you have to change the parameter settings from 1.0 to 1.1 > In 1.0: > Param 1: <keyspace name> > Param 2: <datafile name> > In 1.1: > Param 1: <keyspace name> > Param 2: <column family name>/<datafile name> > > Don’t know if this is a bug or a breaking change ? > > Kind regards, > Pieter Callewaert > > From: Pieter Callewaert [mailto:pieter.callewa...@be-mobile.be] > Sent: maandag 2 juli 2012 15:10 > To: user@cassandra.apache.org > Subject: forceUserDefinedCompaction in 1.1.0 > > Hi guys, > > We have a 6-node 1.0.9 cluster for production and 3-node 1.1.0 cluster for > testing the new version of Cassandra. > In both we insert data in a particular CF with always a TTL of 31 days. > To clean up the files faster we use the forceUserDefinedCompaction to > manually force compaction on the old sstables which we are sure the data has > expired. > In 1.0 this works perfect, but in the 1.1 the command executes without error, > but in the log of the node I see the following: > > INFO [CompactionExecutor:546] 2012-07-02 15:05:11,837 CompactionManager.java > (line 337) Will not compact MapData024CTwT/MapData024CTwT-HOS-hc-21150: it is > not an active sstable > INFO [CompactionExecutor:546] 2012-07-02 15:05:11,838 CompactionManager.java > (line 350) No file to compact for user defined compaction > > I am pretty sure the sstable because it should contain partly expired data en > partly data which is still active. > Does this have to do something with the new directory structure from 1.1 ? Or > are the parameters changed from the function? > > Kind regards, > Pieter Callewaert
