RAID-3?

[Greg 'groggy' Lehey]

[gratuitous empty lines removed]

On Thursday, 19 August 2004 at  1:03:12 -0600, Scott Long wrote:
> Greg 'groggy' Lehey wrote:
>> On Thursday, 19 August 2004 at  8:33:58 +0200, Poul-Henning Kamp wrote:
>>> In message <20040819062228.GO85432 at wantadilla.lemis.com>, "Greg 'groggy'
>>> Lehey"
>>> writes:
>>>
>>>> On Thursday, 19 August 2004 at  0:00:55 -0600, Scott Long wrote:
>>>>
>>>>> I think that you're really reading far too much into this.
>>>>
>>>> That depends on whether you care about accurate terminology or not.
>>>> Or maybe it's you who is reading too much into the matter.
>>>
>>> I think being accurate is a great thing, but accuracy of definition
>>> should never get in the way of working code.
>>
>> Agreed.  I don't think it is.
>>
>>> The main features of RAID3 are the always full stripe access which
>>> keeps your disk heads running in tandem which has desirable
>>> performance characteristica.
>>
>> ... for single accessors.
>>
>> But a single IDE drive nowadays can transfer 40 MB a second.  A 5 disk
>> RAID-3 array should thus be able to transfer 160 MB a second.  What do
>> you need that for?
>
> Video streaming and recoding would find this quite useful I would think.
> But regardless, it's not about thoroughput, it's about having
> predictable latency.  I can't stress this enough!

Probably not.  I hadn't understood this until now.  So you're talking
about applications that bypass buffer cache?

I can alway create predictable latency by sleeping a certain period of
time.  I'd personally prefer low latency.

>>> Also the fact that you can trivially add ECC instead of mere parity
>>> is a big plus.
>>
>> Ah, but that would be RAID-2.  Or something similar.
>>
>>> Raid5 with two bit ECC (sometimes called raid6)
>>
>> I thought RAID-6 was RAID-5 with two identical parity disks.  Not
>> so?
>
> There is no formal definition of RAID-6.  There are various competing
> companies that have tried to position their products as the de-facto
> RAID-6, but that isn't terribly useful here.

This makes it difficult to agree on what it looks like.

>>> whereas RAID3 in 4+2 or 8+3 is pretty trivial because of the
>>> full-stripe access pattern.
>>
>> Sure, easy coding is good.  And having written a RAID-5
>> implementation, I can believe what a nightmare that an ECC version
>> might provide.
>
> Ah, but that is the simplicity of RAID-3.  Your ECC/FEC/Parity
> calculation is relatively easy and deterministic to code since you are
> always writing to all disks at the same time.

Fine, if you don't have RAID-5 code.  If you do, what's the problem in
extending it in the same way?

> I'll concede that a general-purpose PC has challenges in meeting the
> strict interpretation of RAID-3, but what Pawel has meets enough of
> the common definition that I think that it's Close Enough and the
> vast majority of users will get what they expect from it.

I wonder how many users know what to expect from it.  That's part of
my question.  If even you, as a RAID expert, can disagree with me on
what the levels mean and what use they are in relation, how can normal
users know what to expect?  That, incidentally, is a good reason for
this discussion.

Greg
--
Note: I discard all HTML mail unseen.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040819/0dccfd7c/attachment.bin