IBM serveraid and linux

[Tim Writer]

lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org (Lennart Sorensen) writes:

> On Wed, Jan 05, 2005 at 01:53:01PM -0500, Dave Stubbs wrote:
> 
> > The general rule of thumb with RAID is that hardware RAID is *always* 
> > faster than software RAID.

Why?  Certain (perhaps many) optimizations aren't available to the RAID
controller because it doesn't have the full picture.

> > The IBM ServeRAID has it's own CPU for 
> > pity's sake - just for processing RAID parity calculations and managing 
> > the cache.  It would make no sense for software RAID to be able to keep 
> > up with this. 

I disagree.  Modern systems are usually I/O constrained meaning there are
plenty of available CPU cycles to handle the simple parity calculations.  To
put it another way, if the CPU is idle while waiting for I/O, why not use
that time to do the parity calculations?  You give up a few (spare) CPU
cycles in return for retaining a more complete picture of the block I/O which
allows the kernel to make better scheduling decisions, gaining better overall
I/O throughput.

> > Now, I must admit that in my *Linux* experience I have had the same 
> > results as you - software RAID has been way faster than hardware.  But 
> > that is only under Linux.  I have seen under BSD, UNIX, and Windows that 
> > Hardware RAID is generally faster.  That would tend to indicate to me 
> > one of two things -
> > 
> >    1.  The Linux Software RAID guys have come up with some super cool
> >    whiz-bang way of making software RAID work really well, and no one
> >    else has figured it out, even though the RAID subsystem is open
> >    source (unlikely)...   or...
> >    2. The Linux drivers for the IBM ServeRAID adapter are crap (much
> >    more likely). 

3. The block I/O subsystems of other systems suck so bad they make ServerRAID
look good.

I'm not saying this is the case, just throwing it out as another possibility.
Years ago, I ran some benchmarks to compare I/O performance of Linux (ext2)
running on a 486/33 with 16MB RAM and a single (narrow) SCSI-II disk against
Solaris 2.4 running a 167Mhz UltraSPARC with 128MB RAM and a single wide
SCSI-II disk.  Linux blew Slowaris away!  I don't know if that Sun system
would have benefited from hardware RAID but it sure needed something.

> > It wasn't too long ago that the ServeRAID driver was still marked 
> > "Experimental" in the kernel.  And the fact that there seems to be only 
> > one driver in Linux that is supposed to support all ServeRAID adapters 
> > from the ServeRAID 1 up to the 6 or whatever they're up to now, while 
> > there are individual specialized drivers for each variation of each 
> > model of  the ServeRAID for every other operating system supported - 
> > would tend to indicate that some kind of generalization or short-cutting 
> > is going on.
> > 
> > Bottom line:  I would not be comfortable generalizing about RAID 
> > performance based on Linux experience with the IBM ServeRAID.
> 
> One would think if the drivers were the problem IBM would have a serious
> interest in fixing that problem.

And last time I checked, they wrote (or at least sponsored the development
of) the ServerRAID drivers.  Also, poor drivers don't explain the reliability
problems I've experienced with ServerRAID which have been backed up by others
on this list as well as an IBM service technician (in confidence, of course).
Apparently, these problems aren't unique to Linux.

Yes, this is annecdotal and no, I haven't done an extensive study.  But I've
generally had good experiences with software RAID and poor experiences with
hardware RAID.  In my opinion, hardware RAID doesn't live up to its promises.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml