Re: proactive disk replacement

[Reindl Harald <h.reindl@thelounge.net>]

Am 21.03.2017 um 12:56 schrieb Adam Goryachev:
> Sorry, but I'm just seeing scaremongering and things that don't compute.
> Possibly I'm just not seeing it, but I don't see your advise being given
> by a majority of "experts" either on this list or elsewhere. I'll try to
> refrain from responding beyond this one, and return to lurking and
> hopefully learning more.
>
> Also, please note that the quoting / attribution seems to be wrong
> (inverted).

only in your mail client

> On 21/3/17 22:03, Reindl Harald wrote:
>> Am 21.03.2017 um 11:54 schrieb Adam Goryachev:
>> but the point is that with RAID5/6 the recovery itself is *heavy
>> random IO* and that get *combined* with the random IO auf the normal
>> workload and that means *heavy load on the disks*
> random IO is the same as random IO, regardless of the "cause" of making
> the IO random

no - it's a matter of *how much* random IO you have - when the rebuild 
process needs to seek for parity and remaining data blocks and hence 
produces heavily head movements all over the time this is added to the 
IO of the normal workload

in case of a RAID1/10 rebuild the rbuild process itself is just a linear 
read and the only head moves of the disks is the normal workload on the 
array

> In most systems, you won't be running anywhere near the IO limits, so
> allowing your recovery some portion of IO is not an issue

IO limits don't matter here when we talk about IOPS and drive head moves 
around heavily all the time because parity and data blocks for the 
restore are spread all over the disk *and* the requested workload data 
is also somewhere else

in case of a RAID1/10 rebuild you have all the time linear IO from time 
to time interrupted by the workload on the array - that's a completly 
other stress level for a disk compared with seek for hours and days 
parity and data to restore the data for the failed disk