On Sat, 2009-02-21 at 08:40 +0800, Chan Chung Hang Christopher wrote: > Ian Forde wrote: > > I'd have to say no on the processing power for RAID 5. Moore's law has > > grown CPU capabilities over the last 15 or so years. HW RAID > > controllers haven't gotten that much faster because they haven't needed > > to. It's faster to do it in software, though it's preferable to offload > > it to HW RAID so that any apps aren't affected directly. > > > You will have to prove that. I have previously posted posts with links > to benchmarks that show that hardware raid with sufficient processing > power beat the pants of software raid when it comes to raid5/6 > implementations. Hardware raid cards no longer come with crappy i960 cpus.
Just by doing some quick googling, I came across: http://blogs.zdnet.com/storage/?p=126 http://storagemojo.com/2007/04/24/mo-better-zfs-performance-stats/ http://milek.blogspot.com/2007/04/hw-raid-vs-zfs-software-raid-part-iii.html Now, bear in mind that I'm no ZFS fanboy, but I'm saying that it's not so cut and dry anymore. The equation changes, of course, when we're talking about a purposed fileserver versus an application server that needs RAID. (The app server can suffer because its losing access to CPU resources.) But the point of contention is still there. Both are viable solutions, when considering that SW RAID was never a serious contender for performance over the years, look at where it is now. This tells me that it's trending up towards equaling or bettering HW RAID performance. And that's not talking about price points. When throwing that in... But again - I still like HW RAID. I think we're in agreement on this. > > I would agree on that cache memory is an advantage, especially when > > considering battery-backed cache memory. > There is more to it. That cache memory also cuts down on bus traffic but > the real kicker is that there is no bus contention between the board's > cpu and disk data whereas software raid needs to read of the disks for > its calculations and therefore suffers latencies that hardware raid > boards (which have direct connections to disks) do not. Of course, if > the cache size is insufficient, then the hardware raid board will not > perform much better if not worse than software raid. Indeed. > > But those aren't the only significant areas. HW RAID allows for > > hot-swap and pain-free (meaning zero commands needed) disk replacement. > > > > Hmm...really? I guess it depends on the board. (okay, okay, thinking of > antique 3ware 750x series may not be fair) I was thinking about when I was running a farm of 500 HP DL-x80 series boxes and disk replacement became a 9x5 job that we farmed out. Just give a list of servers and locations (first drive or second drive) and the person could pull old drives out, put new drives in, and resync was automatic. Same thing is true for Dell PERC hardware. I note that that's not necessarily true with ALL HW RAID controllers, as they have to support hot-swap, and the chassis has to have hot-swap slots. But still, I've only seen one SW RAID implementation that does auto-sync. That's the Infrant ReadyNAS (http://www.readynas.com). I wonder how they did it? Might not be a bad idea to see how they're able to use mdadm to detect and autosync drives. I don't *ever* want to go through something like: http://kev.coolcavemen.com/2008/07/heroic-journey-to-raid-5-data-recovery/ Not when a little planning can help me skip it... ;) -I _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
