[OT] Useable BIOS RAID 1 on the cheap?

[Dirk Koopman]

On Tue, 2006-01-17 at 19:46 +0000, Chris Benson wrote:
> On Tue, Jan 17, 2006 at 04:37:48PM +0000, Dirk Koopman wrote:
> > 
> > A friend of mine is a disc speed freak and he is reporting bonnie++
> > throughputs of 110MB / sec read speeds (slightly less on write) on a
> > three disk software raid 0 setup (AMD 64 3500, 1GB RAM, 3 Seagate
> > Barracuda 300Mb SATA/150, NVidia chipset). 
> 
> Does this mean anything to anyone?

> Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> beta             2G 36079  94 59261  31 25349  13 24238  65 44377  15 354.4   1
>                     ------Sequential Create------ --------Random Create--------
>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP /sec %CP
>                  16 24771  99 +++++ +++ 20038  99 23481  99 +++++ +++ 17372  99

> beta:/opt/tmp# cat /proc/mdstat
> Personalities : [raid1]
> md0 : active raid1 hdc1[1] hda1[0]
>       156288256 blocks [2/2] [UU]
> 
> The disks are Seagate 160GBs:
> hda: ST3160023A, ATA DISK drive
> hdc: ST3160023A, ATA DISK drive
> hdd: HL-DT-STDVD-ROM GDR8161B, ATAPI CD/DVD-ROM drive
> 
> The machine is a dual
> model name      : AMD Athlon(tm) MP
> stepping        : 1
> cpu MHz         : 2000.474
> cache size      : 256 KB
> 
> with 1GB RAM ...
> 
> So is that good?  I don't really care because I ran on one disk for 6
> days last week when hdc failed with a loose power cable ...

That's about right for a modern setup, using ATA, but it looks like raid
1 (mirroring) rather than raid 0. This does not give you any speed up
over a raid 0 (striping) setup. But then I suspect you are more
interested in the data integrity :-)

Contrast the above with my less than ideal setup of single AMD Athlon 32
2800+ with 1Gb in a Shuttle with 2 slower, 60GB, discs and one in the
secondary slot but they are raid 0, not 1:-

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
dirk3.int.tobit. 2G 35579  93 72526  28 26441   8 34530  82 57350  10 236.0   0

Basically the theory stacks up something like this:-

1. The number of heads (usually 4) x the packing density of the disc x
rotation speed (typically 7200rpm) give the theoreticall, sustained
output of the disc. The bigger the disc, in the same form factor,
generally the bigger the throughput.

2. The max throughput of a disc, even modern ones, generally falls way
below the speed of the channel it is connected to. (I am writing in
terms of SCSI [and IDE controllers] here, but you can think of one SATA
= one wire on a controller with say 4 channels in the same terms). 

3. So doing some kind of striping (Raid 0,5,6) will gain you throughput
because you can, in effect, timeshare the discs on a channel /
controller / computer. This is so because each (sequential) write of a
block goes on the next disc in the set. Given sufficient processor speed
you will, more or less linearly, increase the total throughput of a raid
0 array by the amount available on each disc that you add. I should add
that theoretically raid 1 is slightly less than one disc's worth of
throughput but, given intelligent raid software, can be twice as fast on
read (but rarely is). 

4. Raid 5 and 6 complicate this by adding either one or two
(respectively) blocks of recovery information (usually called parity) to
a 'tranche' of writes. In effect you lose one disc (two for raid 6) of
the raid 0 array to parity (although these parity blocks are spread
throughout the actual array) and one  disc of throughput (two for 6) on
writing (because of the extra write(s)). Reading (usually and should)
roughly maintain the speed of the effective no of data discs in the
array. 

5. But you need to benchmark carefully and theory is rarely borne out in
practice.

Because now 35-50MB/sec sustained throughput for a single disc is now
common place; when you raid, you need enough buffer space to receive it
and a fast enough processor to shift it all where it is going. The more
timesharing that can be done (ie add pathways, eg controllers) the
greater the throughput. 

Perhaps it now becomes clearer why a 400Mhz i860 with 128MB RAM on a
33Mhz 32bit PCI card (max bandwidth 132MB/sec), sharing the PCI bus,
does not constitute a "fast" raid solution anymore.  

Dirk