You can check your actual io utilization using "iostat -d 2 -kx".
If thats too low you may try to raise the min_sync_speed somewhere in
/sys/block/md* but it can't do magic.
If you raise it too much all other io to your raid will suffer delays.
Zitat von jonathan@xxxxxxxxxxxxxxxxxxxx:
I suspected the only move was to wait it out.
Thanks for the feedback Stan & Neil.
On 29/05/2012 5:21 PM, Stan Hoeppner wrote:
On 5/28/2012 7:56 PM, NeilBrown wrote:
On Tue, 29 May 2012 10:33:52 +1000 Jonathan Molyneux
<jonathan@xxxxxxxxxxxxxxxxxxxx> wrote:
md1 : active raid6 sde1[0] sdb1[6] sdh1[5] sdc1[4] sdg1[3] sdd1[2] sdf1[1]
7325679680 blocks super 0.91 level 6, 64k chunk, algorithm 18
[7/6] [UUUUUU_]
[=========>...........] reshape = 47.0% (689413888/1465135936)
finish=4126.9min speed=3132K/sec
The only thing to do is to wait. This is very much a seek-bound operation
and there is little room for making it go faster.
With SSDs you'd see the throughput of this operation increase by 2
orders of magnitude (100x) or more, as SSDs have application level seek
latency of ~50-80 microseconds, over 100x lower than rotational drives
which are in the 10-30 millisecond range depending on spindle speed.
Of course, cost/GB for the same total storage is 2 to 10 times higher
with SSD. Though interestingly the price of SSDs continues to fall,
whereas the rotational drive manufacturers are currently keeping drive
prices artificially high, between 50-100% higher than last year
depending on drive model, in an effort to recoup apparent financial
losses caused by the flooding in Thailand.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
