making a hot spare ... hot

making a hot spare ... hot

[Brendan Hide]

Hi all

To the point: When a disk is designated as a hot spare, would it be of 
benefit to spread copies of data chunks from the other disks onto the 
hot spare even before a failure? Has this been tried before?

If its not already being done, it'd have a small positive consequence 
for performance as well as data integrity, with relatively little to no 
negative consequences. Benefits would diminish the larger the array, 
much like the performance difference between raid3 and raid5. Read 
speeds would theoretically increase and write speeds should not decrease 
except in the case of poor hardware.

Given a 6-disk raid5 (5 "data" disks + 1 spare) array, a re-sync will 
start at 25% progress from the moment a disk gets dropped out of the 
array. The theoretical max read speed will also increase by 16% by 
reading from 6 disks instead of 5. The cons will be that, when writing, 
an extra write will need to occur to the "spare" disk. Though this 
shouldn't have any performance penalties on modern hardware I can still 
see it as being a concern.

I suspect something like this might have been suggested before - but I 
haven't been able to find any reference to something along these lines 
online. I'll welcome any discussion or links to relevant information.

Thanks.

Key:
0-F: Data Chunks
P: Parity

Layout of standard RAID5 + 1 standard spare

Disk0: 048C
Disk1: 159P
Disk2: 26PD
Disk3: 3PAE
Disk4: P7BF
Disk5: Spare (empty)

Chunks read per read "cycle": 5
Time to read all 16 data chunks: 4 cycles

Layout of standard RAID5 + 1 "hot" spare:
Disk0: 048C
Disk1: 159P
Disk2: 26PD
Disk3: 3PAE
Disk4: P7BF
Disk5: 05AF

Chunks read per "cycle": 6
Time to read all 16 data chunks: 3 cycles

-- 
__________
Brendan Hide
Mobile: brendan.cell@swiftspirit.co.za (plain text only please)
Web Africa - Internet Business Solutions
http://www.webafrica.co.za/?AFF1E97

Re: making a hot spare ... hot

[NeilBrown]

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

On Wed, 21 Sep 2011 05:30:17 +0200 Brendan Hide <brendan@swiftspirit.co.za>
wrote:

> Hi all
> 
> To the point: When a disk is designated as a hot spare, would it be of 
> benefit to spread copies of data chunks from the other disks onto the 
> hot spare even before a failure? Has this been tried before?
> 
> If its not already being done, it'd have a small positive consequence 
> for performance as well as data integrity, with relatively little to no 
> negative consequences. Benefits would diminish the larger the array, 
> much like the performance difference between raid3 and raid5. Read 
> speeds would theoretically increase and write speeds should not decrease 
> except in the case of poor hardware.
> 
> Given a 6-disk raid5 (5 "data" disks + 1 spare) array, a re-sync will 
> start at 25% progress from the moment a disk gets dropped out of the 
> array. The theoretical max read speed will also increase by 16% by 
> reading from 6 disks instead of 5. The cons will be that, when writing, 
> an extra write will need to occur to the "spare" disk. Though this 
> shouldn't have any performance penalties on modern hardware I can still 
> see it as being a concern.
> 
> I suspect something like this might have been suggested before - but I 
> haven't been able to find any reference to something along these lines 
> online. I'll welcome any discussion or links to relevant information.
> 
> Thanks.
> 
> Key:
> 0-F: Data Chunks
> P: Parity
> 
> Layout of standard RAID5 + 1 standard spare
> 
> Disk0: 048C
> Disk1: 159P
> Disk2: 26PD
> Disk3: 3PAE
> Disk4: P7BF
> Disk5: Spare (empty)
> 
> Chunks read per read "cycle": 5
> Time to read all 16 data chunks: 4 cycles
> 
> Layout of standard RAID5 + 1 "hot" spare:
> Disk0: 048C
> Disk1: 159P
> Disk2: 26PD
> Disk3: 3PAE
> Disk4: P7BF
> Disk5: 05AF
> 
> Chunks read per "cycle": 6
> Time to read all 16 data chunks: 3 cycles
> 

