*BSD News Article 81227


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.netspace.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!imci5!news.internetMCI.com!newsfeed.internetmci.com!howland.erols.net!EU.net!Austria.EU.net!siemens.at!pc5829.hil.siemens.at!not-for-mail
From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: RAID sw?
Date: 20 Oct 1996 12:25:24 GMT
Organization: Siemens AG Austria
Lines: 55
Message-ID: <54d5nk$3ou@zwei.siemens.at>
References: <chad-3009960810030001@sverige.pengar.com> <325018D3.1131EC4C@lambert.org>
NNTP-Posting-Host: firix.siemens.at
X-Newsreader: TIN [UNIX 1.3 unoff BETA release 961006]

[wading through a bunch of unread articles:]

Terry Lambert <terry@lambert.org> wrote:

: RAID calculation in software is extremely expensive, especially
: for the hamming codes.  [...]

why?

RAID 3 Theory of Operation [greatly simplified]:
================================================

  4 disks with real data
  1 dedicated disk with XOR-ed data.
  basic data unit: 'logical sector' of 4 ordinary sectors

a RAID 3 write operation:

  a transaction of:
     parallel write to the 4 disks
     and a write to the XOR-ed sector. [the XOR has to be recalculated]

a RAID 3 read operation:

  parallel read from all 4 disks

compared to RAID-0 [5 striped disks] benchmarks:

20% more bus bandwith used for writing, 20% more disk space, 20% lower 
read-bandwith, a bit higher read-latency [less than 20% :)], and a 
cross-XOR per write operation. 

If you worry about the XOR ... well, it is an overhead, but really 
nothing to worry about IMHO. It's a per-write thing, doable from
the "i'm ready to write" interrupt.

:              [...] It is so expensive that no one has really
: bothered to implement code to do it.

Such RAID boxes are usually a dedicated 486 board with a better
SCSI adapter [possibly mirrored], using tagged queueing, ensuring
hot plugging, etc. IMHO, no magic there, really.

there is a RAID5 implementation for Linux btw. [and not speed but
stability is the reason why it's still alpha :)]

: For what it's worth, I believe you'd be pretty unhappy with a
: software raid soloution in any case -- the performance would
: *have* to be pretty terrible.

i'm really curious why you think it *has* to be terrible. Reliability
is achieved through a simple XOR, nothing more is needed.

-- mingo