Date: Thu, 19 Aug 2004 00:00:55 -0600 From: Scott Long <scottl@samsco.org> To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> Cc: Wilko Bulte <wb@freebie.xs4all.nl> Subject: Re: RAID-3? Message-ID: <41244217.6010102@samsco.org> In-Reply-To: <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> <20040819024359.GA85432@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41244217.6010102>