new server motherboard with SATA II

[Jeremy Chadwick]

On Fri, Jun 27, 2008 at 05:17:56PM +1000, Danny Carroll wrote:
>> There's a chance you'll see it on brand new SATA300 disks with all sorts
>> of different SATA controller hardware (not limited to just one vendor),
>> too.  The problem is somewhere within FreeBSD, and my Wiki page
>> documents a workaround/patch that the FreeNAS guys came up with, which
>> has sat ignored for over a year by the FreeBSD ATA maintainer.  Not a
>> good sign.
>
> Did it make it into 7-Current?

7-CURRENT existed back in mid to late 2007; there is no 7-CURRENT now.

And no, none of the patches provided by the FreeNAS people ever made it
into the FreeBSD source tree.  In fact, sos@ never even responded to
their mails.  This is the 5th or 6th time I've heard of this situation
happening (ATA driver author not responding to people who submit
patches, submit PRs, or general Email).  It's growing very old.

>> IRQ sharing is generally a "thing of the past", and interrupt conflicts
>> are something from days prior to APICs being available on every
>> motherboard under the sun.  Meaning: "swapping around" IRQs for onboard
>> devices rarely does anything in this day and age.
>>
>>> I'm thinking of getting a couple of Promise SATA-300 TX4 IO cards   
>>> (non-raid).  Perhaps that will offload the CPU.
>>
>> I don't see how that's going to help with heavy interrupt usage.  30%
>> interrupt usage across 5 disks doesn't sound too odd, and going with a
>> Promise controller that doesn't have its own dedicated driver (read: it
>> will use ata(4)) won't address that.
>
> 30%....  Even at idle?   Granted it did not increase much with heavy IO  
> but it surprised me a little that it's so high to start with.

No, it should not happen at idle.  You said "interrupt usage across 5
disks", which I read to mean "interrupt usage is very high during I/O
across a zpool consisting of 5 disks".  I misunderstood.

IRQ sharing could result in what you see, but it sounds more like some
weird interrupt routing/bug that might be specific to that Asus board.

> So which controllers have their own driver/processors onboard that can  
> eliminate the CPU hogging.

The FreeBSD Handbook has a list of hardware.  Anything that has its own
xxx(4) driver (e.g. twa(4), twe(4), arcmsr(4), etc.) will suffice.  Many
of these cards handle SATA disks which appear as daX in FreeBSD, since
they act as SCSI controllers.  SCSI CAM on FreeBSD is quite reliable.

Currently, the best SATA controllers I've seen that have native FreeBSD
support (meaning the vendor supports FreeBSD) are Areca controllers.  I
have no experience with them due to their cost, but they are *very*
fast.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |