[ILUG] Hardware RAID & partitions

[Jakma, Paul]

> > then the controller is parity-bound. RAID5 should be faster 
> at writing than
> > RAID1 if the controller can do the parity calculations fast enough.
> 
> Inclined to disagree here. No matter how fast the raid5 
> implementation,
> it still has to do two reads (data and parity blocks), a 
> parity calculation
> and two writes (data and parity blocks) for every individual 
> write. A raid1 
> only has to do two writes, and no parity calculation. Quite apart from
> the extra work, the raid5 scenario has a serialisation issue 
> - it has to
> read twice, *then* calculate parity, *then* write twice. The raid1
> scenario only involves two writes which can Just Happen.
> 

i don't agree. RAID5 doesn't need to read in order to write.

Controller has data of size stripe to write out.
RAID5:

stripe is divided into n chunks, where n-1=# of disks.
parity is calculculated.
stripe/n(X) is written to each disk(X)

RAID1:
stripe must be written to each disk(X)

In the old days the parity calculation was quite an overhead i agree. But
given Moore's law, it's safe to assume that this overhead is now negligable.
eg the SA110 on Mylex ExtremeRAID is also used by empeg.com to play mpg-3's
so it's no slouch. 

So assuming that modern controllers are not parity-calculation bound, then
RAID5 should beat RAID1 for performance, due to the inherent striping of
RAID5 on both read and writes.

> Fair enough. Me, if I was pretty sure I was only going to use 
> 18GB, I'd
> go with the 18GB raid1 over the 27GB raid5. If I needed 27GB, I'd prob
> just get more disks and raid1 or raid1+0 them. :-)
> 
> As you say, rack space isn't cheap. And when there are *lots* of disks
> to be raid-ed, raid5 looks more and more attractive. Especially if the
> data is pretty much static.
> 

i don't accept the static bit. like i said, slow RAID5 means you have a crap
old controller.

> I don't accept that raid5 is necessarily faster at reading 
> either, though.
> Any raid1 controller worth its salt will interleave requests 
> onto both 
> disks in a pair.

but that's on a 'first to the drive head for this stripe' basis. RAID1 can't
read in parallel from 2 disks. In RAID5 a single stripe is read in parallel.

> Any raid1 controller worth its salt will 
> also trivially
> do striping (1+0/0+1). (*)
> 

that's a different ball game, else i can just say 5+0. :)

> :-)
> 
> Other reasons I like raid1 (and its striped friends) are:
> o In theory, Up to half of the disks in an array can fail and 
> still have the 
>   array accessible with no performance degradation. You can 
> even get a 
>   performance improvement. :-)

but you pay for that in both disk space and read performance. And also, i
argue, write performance.

> o Beyond a certain point, cost of backup starts to make the 
> cost of disk
>   *drives* look trivial and the cost of (filled) disk *space* 
> look more
>   and more expensive. Raid1 treats the cost of disks drives 
> with contempt
>   and disk *space* with reverence.

firstly, the backup cost is related to your logical drive space. Whether
that logical space is made with RAID1 or 5 is irrelevant. 

Secondly, isn't treating the cost of drives with contempt, the same as
treating disk space with contempt?

> o If I want redundancy and performance, raid1 is my friend. 
> If I just want
>   performance, I'll go with raid0. If I just want redundancy, I'll go
>   with raid5. It's been a while since I wanted redundancy without
>   performance. :-)
> 

Or you can have RAID5, and have nearly the same performance as 0, with
nearly the same redundancy as 1. :)

> Wesley.
> 
> (*) Instead of classical raid1 over multiple pairs - where 
> "once one pair is
>     full, it starts on the second". Eugh.
> 

-paul jakma.