[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Comparing RAID5/6 rebuild times, SATA vs SAS vs SSD
From:       Paul Hartman <paul.hartman+gentoo () gmail ! com>
Date:       2013-09-23 5:05:31
Message-ID: CAEH5T2NP9mywJ9k=NPEZbggPRnDeqDTMHk1p1FHcGJS7=mnFLg () mail ! gmail ! com
[Download RAW message or body]

On Sat, Sep 21, 2013 at 11:56 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-09-20 6:43 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
>>
>> A couple weeks ago one of the drives died. I hot-swap replaced it with
>> a new one (with no down-time) and the rebuild took exactly 10 hours.
>>
>> Under normal operation, the speed of the array for contiguous
>> read/writes is about 600MB/sec, which is faster than my SSD (single
>> drive, not RAIDed).
>
>
> Thanks...
>
> But... RAID read/writes under normal operating conditions has nothing
> whatsoever to do with REBUILD speeds/times.

Of course, I just added that as additional info.

Doing the numbers, my actual rebuild speed was roughly 83MB/sec average.

> Again, the reason I'm interested in this is, if the rebuild times are
> 'blindingly fast' (as compared to the times for SATA or even fast SAS drives
> - ie, 1 hour vs your 10 hours)), then maybe a RAID6 with SSDs is back in the
> realm of doable, since you don't lose 50% of available storage with RAID6...

Mathematically, a 256GB drive will take 1/12th as long as a 3TB drive
with all other factors being equal. Using the speed of my rebuild
above, that would require less than an hour to rebuild a 256GB drive.
I can only imagine SSDs or high-class HDDs would be even faster. So I
think your goal of a 1-hour rebuild is a definite possibility,
depending on your capacity needs and CPU/controller capabilities.

You may need to tweak the RAID speed limit, cache settings, disable
NCQ, enable read-ahead, etc. to realize the maximum speed depending on
your particular hardware. There are dozens of pages online explaining
how to speed up RAID syncs like that. Many people report seeing a 5x
speed increase after making those adjustments, compared to linux
default values.

I searched for, but could not find, definitive references about SSD
RAID build times. I found a lot of tweaker/overclocker type of sites
bragging about their 3000MB/sec SSD RAID read speeds but no mention of
replacing a failed drive.

With SSDs, writes are considered the enemy, so using a pair of new
SSDs in a mirrored raid is considered bad practice, because both
drives will suffer the same number of writes, causing them both to
reach their limit at around the same time. In that case it's
considered safer to replace one of the working drives early, perhaps
rotating a few extra working drives in and out every so often, to keep
both sides of the mirror different ages or from varied manufacturing
batches.

Using SSDs in RAID5/6 also causes extra writes to occur for the
parity, of course, but not as bad as mirroring, and you get the speed
benefits from striping. One good thing with SSDs is that when they
fail, it tends to fail on a write, so the chances of it failing to
read when rebuilding in a RAID5/6 should be very small -- for HDDs
that is the biggest fear during a rebuild.

Enterprise SSDs can have 10x as many rated write/erase cycles than
consumer SSDs (for nearly 10x the price), but even the cheapest SSD
with 3000 write cycle lifetime should last you a hundred years if you
write less than a few dozen GB a day to it. In a RAID5/6 you's
spreading those writes out so it should last even longer, even with
the parity overhead.

If your RAID setup does not support passing the TRIM command to your
SSDs it could cut your speed and lifetime down significantly.

In the end it depends on your particular requirements and use case...
as always. :)

Here is a calculator that lets you plug in different drive sizes and
rebuild speeds to see how long it will take, along with some other
info:
https://www.memset.com/tools/raid-calculator/

Good luck!

[prev in list] [next in list] [prev in thread] [next in thread]