Re: H/W RAID 5 on slower disks versus no raid on faster HDDs

On Wed, Nov 27, 2002 at 01:16:35PM -0500, Merlin Moncure wrote:
> I agree 100%: hardware raid sucks.

I've been mostly ignoring this thread, but I'm going to jump in at
this point.

> We confirmed the performance results with heavy testing.  There is virtually
> no disadvatage to software raid, just spend 10$ and get a 10% faster cpu.

Define heavy testing.

I can do sequential selects on a low end PC with one client and have it
perform as well as an E10K. I could also fire up 600 clients doing
seemingly random queries and updates and reduce the same low end PC to
a smoldering pile of rubble.

It'd be easy to fudge the results of the "heavy testing" to match what I
wanted to believe.

> The linux software raid drivers (and others I assume) are very optimized.

As are the Solaris drivers, and many others. But there is more to a
RAID array than drivers. There's the stability of the controller
chipsets and the latency involved in getting data to and from the
devices.

Would you feel comfortable if you knew the state data for the aircraft
you're travelling on was stored on IDE software RAID?

Part of the point of hardware raid is that it does do a small set
of operations, and therefore far easier to specify and validate the
correct operation of the software and hardware.

> p.s. scsi is a huge waste of money and is no faster than IDE.  IMHO, scsi's
> only advantage is longer cables.  Both interfaces will soon be obsolete with
> the coming serial ATA.

Don't get me wrong, I'm a huge fan of IDE RAID in the right locations,
but comments like this reflect a total lack of understanding what
makes SCSI a better protocol over IDE.

Disconnected operation is one _HUGE_ benefit of SCSI, simply being the
ability for the CPU and controller to send a command, and then both head
off to do another task while waiting for data to be returned from the
device. Most (that is most, not all) IDE controllers are incapable of
this. Another is command reordering (which I believe SATA does have),
being the reordering of requests to better utilise each head sweep.

This feature comes into play far more obviously when you have many
clients performing operations across a large dataset where the
elements have no immediate relationship to each other.

It is amplified when your database of such a size, and used in a way
that you have multiple controllers with multiple spools.

SCSI is not about speed to and from the device, although this does end
up being a side effect of the design. It's about latency, and removal of
contention from the shared bus.

Ultra/320 devices in reality are no faster than Ultra/160 devices.
What is faster, is that you can now have 4 devices instead of 2 on the
same bus, with lower request latency and no reduction in
throughput performance.

SCSI also allows some more advanced features too. Remote storage
over fibre, iSCSI, shared spools just to name a few.

> High rpm disks are very expensive and add latent heat to your system.

If you have a real justification for SCSI in your database server, you
probably do have both the cooling and the budget to accomodate it.

> Western digitial's IDE disks outperform even top end scsi disks at a
> fraction of a cost.

Complete and utter rubbish. That's like saying your 1.1 litre small
city commuter hatch can outperform a 600hp Mack truck.

Yes, in the general case it's quite probable. Once you start
shuffling real loads IDE will grind the machine to a halt. Real
database iron does not use normal IDE.

> You can install a 4 drive 10 raid setup for the cost of a single 15k
> rpm scsi disk that will absolutely blow it away in terms of performance

See above. Raw disk speed does not equal performance. Database spool
performance is a combination of a large number of factors, one being
seek time, and another being bus contention.

> (reliability too).

Now you're smoking crack. Having run some rather large server farms
for some very large companies, I can tell you with both anecdotal, and
recorded historical evidence that the failure rate for IDE was at
least double, if not four times that of the SCSI hardware.

And the IDE hardware was under much lower loads than the SCSI
hardware.

> Just remember, don't add more than one IDE disk on a raid system to a single
> IDE channel!  Also, do not attempt to buy IDE cables longer than 18"..they
> will not be reliable.

So now you're pointing out that you share PCI bus interrupts over a large
number of devices, introducing another layer of contention and that
you'll have to cable your 20 spool machine with 20 cables each no longer
than 45cm. Throw in some very high transaction rates, and a large
data set that won't fit in your many GB of ram.

I believe the game show sound effect would be similar to "Bzzzt".

IDE for the general case is acceptable. SCSI is for everything else.

--
David Jericho
Senior Systems Administrator, Bytecomm Pty Ltd


--
Scanned and found clear of viruses by ENTIREScan.  http://www.entirescan.com/