> > I assume the problem is getting io requests to occur simultaneously. My
> > surfing tells me most controllers provides poor same-channel access,
> > yet independent channels. So three controllers, one disk per channel
> > would provide concurrent io's, if the linux eide driver makes use of
> > them.
> >
>
> I'd say your a touch crazy, but just a touch. It isn't a "most controllers"
> controllers issue, it is a fundamental IDE issue. You'd really need to keep
> one device per channel if you want high throughput under heavy activity. Also
> IDE is also very CPU intensive, so this could consume quite a bit of the cores
> time (but better controllers can mitigate this a little). [...]
Check out:
http://beowulf.gsfc.nasa.gov/bds/disks.html
especially the bit at the bottom of the page which shows almost perfect
scaling across three IDE disks/channels. Using cheap IDE drives in DMA
mode completely avoids the CPU overhead penalty associated with the old
PIO-mode divers. I'm currently using two $250 11GB Maxtor 7,200 RPM
diamondmax drives on the two motherboard IDE channels of an Intel
PR440FX motherboard based system with 256MB RAM and a 300MHz PII.
Bonnie shows:
-------Sequential Output-------- ---Sequential Input--
--Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
1024 4868 98.5 23951 25.1 9062 27.3 4319 94.6 20137 23.9
80.1 1.6
Not too shabby. Compare this to the price/performance of a single 18GB
SCSI disk.
I believe the bottom line is that SCSI - particularly LVD/Ulra2 SCSI -
is clearly superior for applications which need tons of disk: SCSI
allows the disks to be conveniently stored in external enclosures, and
lets you put four or five disks on a channel without sacrificing
performance. For situations requiring fewer disks and for folks who
just can't afford SCSI, IDE RAID is a perfectly valid solution.
- C
