On Tue, 12 Oct 1999, Christopher E. Brown wrote:
> -------Sequential Output-------- ---Sequential Input-- --Random--
> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
> fenris 1024 15716 96.7 45169 70.2 17574 45.8 18524 71.5 47481 38.5 509.5 13.2
>
>
> System is a dual Xeon 500/1mb w/ 512MB main memory. It has 3
> SCSI busses, one UltraWide (DLT tape), and 2 Ultra2 LVD units (one
> used, one for expansion). There are 7 seagate 18.2G cheeta drives
> installed, the last 6 are a 0 spare RAID5 array running left-symmetric
> parity and a chunk of 128. The filesystem was created as follows.
That's no surprise. I already knew Linux software RAID5 can perform
extremely well given enough CPU horsepower. The question was, if I want
hardware RAID5, can I have the benefits[1] it provides and not have crappy
i/o performance.
[1]
reliable data storage without having to worry about kernel versions /
raid driver versions and patches
automatic rebuilds using hot spares without having to roll my own scripts
to do so
ability to boot from a RAID5 (though AFAIK, lilo can boot from software
mirrored partitions now, no?)
Not being forced to go SMP just to give software RAID a CPU to play
on...what if we find our system isn't SMP stable? That may not be
likely, especially with 2.2.x or 2.4.x, but it was still a serious issue
with 2.0.x.
----------------------------------------------------------------------
Jon Lewis *[EMAIL PROTECTED]*| Spammers will be winnuked or
System Administrator | nestea'd...whatever it takes
Atlantic Net | to get the job done.
_________http://www.lewis.org/~jlewis/pgp for PGP public key__________
