Alex wrote:
Hi,
That's a good argument for not using "whole disk" array members, a partition can
be started at a good offset and may perform better. As for the speed, since it
is reconstructing the array data (hope the other drives are okay), every block
written requires three blocks read and a reconstruct in cpu and memory. You can
use "blockdev" to increase readahead, and set the devices to use the deadline
scheduler, that _may_ improve things somewhat, but you have to read three block
to write one, so it's not going to be fast.
Read-ahead has absolutely no effect in this context.
Read-ahead is a function of the page cache. When filling the page cache,
read-ahead suggests how much more to be read than has been asked for.
resync/recovery does not use the page cache, consequently the readahead
setting is irrelevant.
IO scheduler choice may make a difference.
It's already set for cfq. I assume that would be the preferred over deadline?
I set it on the actual disk devices. Should I also set it on md0/1
devices as well? It is currently 'none'.
/sys/devices/virtual/block/md0/queue/scheduler
Never tried doing the array itself, but do the underlying devices.
--
Bill Davidsen <davidsen@xxxxxxx>
We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination. -me, 2010
--
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
