Re: Dumb question: Which is "better" SCSI or IDE disks?

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Fri, 4 Dec 1998 13:17:27 +0100 (CET)


On Thu, 3 Dec 1998, Russell Leighton wrote:

> What are good rules of "thumb" for
> choosing IDE vs SCSI when building
> a Linux system?

When there are not too many processes accessing the disk at
the same time, IDE is cheaper and thus to be preferred.

> Both are fast these days...I always
> thought that IDE==cheap, but loaded
> the CPU, so you didn't want that in
> a server or high performance machine

IDE and SCSI both load the CPU about as much. The difference
is that SCSI is a lot smarter and allows multiple outstanding
commands to a device and multiple devices being busy at the
same time. This means that you can get a lot more work done
with a SCSI subsystem than with an IDE one.

If, for instance, you have 2 IDE drives on the same channel
and you are waiting for drive 1 to read a sector, you cannot
tell drive 2 to get off of it's lazy butt and fetch you some
data.

With SCSI all drives can seek for data at the same time, the
only time they block eachother is with the actual data
transfer, which comes out of a buffer anyway so that contention
is minimal.

Command reordering is another nice feature of SCSI drives, but
since Linux does something like that in software too it's not
that much of an issue anymore. IDE write caching has narrowed
that gap even more.

Scatter-gather _is_ a good argument for SCSI (IMHO of course)
since that allows you to give a command with lots of arguments
to a drive and the drive can continue processing the commands
(seeking) even while it is returning other data or accepting
new commands. Very nice for /home or /var...

MP3 or movie streaming can just as well be done from IDE drives
since you want to do large readaheads anyway and IDE is much
cheaper and has the same transfer speed and reliability.

I am using 2 SCSI and 2 IDE drives myself. The IDE drives do
mainly long, non time-critical data transfers and the SCSI
drives do lots of small transfers.

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/