On Jun 2, 2009, at 9:53 PM, Christopher Chan <christopher.chan at bradbury.edu.hk > wrote: > John R Pierce wrote: >> Chan Chung Hang Christopher wrote: >> >>>> I've read a lot of different reports that suggest at this point >>>> in time, >>>> kernel software raid is in most cases better than controller raid. >>>> >>>> >>>> >>> Let me define 'most cases' for you. Linux software raid can perform >>> better or the same if you are using raid0/raid1/raid1+0 arrays. If >>> you >>> are using raid5/6 arrays, the most disks are involved, the better >>> hardware raid (those with sufficient processing power and cache - >>> a long >>> time ago software raid 5 beat the pants of hardware raid cards >>> based on >>> Intel i960 chips) will perform. >>> >>> >> >> not if you're doing committed random writes such as a transactional >> database server... this is where a 'true' hardware raid controller >> with >> significant battery backed write cache will blow the doors off your >> software raid. >> >> >> > > > See my reply to nate. If you are using boards with 12GB of cache, > software raid is not even on the radar. True, but I feel an important point is being missed here. In a multi-user environment whether it be file or database the data will NOT be contiguous long after the initial build, so all I/O will go random. That's why defragging will always be important except for say COW based file systems which are random by nature, then it's their transactional log, like databases, that makes 'em or breaks 'em. In order to avoid a lot of the random I/O file systems use page cache to combine I/O operations and transaction logs to log it sequentially before committing it in the background later but the ability of the disks to handle a large amount of random I/O is also a big factor as if the commits can't execute fast enough the log will not empty enough to make it perform, so then you need an ever bigger log. -Ross