[ https://issues.apache.org/jira/browse/CASSANDRA-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2749: ---------------------------------------- Attachment: 0003-Fixes.patch 0002-fix-unit-tests.patch 0001-2749.patch Attaching rebased patches, with a 3rd patches (0003-Fixes.patch) addressing the Pavel's remarks. More specifically: bq. o.a.c.db.Directories comment should be updated because it still uses SSTable file name without keyspace. Fixed, thanks bq. o.a.c.io.sstable.SSTableReaderTest won't compile Sorry, I forgot to check the test after a last rebase, fixed too (this involved renaming a number of sstables from test/data/legacy-sstables/hb to include the keyspace name, so that specific change is in the 2nd 'fix unit tests' patch to avoid polluting the 3rd one). bq. if you start with empty data directory you get following exception and process exits Fixed. I've actually made two modifications: the migration checks the existence of the directory to avoid the NPE during listFiles(), but I've also modified the 'should we migrate' check to detect new nodes (checking if the system keyspace directory exists) and thus not print the migration message at all. bq. on snapshot doesn't create or move (from older schema) index SSTables related to CF I'm not sure I see what this one is. Are we talking of the migration process? In any case, you made me think about secondary indexes. Maybe it is more "natural" to have secondary indexes sstables be in the same directory than the base cfs? Since the indexes name is not really something exposed (granted you don't have to be a genius to figure it out), it feels like it would slightly simplify administration to not put them in a separate directory. I've updated the patch to implement this last idea (so indexes are in the same directory than their base cf), but it would be nice to have multiple opinions on that move since we don't want to have to do a new migration in 6 month because "we've changed our mind". bq. shouldn't old "snapshots" directory be removed after move? Your right, fixed (for backups too). > fine-grained control over data directories > ------------------------------------------ > > Key: CASSANDRA-2749 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2749 > Project: Cassandra > Issue Type: New Feature > Components: Core > Reporter: Jonathan Ellis > Priority: Minor > Fix For: 1.1 > > Attachments: 0001-2749.patch, > 0001-Make-it-possible-to-put-column-families-in-subdirect.patch, > 0001-non-backwards-compatible-patch-for-2749-putting-cfs-.patch.gz, > 0002-fix-unit-tests.patch, 0003-Fixes.patch, 2749.tar.gz, > 2749_backwards_compatible_v1.patch, 2749_backwards_compatible_v2.patch, > 2749_backwards_compatible_v3.patch, 2749_backwards_compatible_v4.patch, > 2749_backwards_compatible_v4_rebase1.patch, 2749_not_backwards.tar.gz, > 2749_proper.tar.gz > > > Currently Cassandra supports multiple data directories but no way to control > what sstables are placed where. Particularly for systems with mixed SSDs and > rotational disks, it would be nice to pin frequently accessed columnfamilies > to the SSDs. > Postgresql does this with tablespaces > (http://www.postgresql.org/docs/9.0/static/manage-ag-tablespaces.html) but we > should probably avoid using that name because of confusing similarity to > "keyspaces." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira