You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ariel Weisberg (JIRA)" <ji...@apache.org> on 2015/03/27 22:20:54 UTC
[jira] [Resolved] (CASSANDRA-8771) Remove commit log segment
recycling
[ https://issues.apache.org/jira/browse/CASSANDRA-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ariel Weisberg resolved CASSANDRA-8771.
---------------------------------------
Resolution: Fixed
This was fixed as part of CASSANDRA-6809
> Remove commit log segment recycling
> -----------------------------------
>
> Key: CASSANDRA-8771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8771
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Labels: commitlog
> Fix For: 3.0
>
>
> For discussion
> Commit log segment recycling introduces a lot of complexity in the existing code.
> CASSANDRA-8729 is a side effect of commit log segment recycling and addressing it will require memory management code and thread coordination for memory that the filesystem will no longer handle for us.
> There is some discussion about what storage configurations actually benefit from preallocated files. Fast random access devices like SSDs, or non-volatile write caches etc. make the distinction not that great.
> I haven't measured any difference in throughput for bulk appending vs overwriting although it was pointed out that I didn't test with concurrent IO streams.
> What would it take to make removing commit log segment recycling acceptable? Maybe a benchmark on a spinning disk that measures the performance impact of preallocation when there are other IO streams?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)