RAID-3?

[Scott Long]

Greg 'groggy' Lehey wrote:
> 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:
> 
>   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