Looking for RAID Drivers

[Mark Haney]

Brian McKee wrote:
> On Mon, Sep 22, 2008 at 4:40 PM, Mark Haney <mhaney at ercbroadband.org> wrote:
>> Elizabeth Bevilacqua wrote:
>>> On Fri, Sep 19, 2008 at 10:08 PM, John Hubbard <ender8282 at yahoo.com> wrote:
>>>> Linux implements its own software raid.  True hardware
>>>> raid is pretty expensive and not very common.  Unless you spent a good
>>>> chunk of cash on your board, I would guess it is actually software raid.
> 
>>> And lest you get concerned about spending money on this card and not
>>> being able to use it for RAID - benchmarks have shown that Linux
>>> software RAID is faster than most of the RAID cards you can buy. So
>>> you'll still be making out fine (or better!) by using the controller
>>> as simply an SATA controller and then using Linux software RAID.
> 
>> I'd REALLY like to see those benchmarks.  Because I simply don't believe
>> it.  Sure, the linux dm-raid is damn good, but nothing beats having a
>> controller do the 'package and assembly' work for you off-CPU.  In a
>> resource intensive setup S/W RAID can't cut it, except for maybe (and I
>> emphasize MAYBE with Reads).
> 
> Mark - I hate to argue with you when I can't present benchmarks - but
> the processor on most systems today is so fast, and idle so often,
> that the dedicated controller really has to be good (read more
> expensive) to keep up to software RAID backed by a modern CPU.  From
> what I've seen, unless you start needing really serious performance
> (read way in excess of what any home or small business server will
> ever require) or your server is seriously overloaded, software RAID
> keeps up just fine.  Heck, people are running entire extra operating
> systems via virtualization because the CPU can run more than one
> without appreciably affecting required performance.   And at the other
> end of the scale we're talking SAN technology or whatever, where
> software RAID is really a moot point.

Yes, virtualization is possible with almost any modern CPU.  I use it 
all the time.  However, if you dig a little deeper into things, you'll 
find the disk controller CPU is designed to do one thing and one thing 
only, build RAID blocks, either for writing or for reading. Your point 
is valid, but let's just say I don't like having all of /those/ eggs in 
one basket.

Not to mention have you ever really tried to rebuild a S/W array?  Sure 
the system might be up, but it's virtually useless until the array is 
rebuilt.  With a hardware based system that isn't the case.

> 
>> When you can offload the work to a dedicated controller you free up the
>> CPU for other processes.  The kernel doesn't know or care about the RAID
>> functions at that point and can concentrate on what it does best.  Not
>> to mention, as per my previous post, that the S/W RAID setup is still
>> not as stable as I would like.  And, even on RAID 5 the likelihood you
>> lose data is increased with S/W RAID if a drive fails.
> 
> Now that's where I have to say Huh?   Why would software RAID be more
> likely to cause failure than hardware RAID?

Why would it be more likely? It's software.  It's buggy.  It's not 
always stable.  An unstable part of the system can affect the RAID 
subsystem.  To me, this sounds like you haven't been bitten by a failed 
S/W array.  (Or any array at all) If so, that's great.  But we just went 
through having to have a DR company recover 250GB of data from a NAS 
device with Linux S/W RAID.  It was RAID5, a drive failed and the system 
decided a GOOD drive was degraded and overwrote it with the failed 
drives data.

You also have to consider the boot consequences of S/W RAID.  It 
requires (sometimes) rebuilding initrd to handle the booting properly. 
Again, /not/ something I want to spend my time either fixing, or hoping 
it doesn't happen.

> Raid level 1, 5, 10 whatever doesn't come into play here - compare
> apples to apples because software RAID supports different levels, just
> like hardware RAID does.  I have never seen proof that software RAID
> is less stable at the same level.  Got something to back that up?

See above.  I have a couple more examples if you want them.

> Especially when we're talking about the half-baked untested RAID they
> 'throw in' with a consumer level motherboard? 

Uh, anyone buying from a vendor /anything/ that they think is half-baked 
is half-baked themselves.  I never said to take /any/ RAID system you 
find.  Stick with what you know.  I rather think that comment was 
off-topic, but okay.

   Tell me a quality
> battery backed unit is more reliable, and I *might* buy it - but
> that's not what we're talking about here.

Yeah, that last statement made no sense to me.

> 
> My beef with hardware RAID is if the controller goes, you're hosed
> without a matching controller.  And unless you buy a spare when you
> buy the original, you can end up in a real pickle.  It's why I don't
> like the Drobo - your data is inaccessible unless you have a backup
> Drobo.

Yes, that is true.  I never said there wasn't a downside to H/W RAID.  I 
just wanted to debunk some of the things listed in a reply to the OP. 
Yes, your data is unavailable unless you have backup hardware.  But if 
your MB goes with S/W RAID, what then?  Have you ever tried to rebuild 
S/W on another spare system?  It can be done, but it ain't always 
pretty.  Or reliable.

  I have a DROBO, actually.  It works great.  But then, I don't worry 
too much about the data on it.  It's MP3s I have backed up on spare 
drives.  So far it works great.
> 
> As I type this I get the feeling we've had this discussion before :-)
>  I'll quiet down now.
> 
> Brian
> 

I certainly get your points, and they are all valid.  The discussion I 
think spilled over into areas that the OP didn't plan on discussing. 
All I wanted to do was share my experiences with S/W RAID and offer my 
advice on the pros and cons.

I've seen arrays of both types self destruct before, and I can say 
(personally) that I'd trust a H/W RAID setup than S/W any day if the 
data is critical whether consumer or business.



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support