[LAU] drive bays and hardware RAID

[Arnold Krille]

Hi,

On Wednesday 05 May 2010 10:39:32 Florian Faber wrote:
> > Don't do hardware-raid! Neither the real nor the "soft" hardware raid
> > help you that much. What do you do when the controller fails?
> Well, this is a stupid advice, unless you tell plutek also to get
> everything else in his studio twice.

Imagine how plutek runs to a friends computer (or just breaks out his second 
machine) when the first fails during the session?

And now imagine plutek checking ebay for days to hunt down the same hw-
controller as the one that just fried up...

Oh, most people have two or more audio-interfaces. And two or more headphones 
and speaker-pairs. And two or more guitars (if they are guitar-players).

But with the disks storing the results of the work, he should be careless???

> A hardware raid does all the computation for you and just passes along
> the data you need. It also eats away a lot of stress through huge
> buffers. With an Areca 1280 for example, I get 3GB/s for the first
> second and ~1.5GB/s sustained on a RAID6.
> 
> With software raid, you have to transfer all data twice through the
> system,

No, the only place where it feeds through twice is the part memory->disk-
controller (which is pretty fast thanks to dma). Before that its just one 
stream, after that its one dedicated bus per device (given this centuries 
sata/sas).

> you fuck up you caches,

If the linux kernel fucks up its caches when its doing its own raid, something 
is _horribly_ wrong. And I doubt it is.

> and the CPU has to do all the
> computations. If you only have two drives, it doesn't matter that much.

What computations? - Ah, you still don't know that any [345]-raid is bad...

> So it really depends on what you want to do and what your budget is. If
> you have to avoid IO stress, go and get a decent RAID controller.

If you want to avoid user-stress, do software-raid.

> > With a hardware-raid you have to have a second of the same kind in stock
> > to get back the data on your disks. Don't even think about not having a
> > spare controller and buying one when yours fails.
> This is only true if the on-disk format is not specified somewhere. If
> you buy cheap shit, that may be and you may have to fiddle around to
> extract the data. But it can be done.

Again, the question is probably not so much the "if" or "how" but the "how 
fast" and "how pricey".

> > The "reduced" throughput of a software-raid is worth the ease of use. And
> > its not that "reduced" at all.
> Again, it depends on the use case.
> > Oh, and use only raid1 or combinations of 0 and 1. For all the others see
> > http://baarf.com.
> Again, it depends on the use case. As a general rule, this is just wrong.

I know business you have lost raid5-systems (and all the data on it) because a 
second disk broke under the stress of reconstructing a first failed disk.

But be my guest, I (*) work in a company helping such firms after disaster. 
Note that we also write invoices for our work.

Have fun,

Arnold

(*) insert: almost
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20100505/a8a61b34/attachment-0001.pgp>