On Thu, 19 Jul 2012 21:04:17 -0400 Alex <mysqlstudent@xxxxxxxxx> 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? The one that is preferred is the one that works best. I suggest trying them all and seeing what effect they have on your workload. > > 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 The queue/scheduler is meaningless for md devices. They do not use the block-layer queuing code. The queue/scheduler setting on the actual devices is meaningful. NeilBrown
Attachment:
signature.asc
Description: PGP signature
