Jeremy Chadwick wrote:
This comes as no surprise, as there is no ICH10 knowledge in the PCI and
ATA code at this time. ICH10 is ***very*** new, as in probably within
the past 6 weeks, no?
Yes.... It's a new desktop machine that I am toying with before it
needs to go to it's permanent owner.
You're greatly confused with regards to what "amd64" means. FreeBSD's
32-bit operating system is called i386. FreeBSD's 64-bit operating
system is called amd64. It has absolutely **nothing** to do with
processor types (AMD vs. Intel).
You can understand how that can happen I guess. But thanks for setting
me straight.
FreeBSD's ability to boot off of FreeBSD-managed-RAID'd volumes is
horrible. Administrators have to go through a bunch of rigmarole to
accomplish something that should be an absolute simplicity/necessity in
this day and age. This is one reason why I myself have considered using
Intel MatrixRAID, because then that "layer" is generally transparent to
FreeBSD.
In fact, ZFS on a root filesystem is still a "pain", yet Solaris has it
down pat.
I had that whole hassle with either vinum or gmirror (can't remember
which). That's why this time I decided on a dedicated disk. So long as
I have a backup I don't care about a days downtime for the OS.
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?
Keep in mind that there have been some reports of ZFS on FreeBSD
behaving incorrectly/oddly when a disk goes back, or a checksum error is
found by ZFS. The disk will resilver for no apparent reason.
Hmmmm....
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.
So which controllers have their own driver/processors onboard that can
eliminate the CPU hogging.
You might be better off getting actual server hardware rather than
"hacked up to be server" desktop hardware. Consider Supermicro stuff.
I can personally recommend their PDSMi+ motherboard, and many other
FreeBSD users rely heavily on their hardware.
Well I still have the option to choose something so I'm open to all
sorts of suggestions. And actually that's kinda the point to me
starting this post. To find out what hardware does great IO with Sata.
I was also looking at TYAN gear. I've used it in the past and been
happy (but performance was never really an issue then).
Thanks so much for the tips so far.
-D
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
