From owner-cvs-src@FreeBSD.ORG Thu Aug 19 06:03:43 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 1803616A55D; Thu, 19 Aug 2004 06:03:43 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F04443D1D; Thu, 19 Aug 2004 06:03:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.2.73] (cpe.125.wat.v126.packetworks.net [64.235.97.125] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7J644uY067256; Thu, 19 Aug 2004 00:04:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <41244217.6010102@samsco.org> Date: Thu, 19 Aug 2004 00:00:55 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Greg 'groggy' Lehey" 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> <20040819024359.GA85432@wantadilla.lemis.com> In-Reply-To: <20040819024359.GA85432@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org 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 06:03:43 -0000 Greg 'groggy' Lehey wrote: > 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 think >>>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 > > 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 = 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 >= 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. > I think that you're really reading far too much into this. The key to all of the definitions that you quoted is that all drives are accessed during a read or write, unlike RAID-4. 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. That is a world of difference from a general purpose multi-transaction, multi-process workload, so comparing against RAID-4 or RAID-5 really doesn't make sense. Whether Pawel's implementation conforms to your ideas of RAID-3 is somewhat irrelevant. He's doing an excellent job with storage research at the moment, and I don't see why he should get bogged down with idle nit-picking. Scott