Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Aug 2004 16:43:58 +0930
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Scott Long <scottl@samsco.org>
Cc:        Wilko Bulte <wb@freebie.xs4all.nl>
Subject:   Re: RAID-3?
Message-ID:  <20040819071358.GT85432@wantadilla.lemis.com>
In-Reply-To: <412450B0.80701@samsco.org>
References:  <20040819062228.GO85432@wantadilla.lemis.com> <11555.1092897238@critter.freebsd.dk> <20040819064926.GQ85432@wantadilla.lemis.com> <412450B0.80701@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--RvrrZ8vH9xW05bsQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[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@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@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.

--RvrrZ8vH9xW05bsQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQFBJFM1IubykFB6QiMRAkH1AJ9hBw05PBlmQCRtg3nQ6p+9shQN1QCgplad
lfo8aGhcUaDC+G/PBRGSVyM=
=RNPY
-----END PGP SIGNATURE-----

--RvrrZ8vH9xW05bsQ--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040819071358.GT85432>