[
https://issues.apache.org/jira/browse/CASSANDRA-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425036#comment-13425036
]
Jonathan Ellis commented on CASSANDRA-4292:
-------------------------------------------
- need to use a single DiskWriter for both compaction and flushing or we lose
on most of the benefits here. One solution: rename CompactionManager to
IOManager, and use that. Another could be to move it into StorageService.
- compactionexecutor needs to be cleaned up since it's no longer serving the
executor role. again, cleanup could be straightforward if we morph CM into
IOManager (and merge CompactionExecutor + DiskWriter). Could be nice to get
the kind of progress reporting on flushes that we now have on compaction.
- DiskWriter: Can we use CopyOnWriteArrayList instead of synchronized block?
> Per-disk I/O queues
> -------------------
>
> Key: CASSANDRA-4292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4292
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Yuki Morishita
> Fix For: 1.2
>
> Attachments: 4292-v2.txt, 4292.txt
>
>
> As noted in CASSANDRA-809, we have a certain amount of flush (and compaction)
> threads, which mix and match disk volumes indiscriminately. It may be worth
> creating a tight thread -> disk affinity, to prevent unnecessary conflict at
> that level.
> OTOH as SSDs become more prevalent this becomes a non-issue. Unclear how
> much pain this actually causes in practice in the meantime.
--
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
