[CentOS] Harware vs Kernel RAID (was Re: External SATA enclosures: SiI3124 and CentOS 5?)

[Ross Walker]

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