From owner-cvs-src@FreeBSD.ORG Thu Aug 19 02:44:08 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 835E216A4CE; Thu, 19 Aug 2004 02:44:08 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF7B443D46; Thu, 19 Aug 2004 02:44:07 +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 8DC992BD68; Thu, 19 Aug 2004 12:44:04 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 0E5F951202; Thu, 19 Aug 2004 12:14:00 +0930 (CST) Date: Thu, 19 Aug 2004 12:13:59 +0930 From: Greg 'groggy' Lehey To: Pawel Jakub Dawidek , Poul-Henning Kamp Message-ID: <20040819024359.GA85432@wantadilla.lemis.com> References: <20040817132740.GA32139@freebie.xs4all.nl> <41449.1092750244@critter.freebsd.dk> <200408161043.i7GAhfXs079045@repoman.freebsd.org> <20040817004407.GA81257@wantadilla.lemis.com> <20040817074633.GO30151@darkness.comp.waw.pl> <20040817112900.GA31635@freebie.xs4all.nl> <20040817124020.GK88156@wantadilla.lemis.com> <20040817131612.GT30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <41449.1092750244@critter.freebsd.dk> <20040817131612.GT30151@darkness.comp.waw.pl> 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: Wilko Bulte cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG Subject: RAID-3? (was: cvs commit: src MAINTAINERS) 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 02:44:08 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tuesday, 17 August 2004 at 15:44:04 +0200, Poul-Henning Kamp wrote: > In message <20040817132740.GA32139@freebie.xs4all.nl>, Wilko Bulte writes: > >> RAID-3 IIRC uses a dedicated parity disk, and small stripes. I don't th= ink >> it must be bytelevel striping. Just small enough stripes that all disks >> contribute to every I/O > > RAID3 differs from RAID5 in that you always access the entire stripe > and never have R/M/W cycles. That's not the definition I know, and I haven't been able to find it during a quick Google. I have: http://sbc.webopedia.com/TERM/R/RAID.html : "Level 3 -- Bit-Interleaved Parity: Provides byte-level striping with a dedicated parity disk. Level 3, which cannot service simultaneous multiple requests, also is rarely used." http://www.acnc.com/04_01_03.html : "The data block is subdivided ("striped") and written on the data disks. Stripe parity is generated on Writes, recorded on the parity disk and checked on Reads. Disadvantages: Transaction rate equal to that of a single disk drive at best (if spindles are synchronized) Controller design is fairly complex =20 Very difficult and resource intensive to do as a "software" RAID" The original 1988 paper talks of bit-interleaving (specifically, in the same manner that RAM works). > Typically the problem is that by doing so you get a RAID3 sectorsize > which is the sum of all non-parity sectors, a 4+1 will give you 4 x > 512 =3D 2048 and 8 + 3 will give you 4k. This looks more like RAID-4 to me. RAID-3 shouldn't increase the sector size, and there's nothing in the original definitions to suggest limitations to 2 ** n + 1 disks. But certainly the approach has all the disadvantages of RAID-3, so let's leave that one be. > Since a lot of filesystems/OS/hardware can only work with 512 byte > sectors, people have hacked around this in various ways and eventually > given up on RAID3. > > UFS/FFS works fine with 1k, 2k, 4k and larger sectorsizes and so > RAID3 is a great idea for FreeBSD, and I'd rather use RAID3 than > RAID5 myself. The real issue here is concurrency. You're tying up the bandwidth of all the disks for every transfer. That slows down throughput considerably. It's a different tradeoff than RAID-5. For things like streaming video, assuming a *single* transfer, it's excellent. But who needs that speed for streaming video? On Tuesday, 17 August 2004 at 15:16:12 +0200, Pawel Jakub Dawidek wrote: > On Tue, Aug 17, 2004 at 10:10:20PM +0930, Greg 'groggy' Lehey wrote: > +> On the contrary. RAID-3 requires byte-level striping, which is > +> ridiculous on the hardware that FreeBSD supports. > > And RAID5 isn't? So what's the difference? RAID3 requires 2^n+1 > components where n >=3D 1, so minimum is 3. I'm not here to defend RAID-5, though it certainly doesn't require sub-sector striping. I just don't see any advantage in RAID-3. > +> [...] I suspect that pjd > +> is confusing RAID-3 with RAID-4. And RAID-4 has no advantages > +> whatsoever over RAID-5. > > I'm not confusing RAID3 with RAID4. This is RAID3 and it works well. See above. > Want to compare performance with vinum's RAID5?:) Feel free. But do it with more than a single process accessing the disks. Greg -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBJBPvIubykFB6QiMRArgrAJwLJIaAeWlIf0SG8gHSR7RqufiBxACeInmL G/mO2MVzzN3s3KmYytInbo0= =QhUO -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--