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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
