[OT] Useable BIOS RAID 1 on the cheap?
djk at tobit.co.uk
Tue Jan 17 21:12:22 GMT 2006
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 hda1
> 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
5. But you need to benchmark carefully and theory is rarely borne out in
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.
More information about the london.pm