Re: SCSI protocol efficiency vs. IDE protocol efficiency:

A good point. I'll add another one. One has to think beyond the protocol design and also think about protocol implementation.

Even with SCSI drives, not all drives are the same. Some do a better job of implementing the SCSI protocol than others.

In a prior life, the workstation I/O folks were qualifying low and mid-cost SCSI drives to ship with the workstations instead of the ~$1000 high-end SCSI drives we were putting in our servers.

They found that the lower-cost drives couldn't keep up with the higher-cost drives when you tried things like striping a bunch of the drives together on a bus. When you're pushing SCSI hard, all it takes is something simple like the drive not releasing the bus quickly enough and your performance starts to degrade. (And then there are mechanical issues, too, like how well the enclosures damp vibrations so that the drives don't interfere with each other when seeking.)

And I don't even want to talk about data corruption under heavy and demanding workloads.

Disk drives are no different from any other commodity product. You get what you pay for. The question is whether or not the extra cost is worth the extra benefit.

I use el-cheapo EIDE drives on my PC at home. I'm comfortable with that because I know the I/O workload against the drive is going to pretty minimal so the drive should be just fine.

If I wanted to do high-performance I/O and I cared about my data, I'd be using expensive server-class disk drives. I would also eat the extra cost if I could afford it and buy qualified drives directly from my system vendor as opposed to from a 3rd-party (either that or make really certain that my drives were running the same firmware revision as the system vendor's drives. Firmware revisions do matter.).

Ray Chen rcc@netapp.com

The real issue with SCSI vs IDE is bus utilization.

The SCSI protocols were designed such that the bus could be freed for other users, in-between the time the request for data was sent to the drive, and the time data was returned. Thus commands for data could be sent to several drives, before the time the first drive could reply with the requested data.

The IDE protocols were designed for simplicity, it results in the bus being allocated to one request, for the duration of a single request. It wastes time for simplicity.

Due to the sporatic disk access behavior of workstations, IDE and SCSI drive perform similarly.

However, do to the much more consistant but varied disk access of file servers, the SCSI bus out-performs the IDE bus due to its time efficiency. The only mechanism to combat the IDE bus efficiency would be to have one IDE bus for each drive. Having one IDE bus per drive, would eliminates the minor cost advantage that IDE drives have over SCSI drives.

Note: Another issue that has not been mentioned, is system uptime. I have not seen an IDE drive that has been adapted to support hotplugging. This is critical for online maintenance.

-- Matthew Lee Stier * Fujitsu Network Communications Unix Systems Administrator | Two Blue Hill Plaza Ph: 914-731-2097 Fx: 914-731-2011 | Sixth Floor Matthew.Stier@fnc.fujitsu.com * Pearl River, NY 10965