From owner-cvs-all@FreeBSD.ORG Thu Aug 19 07:37:37 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A586516A4CE; Thu, 19 Aug 2004 07:37:37 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0672443D4C; Thu, 19 Aug 2004 07:37:37 +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 32F842BDA1; Thu, 19 Aug 2004 17:37:34 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 4DAC4511FA; Thu, 19 Aug 2004 17:07:32 +0930 (CST) Date: Thu, 19 Aug 2004 17:07:32 +0930 From: Greg 'groggy' Lehey To: Poul-Henning Kamp Message-ID: <20040819073732.GV85432@wantadilla.lemis.com> References: <20040819070716.GS85432@wantadilla.lemis.com> <12437.1092899768@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="thwsKKN5whlRGe6j" Content-Disposition: inline In-Reply-To: <12437.1092899768@critter.freebsd.dk> 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: Scott Long cc: src-committers@FreeBSD.org cc: Pawel Jakub Dawidek cc: cvs-src@FreeBSD.org cc: John-Mark Gurney cc: cvs-all@FreeBSD.org cc: Wilko Bulte Subject: Re: RAID-3? X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2004 07:37:37 -0000 --thwsKKN5whlRGe6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 19 August 2004 at 9:16:08 +0200, Poul-Henning Kamp wrote: > In message <20040819070716.GS85432@wantadilla.lemis.com>, "Greg 'groggy' Lehey" > writes: > >>> 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. > > RAID3 is within epsilon of the single disk because all the disks > work in unison. Exactly the point I'm trying to make. For multiple transfers, all other RAID forms are faster than a single disk. > (Spindle-sync is a good idea btw). It can't harm. But how much difference does it make with modern cached drive? >>> 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. > > You're wrong. RAID-3 is good for normal usage. The point is that > you don't have to do the complicated "I have disk1 in my cache but > that is not the parity and not the one I'm writing so I need to > read 2,3 and the parity which is 4 and then write my data to disk > 5 and calculate and update the parity on 4" dance. Agreed. Easier on the programmer. The user pays. > RAID3 works by: > > A write-request: > ... > > A read-request: > ... Yes, I know all this, once we've accepted that we are no longer dealing with the real RAID-3, but a modified version. It has in common with the original RAID-3 that while we're doing this, the other requests are waiting for us to get our act together. > read parity from disk5 and check Really check every time? I would have thought you'd only use the parity disk if one of the other ones had gone down. > And that is _all_ there is to it. "What you see is all you get". >> Note, of course, that RAID-5 is relatively good on reading. The big >> disadvantage of RAID-5 is when you write. > > RAID3 doesn't suffer and is very predictable in either mode. As I pointed out earlier, predictability and performance are two different kettles of fish. >> 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. > > Forget the original paper. Why? > Original papers are full of things people have not found out yet. I'm not sure how to interpret this. Greg -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --thwsKKN5whlRGe6j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBJFi8IubykFB6QiMRAno0AJ9pxI/c5bluqijVcfngSrC9hcKV4QCfSZEj 78rxXP8+08bIe7r+VBX6Prc= =GzMZ -----END PGP SIGNATURE----- --thwsKKN5whlRGe6j--