[ILUG] Highpoint Sata RAID
Rick Moen
rick at linuxmafia.com
Wed Mar 23 20:00:45 GMT 2005
Quoting Paul Jakma (paul at clubi.ie):
> - The Promise TX4 is *not* the same card as the Promise SX4[1].
/me checks online.
SATA150 SX4 appears to have the _same_ design limitation as the TX4: It
has a chip devoted to XOR calculations only. Striping, error-handling,
etc., are offloaded. (In a further display of cheapness, I notice that
they also use a Marvell 88i8030-TBC PATA/SATA converter chip on each
channel, like a lot of the other first-generation jobs.)
This is not necessarily a bad thing: It makes the cards a lot cheaper
than, say, 3Ware's and Areca's. But the system load problem is real.
> - If you're using Linux MD, as you should be, (be it with a promise
> TX4 or SX4 or Highpoint or whatever) then you're
> obviously not using proprietary on-disk RAID formats..
Which, you will note, is my recommendation for those determined to save
a few extra Euros. (Addendum: People looking over _new_-generation
SATA-II cards might want to look at the Tekrams: They closely imitate
the extremely good but high-priced Areca cards using the same chipsets
and basic designs.)
> - On-disk RAID superblock format is *not* the cause of performance
> problems with soft-raid.
And of course I _didn't say it did_.
> - The primary reason soft-raid can be slower is because it requires
> extra bus bandwidth - instead of writing a block once and letting
> the controller write a copy to each disk you have to send each
> block across the bus for each disk (for RAID-1). For RAID-5 the XOR
> doesnt cost much on a modern CPU (which are *vastly* superior in
> speed and RAM bandwidth to the CPUs and RAM used on "embedded
> computer on a PCI card" RAID controllers), however it is an extra
> block of data to pass across the bus.
That is correct, with exception noted below.
> Ie, extra bus bandwidth of software RAID is the primary bottleneck
> of soft RAID
Except during restriping, when the calculation overhead becomes
absolutely brutal, and the system is often effectively nonfunctional.
More information about the ILUG
mailing list