On 21/3/17 20:54, Reindl Harald wrote:
Am 21.03.2017 um 03:33 schrieb Jeff Allison:
I don't have a spare SATA slot I do however have a spare USB carrier,
is that fast enough to be used temporarily?
USB3 yes, USB2 don't make fun because the speed of the array depends
on the slowest disk in the spindle
and about RAID5/RAID6 versus RAID10: both RAID5 and RAID6 suffer from
the same problems - due rebuild you have a lot of random-IO load on
all remaining disks which leads in bad performance and make it more
likely that before the rebuild is finished another disk fails, RAID6
produces even more random IO because of the double parity and if you
have a Unrecoverable-Read-Error on RAID5 you are dead, RAID6 is not
much better here and the probability of a URE becomes more likely with
larger disks
RAID10: less to zero performance impact due rebuild and no random-IO
caused by the rebuild, it's just "read a disk from start to end and
write the data on another disk linear" while the only head moves on
your disks is the normal workload on the array
with disks 2 TB or larger you can make the conclusion "do not use
RAID5/6 anymore and when you do be prepared that you won't survive a
rebuild caused by a failed disk"
I can't say I'm an expert in this, but in actual fact, I disagree with
both your arguments against RAID6...
You say recovery on a RAID10 is a simple linear read from one drive (the
surviving member of the RAID1 portion) and a linear write on the other
(the replaced drive). You also declare that there is no random IO with
normal work load + recovery. I think you have forgotten that the "normal
workload" is probably random IO, but certainly once combined with the
recovery IO then it will be random IO.
In addition, you claim that a drive larger than 2TB is almost certainly
going to suffer from a URE during recovery, yet this is exactly the
situation you will be in when trying to recover a RAID10 with member
devices 2TB or larger. A single URE on the surviving portion of the
RAID1 will cause you to lose the entire RAID10 array. On the other hand,
3 URE's on the three remaining members of the RAID6 will not cause more
than a hiccup (as long as no more than one URE on the same stripe, which
I would argue is ... exceptionally unlikely).
In addition, with a 4 disk RAID6 you have a 100% chance of surviving a 2
drive failure without data loss, yet with 4 disk RAID10 you have a 50%
chance of surviving a 2 drive failure.
Sure, there are other things to consider (performance, cost, etc) but on
a reliability point, RAID6 seems to be the far better option.
Regards,
Adam
On 21 March 2017 at 01:59, Adam Goryachev
<mailinglists@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On 20/3/17 23:47, Jeff Allison wrote:
Hi all I’ve had a poke around but am yet to find something definitive.
I have a raid 5 array of 4 disks amounting to approx 5.5tb. Now
this disks
are getting a bit long in the tooth so before I get into problems I’ve
bought 4 new disks to replace them.
I have a backup so if it all goes west I’m covered. So I’m looking for
suggestions.
My current plan is just to replace the 2tb drives with the new 3tb
drives
and move on, I’d like to do it on line with out having to trash the
array
and start again, so does anyone have a game plan for doing that.
Yes, do not fail a disk and then replace it, use the newer replace
method
(it keeps redundancy in the array).
Even better would be to add a disk, and convert to RAID6, then add a
second
disk (using replace), and so on, then remove the last disk, grow the
array
to fill the 3TB, and then reduce the number of disks in the raid.
This way, you end up with RAID6...
Or is a 9tb raid 5 array the wrong thing to be doing and should I
be doing
something else 6tb raid 10 or something I’m open to suggestions.
I'd feel safer with RAID6, but it depends on your requirements.
RAID10 is
also a nice option, but, it depends...
--
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
--
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
