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    [W:0.022 / U:0.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site