Tom Lane <tgl@sss.pgh.pa.us> writes:
> Yes, you can probably assume that blocks with far-apart numbers are
> going to require a big seek, and you might even be right in supposing
> that a block with an intermediate number should be read on the way.
> But you have no hope at all of making the right decisions at a more
> local level --- say, reading various sectors within the same cylinder
> in an optimal fashion. You don't know where the track boundaries are,
> so you can't schedule in a way that minimizes rotational latency.
> You're best off to throw all the requests at the drive together and
> let the drive sort it out.
Consider for example three reads, one at the beginning of the disk, one at the
very end, and one in the middle. If the three are performed in the logical
order (assuming the head starts at the beginning), then the drive has to seek,
say, 4ms to get to the middle and 4ms to get to the end.
But if the middle block requires a full rotation to reach it from when the
head arrives that adds another 8ms of rotational delay (assuming a 7200RPM
drive).
Whereas the drive could have seeked over to the last block, then seeked back
in 8ms and gotten there just in time to perform the read for free.
I'm not entirely convinced this explains all of the SCSI drives' superior
performance though. The above is about a worst-case scenario. should really
only have a small effect, and it's not like the drive firmware can really
schedule things perfectly either.
I think most of the difference is that the drive manufacturers just don't
package their high end drives with ATA interfaces. So there are no 10k RPM ATA
drives and no 15k RPM ATA drives. I think WD is making fast SATA drives but
most of the manufacturers aren't even doing that.
--
greg