RAID-3? (was: cvs commit: src MAINTAINERS)
Greg 'groggy' Lehey
grog at FreeBSD.org
Wed Aug 18 19:44:08 PDT 2004
On Tuesday, 17 August 2004 at 15:44:04 +0200, Poul-Henning Kamp wrote:
> In message <20040817132740.GA32139 at 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:
"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."
"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.
> Want to compare performance with vinum's RAID5?:)
Feel free. But do it with more than a single process accessing the
Note: I discard all HTML mail unseen.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040819/35d8dd0f/attachment.bin
More information about the cvs-src