I see what you are getting at, but I doubt the value justifies the extra
complexity.
If you want more redundancy and have a spare device - use RAID6.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: making a hot spare ... hot

[Brendan Hide]

On 2011/09/21 06:05 AM, NeilBrown wrote:
> On Wed, 21 Sep 2011 05:30:17 +0200 Brendan Hide<brendan@swiftspirit.co.za>
> wrote:
>
>> Hi all
>>
>> To the point: When a disk is designated as a hot spare, would it be of
>> benefit to spread copies of data chunks from the other disks onto the
>> hot spare even before a failure? Has this been tried before?
> I see what you are getting at, but I doubt the value justifies the extra
> complexity.
> If you want more redundancy and have a spare device - use RAID6.
>
> NeilBrown
That makes sense then that there's no point in a hot spare when you're 
using RAID5 - as you say, rather use RAID6. This concept could be used 
on top of a RAID6 too. However, I also see what you mean by the 
complexity issue.

There's diminishing benefits when you have lots of disks and, with fewer 
disks, you're better off having a bigger RAID6. Given a typical RAID6 (8 
disks-worth of capacity), the potential improvements are still 
*relatively* significant, but much less than the numbers given 
previously. Maximum potential numbers:
read speed improvement: 9.09%
sync progress at disk fail-time before any pro-active sync work starts: 
12.5%

In my books, any trickery that improves integrity is a good thing but, 
until I have time to hack around in mdadm code (not likely at the 
moment), I guess I'll leave it to whoever else who thinks these numbers 
are worth it. :)

Thanks, all.

-- 
Brendan Hide

http://swiftspirit.co.za/

Re: making a hot spare ... hot

[David Brown]

On 21/09/2011 08:59, Brendan Hide wrote:
> On 2011/09/21 06:05 AM, NeilBrown wrote:
>> On Wed, 21 Sep 2011 05:30:17 +0200 Brendan
>> Hide<brendan@swiftspirit.co.za>
>> wrote:
>>
>>> Hi all
>>>
>>> To the point: When a disk is designated as a hot spare, would it be of
>>> benefit to spread copies of data chunks from the other disks onto the
>>> hot spare even before a failure? Has this been tried before?
>> I see what you are getting at, but I doubt the value justifies the extra
>> complexity.
>> If you want more redundancy and have a spare device - use RAID6.
>>
>> NeilBrown
> That makes sense then that there's no point in a hot spare when you're
> using RAID5 - as you say, rather use RAID6. This concept could be used
> on top of a RAID6 too. However, I also see what you mean by the
> complexity issue.
>

Correct - there /is/ no point in using a hot spare with RAID5 when you 
can use RAID6 (unless you have several RAID5 arrays with a shared hot 
spare).  There are a few types of access that are a little faster with 
RAID5 plus spare than with RAID6, but other accesses that are faster 
with the RAID6 (since you have an extra spindle to read from).

And if you are thinking of RAID6 + hot spare, then one day I hope that 
triple parity RAID6 will be supported by mdadm - it will be less 
complicated than this method.  (I've almost finished a paper explaining 
the maths of triple parity raid - I just have to tidy up the examples a 
bit.)

There is one potential improvement to hot spares that is already on 
Neil's "things to do" list - Hot Replace.  The idea there is that when 
you have a disk that is feeling poorly, but not completely dead, then 
data will be copied from it to the replacement device before the dying 
device is removed.

> There's diminishing benefits when you have lots of disks and, with fewer
> disks, you're better off having a bigger RAID6. Given a typical RAID6 (8
> disks-worth of capacity), the potential improvements are still
> *relatively* significant, but much less than the numbers given
> previously. Maximum potential numbers:
> read speed improvement: 9.09%
> sync progress at disk fail-time before any pro-active sync work starts:
> 12.5%
>
> In my books, any trickery that improves integrity is a good thing but,
> until I have time to hack around in mdadm code (not likely at the
> moment), I guess I'll leave it to whoever else who thinks these numbers
> are worth it. :)
>
> Thanks, all.
>