> On Fri, Mar 19, 1999 at 10:41:31AM -0800, David Lang wrote:
> > > Well of course a 2-way elevator should sort by *ascending* sector within
> > > descending track. I take it this is difficult?
> > >
> > > --
> >
> > Many (most? all new?) IDE drives lie to you about the real
> > heads/sectors of the drive so you do not have the ability to do this
> > accuratly.
> >
>
> Yeah, but some manufacturers are good enough to put it in the tech notes.
> Should the scheduling algo be put in as a device strategy function, with
> fallback to the current elevator if the device doesnt have one? Then we could
> implement two way elevator algos for those hard disks for which we can get
> physical geometry info from the data sheets or somewhere.
>
The typical IDE drive has a single platter and two heads. Just
like a floppy disk. The so-called geometry is specified only
for compatibility with the real-mode BIOS (0x13) interface that
expects heads/sectors/cylinders, like in the old ST-506 interface
days.
Any attempt to optimize performance based upon this phony geometry will
fail. The best you can do is attempt to keep read/write queues separate.
In other words, if possible, queue a bunch of reads and do them all
together, then queue a bunch of writes and queue them all together. This
can cut down some time on the write-splice and other so-called rotational
latencies.
A write splice occurs when you need to write some new sectors between
existing sectors, i.e., you are not going to write an entire track. This
often requires that the disc make up to one complete rotation before a
write can begin because the drive has to "learn" where the starting sector
is by reading sectors. Note, all sectors on hard disks are "soft" which
means that there is no index to tell the electronics when to turn on the
write current. If writes get queued together, and you have multiple
writes, there is a chance some writes will occur on the same track. This
means that since the drive already knows where the sectors are on that
track, it doesn't have to reread.
There is practically zero probability that optimization based upon phony
geometry will accomplish anything because the real geometry boundaries are
usually well hidden by the drive's sector buffer. All you do is waste
CPU cycles that could be used elsewhere. What happens is you slightly
slow the overall operation of the entire machine without increasing the
Disc performance at all. Wasted CPU cycles are never gotten back, you
burned them up, making a beautiful I/O queue, then accomplish nothing
for your effort.
With SCSI drives, the physical geometry is also hidden. However since SCSI
drives usually cost more, the expense of better buffering is usually
justified. Therefore the drives themselves become very "smart". Usually an
internal CPU optimizes reads and writes if you let it. You let it by using
a controller which provides tagged queuing, synchronous operation, and
disconnect.
If the OS/Driver combination keeps the queues full, performance will be
optimized for a particular drive.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.3 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/