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
--
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
