Skip site navigation (1) Skip section navigation (2)

Re: Hardware vs Software RAID

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: "Peter T(dot) Breuer" <ptb(at)inv(dot)it(dot)uc3m(dot)es>
Cc: Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware vs Software RAID
Date: 2008-06-25 15:24:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, 25 Jun 2008, Peter T. Breuer wrote:

> You can put the log/bitmap wherever you want in software raid, including 
> on a battery-backed local ram disk if you feel so inclined.  So there is 
> no intrinsic advantage to be gained there at all.

You are technically correct but this is irrelevant.  There are zero 
mainstream battery-backed local RAM disk setups appropriate for database 
use that don't cost substantially more than the upgrade cost to just 
getting a good hardware RAID controller with cache integrated and using 
regular disks.

What I often do is get a hardware RAID controller, just to accelerate disk 
writes, but configure it in JBOD mode and use Linux or other software RAID 
on that platform.

Advantages of using software RAID, in general and in some cases even with 
a hardware disk controller:

-Your CPU is inevitably faster than the one on the controller, so this can 
give better performance than having RAID calcuations done on the 
controller itself.

-If the RAID controllers dies, you can move everything to another machine 
and know that the RAID setup will transfer.  Usually hardware RAID 
controllers use a formatting process such that you can't read the array 
without such a controller, so you're stuck with having a replacement 
controller around if you're paranoid.  As long as I've got any hardware 
that can read the disks, I can get a software RAID back again.

-There is a transparency to having the disks directly attached to the OS 
you lose with most hardware RAID.  Often with hardware RAID you lose the 
ability to do things like monitor drive status and temperature without 
using a special utility to read SMART and similar data.


-Maintenance like disk replacement rebuilds will be using up your main CPU 
and its resources (like I/O bus bandwidth) that might be offloaded onto 
the hardware RAID controller.

-It's harder to setup a redundant boot volume with software RAID that 
works right with a typical PC BIOS.  If you use hardware RAID it tends to 
insulate you from the BIOS quirks.

-If a disk fails, I've found a full hardware RAID setup is less likely to 
result in an OS crash than a software RAID is.  The same transparency and 
visibility into what the individual disks are doing can be a problem when 
a disk goes crazy and starts spewing junk the OS has to listen to. 
Hardware controllers tend to do a better job planning for that sort of 
failure, and some of that is lost even by putting them into JBOD mode.

>> However, not all hardware RAID will have such a battery-backed-up cache,
>> and those that do tend to have a hefty price tag.
> Whereas software raid and a firewire-attached log device does not.

A firewire-attached log device is an extremely bad idea.  First off, 
you're at the mercy of the firewire bridge's write guarantees, which may 
or may not be sensible.  It's not hard to find reports of people whose 
disks were corrupted when the disk was accidentally disconnected, or of 
buggy drive controller firmware causing problems.  I stopped using 
Firewire years ago because it seems you need to do some serious QA to 
figure out which combinations are reliable and which aren't, and I don't 
use external disks enough to spend that kind of time with them.

Second, there's few if any Firewire setups where the host gets to read 
SMART error data from the disk.  This means that you can continue to use a 
flaky disk long past the point where a direct connected drive would have 
been kicked out of an array for being unreliable.  SMART doesn't detect 
100% of drive failures in advance, but you'd be silly to setup a database 
system where you don't get to take advantage of the ~50% it does catch 
before you lose any data.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to


pgsql-performance by date

Next:From: Jonah H. HarrisDate: 2008-06-25 15:30:14
Subject: Re: Hardware vs Software RAID
Previous:From: Greg SmithDate: 2008-06-25 13:56:50
Subject: Re: Hardware suggestions for high performance 8.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group