[
https://issues.apache.org/jira/browse/CASSANDRA-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024836#comment-13024836
]
Sylvain Lebresne commented on CASSANDRA-2404:
---------------------------------------------
Minor comments: in the estimation, the index size could be slightly improved by
adding 10 * nb of keys (2 for the written size of the key + 8 for the recorded
position). It's an estimation though so not a huge deal.
But otherwise, +1.
Made me wonder (but not directly related to the ticket), wouldn't it be "safer"
when we're out of space to hold on the memtable (and thus block writes fairly
quickly) instead of dropping the memtable "fairly silently" (we throw a
RuntimeException that will be logged, but it still could be some time during
which the node seems to accept write fine but will throw them out).
> if out of disk space reclaim compacted SSTables during memtable flush
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-2404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2404
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Aaron Morton
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7.6
>
> Attachments: 2404-0.7.txt, 2404-0.8.txt
>
>
> During compaction if there is not enough disk space we invoke GC to reclaim
> unused space.
> During memtable and binary memtable flush we just error out if there is not
> enough disk space to flush the table.
> Can we make cfs.createFlushWriter() use the same logic as
> Table.getDataFileLocation() to reclaim space if needed?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
