RAID-3? (was: cvs commit: src MAINTAINERS)

[Greg 'groggy' Lehey]

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.

Greg
--
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
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20040819/35d8dd0f/attachment.bin