From owner-cvs-src@FreeBSD.ORG Thu Aug 19 07:07:22 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 C8FF816A4CE; Thu, 19 Aug 2004 07:07:22 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4419C43D67; Thu, 19 Aug 2004 07:07:22 +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 422502BDA1; Thu, 19 Aug 2004 17:07:18 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 2ADED511FA; Thu, 19 Aug 2004 16:37:16 +0930 (CST) Date: Thu, 19 Aug 2004 16:37:16 +0930 From: Greg 'groggy' Lehey To: Scott Long Message-ID: <20040819070716.GS85432@wantadilla.lemis.com> References: <20040817124020.GK88156@wantadilla.lemis.com> <20040817131612.GT30151@darkness.comp.waw.pl> <20040819024359.GA85432@wantadilla.lemis.com> <41244217.6010102@samsco.org> <20040819062228.GO85432@wantadilla.lemis.com> <20040819062848.GM99980@funkthat.com> <20040819063843.GP85432@wantadilla.lemis.com> <20040819064401.GN99980@funkthat.com> <20040819065155.GR85432@wantadilla.lemis.com> <41244F17.9030007@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4PJudQiuYY5+cwwi" Content-Disposition: inline In-Reply-To: <41244F17.9030007@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: John-Mark Gurney 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:07:23 -0000 --4PJudQiuYY5+cwwi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --4PJudQiuYY5+cwwi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBJFGkIubykFB6QiMRAqEaAKCuYc5x0IHnYZRBBiwaZfrnQtZtqwCgkT6B /+nQYr1v72CKOibPEAicexE= =Is7U -----END PGP SIGNATURE----- --4PJudQiuYY5+cwwi--