[Discuss] SW vs HW raid (was raid controller drivers)

Edward Ned Harvey (blu) blu at nedharvey.com
Fri Sep 26 06:50:48 EDT 2014


> From: jabr at gapps.blu.org [mailto:jabr at gapps.blu.org] On Behalf Of John
> Abreau
> 
> I like to stick with software raid. The argument that convinced me was that
> with hardware raid, the controller can fail, and would have to be replaced
> with an identical controller, which might no longer be available on the market
> by the time your controller fails. Whereas with software raid, the controller is
> just a generic disk controller, and if it fails, it can be replaced by any other
> generic disk controller of the same type (ide, scsi, sata, or whatever).
> 
> If there are performance requirements for which software raid is too slow,
> then sure, you may need to go with hardware raid. But when software raid
> will suffice, I feel it's the more reliable choice.

There are pros and cons to both.  John, you seem to think hardware raid is faster than software raid, and sometimes that's true, but not always.  For example, there are lots of HW raid controllers with on-board write buffers, that can greatly improve performance of things like EXTfs.

But my favorite counterexample is ZFS.  The way ZFS performs best is when you have a direct attached bunch of plain dumb disks and no smart HBA.  If your workload is suitable, you can disable the ZIL for maximum performance, but otherwise, use a dedicated log device (SSD typically).  The reason ZFS outperforms hardware acceleration is because ZFS has intimate knowledge of the filesystem layer.  When something in userland says "Overwrite block #7432 of this file," ZFS remaps all those blocks to big contiguous region on disk.  Unlike most filesystems, where "Overwrite some block" must translate to actually overwriting that block

There are some disadvantages (as discussed) with software raid, particularly, making it usable by the bootloader.  And sometimes other restrictions, like...  In windows software raid, you can't split the raid and expect some random NTFS utility to be able to read it.  (Server fails, so you attach the disk to another system to extract files out of it, and discover you can't, because the dynamic volume is broken or something, but you *could* have booted that disk, if the server hadn't failed.)  


More information about the Discuss mailing list