From: Jakma, Paul (Paul.Jakma at domain compaq.com)
Date: Thu 03 Feb 2000 - 15:32:56 GMT
> > 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.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:05:21 GMT