RAID-3?

[Greg 'groggy' Lehey]

On Thursday, 19 August 2004 at  0:56:23 -0600, Scott Long wrote:
> Greg 'groggy' Lehey wrote:
>> On Wednesday, 18 August 2004 at 23:44:01 -0700, John-Mark Gurney wrote:
>>
>>> I originaly was working on a RAID-3 module (which is possibly where
>>> pjd got his idea) that used Luigi's FEC code.  The advantage of this
>>> code was the fact that you could have n parity disks beyond the m
>>> data disks.  The advantage of this was that you could loose any n
>>> disks, and your data is still recoverable.  Unlike with RAID-4/5
>>> implementations where if you happen to loose a second disk (due to a
>>> power surge or something) while rebuilding, you'd be SOL.  That type
>>> of redundancy is good thing to have.
>>
>> I can see that as a great advantage, but it's not part of the RAID-3
>> definition, and I can't see why you couldn't expand RAID-5 in a
>> similar manner.  Am I missing something?
>
> Yes, you are!  The advantage of RAID-3 is that there are NO
> Read-Modify-Write cycles when writing blocks.

I didn't miss that, but it has nothing to do with what jmg said.
Still, let's address your statement:

> Every write takes exactly the same amount of time.

Which, including aggregate seek time, is longer than for RAID-5,
because more disks are involved.

> There is no waiting for data to be read off of any disks.

Sure there is.  There's always waiting for data to be read off disks.
That's part of the way disks are built.  You've got to seek first,
then you've got to get the head over the data.  That's why I said that
RAID-3 is only useful for sequential transfers.

Note, of course, that RAID-5 is relatively good on reading.  The big
disadvantage of RAID-5 is when you write.

> That is why it's nice to applications that require fixed latency.
> RAID-3 has no concept of stripe sizes becuase of this, unlike 4 and
> 5.

Of course it has.  Once you spread your data out over more than one
disk, you need some kind of mapping.  What we're talking about here
appears to be an implicit one sector stripe size, though the original
paper talked of a stripe size of one byte.

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-all/attachments/20040819/aa49cacf/attachment-0001.bin