Re: Need to remove failed disk from RAID5 array

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Thu, 19 Jul 2012 21:04:17 -0400 Alex <mysqlstudent@gmail.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]