I think the new SSTable will be in the new size. In order to do that, you need to trigger a compaction so that the new SSTables will be generated. for LCS, there is no major compaction though. You can run a nodetool repair and hopefully you will bring some new SSTables and compactions will kick in. Or you can change the $CFName.json file under your data directory and move every SSTable to level 0. You need to stop your node, write a simple script to alter that file and start the node again.
I think it will be helpful to have a nodetool command to change the SSTable Size and trigger the rebuild of the SSTables. Thanks. -Wei ----- Original Message ----- From: "Robert Coli" <rc...@eventbrite.com> To: user@cassandra.apache.org Sent: Friday, June 21, 2013 4:51:29 PM Subject: Re: Updated sstable size for LCS, ran upgradesstables, file sizes didn't change On Fri, Jun 21, 2013 at 4:40 PM, Andrew Bialecki <andrew.biale...@gmail.com> wrote: > However when we run alter the column > family and then run "nodetool upgradesstables -a keyspace columnfamily," the > files in the data directory have been re-written, but the file sizes are the > same. > > Is this the expected behavior? If not, what's the right way to upgrade them. > If this is expected, how can we benchmark the read/write performance with > varying sstable sizes. It is expected, upgradesstables/scrub/clean compactions work on a single sstable at a time, they are not capable of combining or splitting them. In theory you could probably : 1) start out with the largest size you want to test 2) stop your node 3) use sstable_split [1] to split sstables 4) start node, test 5) repeat 2-4 I am not sure if there is anything about level compaction which makes this infeasible. =Rob [1] https://github.com/pcmanus/cassandra/tree/sstable_split
