On Mon, 30 Aug 1999, Mike Black wrote:
> But this is doing disk "reads" not "writes". It shouldn't need to read from
> both disks.
It does read balancing. That gives the best performance for an optimized
configuration (in this case that would mean the two disks split across two
IDE busses).
> Read performance will usually scale close to to N*P, while write performance
> is the same as on one device, or perhaps even less. Reads can be done in
> parallel, but when writing, the CPU must transfer N times as much data to
> the disks as it usually would (remember, N identical copies of all data must
> be sent to the disks).
This is in the abstract, and probably assumes an optimized configuration.
> I should expect at least the same performance (when disks are on the same
> bus) -- that's why I'm confused. I would actually expect better performance
> given that the limit is the disk i/o speed and not the data bus. If disks
> were on seperate buses I would expect better performance.
I don't know much about IDE, but I don't think it will do well when getting
pounded with requests for both disks (due to read balancing). It doesn't
have a capability analogous to SCSI's command tag queueing to make a shared
disk I/O bus practical. My understanding of IDE is that each command must
completely finish before another can be begun.
Add in some overhead for using both devices, and I'm really not surprised
it's slower than the single disk.
-Andy
