[
https://issues.apache.org/jira/browse/CASSANDRA-7386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099753#comment-14099753
]
Robert Stupp commented on CASSANDRA-7386:
-----------------------------------------
I guess, what [~lyubent] sais is, that he started with C* configured to use 2
disks for data directories. Then added data to it.
After that, he restarted C* with 5 more drives (7 in sum now) and resumed
adding data to the node.
The 5 new drives were used for new sstables (because they have a higher "write
value" since these 5 new drives have more disk space left).
So it seems to work as expected.
I'm looking forward to see the results with busy disk results, when I/O
read/write usage comes into play.
> JBOD threshold to prevent unbalanced disk utilization
> -----------------------------------------------------
>
> Key: CASSANDRA-7386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7386
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Lohfink
> Assignee: Robert Stupp
> Priority: Minor
> Fix For: 2.1.1
>
> Attachments: 7386-v1.patch, 7386v2.diff, Mappe1.ods,
> mean-writevalue-7disks.png, patch_2_1_branch_proto.diff,
> sstable-count-second-run.png
>
>
> Currently the pick the disks are picked first by number of current tasks,
> then by free space. This helps with performance but can lead to large
> differences in utilization in some (unlikely but possible) scenarios. Ive
> seen 55% to 10% and heard reports of 90% to 10% on IRC. With both LCS and
> STCS (although my suspicion is that STCS makes it worse since harder to be
> balanced).
> I purpose the algorithm change a little to have some maximum range of
> utilization where it will pick by free space over load (acknowledging it can
> be slower). So if a disk A is 30% full and disk B is 5% full it will never
> pick A over B until it balances out.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
