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

David,

The answer is always: It depends.

Of course can software RAID be faster than hardware
RAID. But then you are not comparing the best
offerings of each category. Software RAID is usually
cheaper than hardware. But again you may be able to
construct a product pairing where it is reverse.

However, my main point was to use RAID in a production
environment to protect against hardware failures.

raw versus file system is an old battle. raw is faster
because it does not have the filesystem overhead.
However, raw is a little harder to administer.
Question is how much faster raw is and if it is worth
the trouble. Numbers usually quoted are 10-20%. And
here things may be changing as operating systems and
chaching algorithems get better to mask the file system
overhead. As I mentioned the question is mute for
PostgeSQL because raw is currently not supported.

Regards,
Nikolaus Dilger

>From http://linas.org/linux/raid.html
If the RAID disk controller has a modern, high-speed
DSP/controller on board, and a sufficient amount of
cache memory, it can outperform software RAID,
especially on a heavily loaded system. However, using
and old controller on a modern, fast 2-way or 4-way SMP
machine may easily prove to be a performance
bottle-neck as compared to a pure software-RAID
solution. Some of the performance figures below provide
additional insight into this claim.

From
http://www.uni-mainz.de/~neuffer/scsi/what_is_raid.html
Hardware vs. Software RAID
Just like any other application, software-based arrays
occupy host system memory, consume CPU cycles and are
operating system dependent. By contending with other
applications that are running concurrently for host CPU
cycles and memory, software-based arrays degrade
overall server performance. Also, unlike hardware-based
arrays, the performance of a software-based array is
directly dependent on server CPU performance and load.

On Sun, 24 Nov 2002, David Gilbert wrote:

>
> >>>>> "Nikolaus" == Nikolaus Dilger
> <nikolaus(at)dilger(dot)cc> writes:
>
> Nikolaus> SCSI320 in theory is twice as fast as
> SCSI160. But the
> Nikolaus> bottleneck will be the throughput of the
> individual disks.
> Nikolaus> 15,000 rpm of course will be faster than
> 10,000 rpm. More
> Nikolaus> interesting then the rpm numbers itself are
> seek time and
> Nikolaus> transfer rate.
>
> More to the point, with current disks, SCSI160 needs 3
> to 4 disks to
> be saturated. Don't buy 320 unless you have more than
> 4 disks.
>
> Nikolaus> In a production environment I would always
> favor some kind
> Nikolaus> of error protection. Either RAID 5 or RAID 1
> (mirroring). A
> Nikolaus> hardware RAID controller is faster than
> software RAID.
>
> I'm on a bit of a mission to stamp out this
> misconception. In my
> testing, all but the most expensive hardware raid
> controllers are
> actually slower than FreeBSD's software RAID. I've
> done my tests with
> a variety of controllers with the same data load and
> the same disks.
>
> As with any test, I have a theory: that the 2Ghz+ main
> processors of
> modern machines so outstrip most raid controllers that
> it is faster to
> perform the RAID on the main processor. It is also
> lower latency
> ... and latency is what matters for advanced
> filesystems.
>
> Nikolaus> For pure speed raw devices would be faster
> then file
> Nikolaus> systems. However, PostgeSQL currently does
> not support
> Nikolaus> them.
>
> This used to be true on machines with less processor
> power than disk
> bandwidth. It is likely no longer true. To be more
> exact: yes,
> filesystems have overhead, but the overhead is
> processor overhead
> ... of which (compared to disk bandwidth) you have
> lots. OSs have
> also become more efficient.
>
> Dave.
>
> --
>
============================================================================
> |David Gilbert, Velocet Communications. | Two
> things can only be |
> |Mail: dgilbert(at)velocet(dot)net | equal
> if and only if they |
> |<a
href="http://mail.dilger.cc/jump/http://daveg.ca">http://daveg.ca</a> | are
> precisely opposite. |
>
=========================================================GLO================