lkml.org 
[lkml]   [1998]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: elevator algorithm bug in ll_rw_blk.c
Date
From
And lo, Simon Kenyon saith unto me:
>
> On Sun, Nov 15, 1998 at 06:30:25PM +0100, Martin Mares wrote:
> > Track-to-track seek speeds are not directional, but inter-sector
> > speeds are and since the algorithm has no information on physical
> > disk geometry, it cannot distinguish whether two sectors are on
> > the same track or not.
>
> well perhaps it should
> all this crap to deal with logical block number has lost all the optimization that
> is possible by taking into account physical distances on the disk.

The cylinder/head/sector numbers have been lies for years. With a SCSI
disk you could read the true geometries, including sectors per track in
each of the various zones, together with the defect map and know exactly
where each block lies on the disk...but the angular position of the disc
is a whopping 11 ms variable (5400 RPM), and you can't optimize for it
in the OS without guessing at it, then hoping you aren't interrupted
too badly before acting on that guess.

Leave the nitty gritty to the disk (for SCSI, or for IDE writes); just
get the requests in rough order without starving anyone and things
should go quickly and smoothly. Worst case, you plan to request a track's
blocks in reverse order, but the dumb IDE disk has nothing better to do but
to read the track into its buffer when it finishes seeking, so within a rev
the data for a whole batch of pessimal requests is in the buffer.


> i think it was rsx-11 which used to format the disk to take into account
> retational delays
I've seen DOS floppy formatting programs that do that. Meanwhile, since
hard disk makers have been bragging about sustained transfer rate for the
past several years, I can guarantee they've skewed the tracks properly to
optimize sequential reads across track boundaries...and not even a SCSI
drive will tell you the value of this skew, AFAIK...


> of course the other side of the coin is that all this sorting increases the
> potential for problems when metadata on the disk becomes inconsistent. i know
> disks are pretty reliable these days, but the os has been know to crash now and
> then :-)
There's going to be power interruptions at inconvenient times no matter what
you do.

Keith


--
"The avalanche has already started; |Linux: http://www.linuxhq.com |"Zooty,
it is too late for the pebbles to |KDE: http://www.kde.org | zoot
vote." Kosh, "Believers", Babylon 5 |Keith: kwrohrer@enteract.com | zoot!"
www.midwinter.com/lurk/lurker.html |http://www.enteract.com/~kwrohrer | --Rebo
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans