From owner-cvs-src@FreeBSD.ORG Thu Aug 19 07:14:03 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38FDE16A4CE; Thu, 19 Aug 2004 07:14:03 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACEE443D49; Thu, 19 Aug 2004 07:14:02 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id CF4422BDFE; Thu, 19 Aug 2004 17:13:59 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 0B22C511FA; Thu, 19 Aug 2004 16:43:58 +0930 (CST) Date: Thu, 19 Aug 2004 16:43:58 +0930 From: Greg 'groggy' Lehey To: Scott Long Message-ID: <20040819071358.GT85432@wantadilla.lemis.com> References: <20040819062228.GO85432@wantadilla.lemis.com> <11555.1092897238@critter.freebsd.dk> <20040819064926.GQ85432@wantadilla.lemis.com> <412450B0.80701@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvrrZ8vH9xW05bsQ" Content-Disposition: inline In-Reply-To: <412450B0.80701@samsco.org> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: src-committers@FreeBSD.org cc: Pawel Jakub Dawidek cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Poul-Henning Kamp cc: Wilko Bulte Subject: Re: RAID-3? X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2004 07:14:03 -0000 --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--