From owner-cvs-src@FreeBSD.ORG Thu Aug 19 06:44:06 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 3E5F116A4CF for ; Thu, 19 Aug 2004 06:44:06 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 914D043D53 for ; Thu, 19 Aug 2004 06:44:05 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 30198 invoked from network); 19 Aug 2004 06:44:05 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Aug 2004 06:44:05 -0000 Received: from hydrogen.funkthat.com (ripyjs@localhost.funkthat.com [127.0.0.1])i7J6i3uU064949; Wed, 18 Aug 2004 23:44:04 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7J6i1dG064945; Wed, 18 Aug 2004 23:44:01 -0700 (PDT) Date: Wed, 18 Aug 2004 23:44:01 -0700 From: John-Mark Gurney To: "Greg 'groggy' Lehey" Message-ID: <20040819064401.GN99980@funkthat.com> References: <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> <20040819024359.GA85432@wantadilla.lemis.com> <41244217.6010102@samsco.org> <20040819062228.GO85432@wantadilla.lemis.com> <20040819062848.GM99980@funkthat.com> <20040819063843.GP85432@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040819063843.GP85432@wantadilla.lemis.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Scott Long 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 Reply-To: John-Mark Gurney 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 06:44:06 -0000 Greg 'groggy' Lehey wrote this message on Thu, Aug 19, 2004 at 16:08 +0930: > On Wednesday, 18 August 2004 at 23:28:48 -0700, John-Mark Gurney wrote: > > Greg 'groggy' Lehey wrote this message on Thu, Aug 19, 2004 at 15:52 +0930: > >>> Your quoted text also seems a bit subjective as there are very valid > >>> reasons for RAID-3, especially if one is looking for consistent > >>> low-latency transactions like in video recorders and servers. > >> > >> Well, I did use *exactly* this example. I also pointed out that the > >> relative performance of modern disk subsystems is adequate for a > >> single streaming video channel. > >> > >> Low latency depends on the number of concurrent accesses. RAID-3 > >> handles concurrent access poorly, exactly because it accesses all > >> disks for each transfer. > > > > One thing that RAID-3 has is that you never have to do a READ/MODIFY > > cycle when you do writes. Until we implement a write-through cache > > geom module, raid-5 will continue to substandard performance. > > Even then, RAID-5 might have higher bandwidth under some > circumstances. Pick your tool, and you can always find a good example and a bad example of how to use the tool. Doesn't mean it's bad. > My real question about RAID-3 remains: what use is it? This isn't > nit-picking, it's certainly not a criticism of pjd. I just don't see > any practical use on FreeBSD machines. 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."