[lkml]   [1998]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: elevator algorithm bug in ll_rw_blk.c
    On Mon, Nov 16, 1998 at 09:42:47AM +0100, Helge Hafting wrote:

    > This would be trivial if the real disk geometry was simple, without
    > variations in the number of sectors per cylinder. It isn't so though.
    > Manufacturers can sometimes fit more sectors on the outer cylinders,
    > this gives faster transfers and more data in those areas. Figuring
    > out the real geometry with timing tests is not simple in this case, there may
    > be lots of different sector counts and you have no idea where they change.
    > You would need to do timing tests on every physical cylinder (not
    > knowing where they start in the first place) and build a big table.
    > Not something we want during bootup. And timing could go wrong
    > if anything else happen with the machine in the meantime.

    You don't even know how the mapping logical to physical block works exactly
    in some cases. IBM has some series of drives that do faster track-to-track
    steps than switching between heads on the same cylinder. As a result
    transfer rate benchmarks on various sector ranges result in a sawtooth graph.

    Advanced wierdness: Imagine one of those hardware RAID systems which look
    to the host like a single block device and equipped with various types of
    disk drives.

    You don't want to optimize your OS for such stuff. Berkeley's FFS filesystem
    used such optimizations long time ago but today they don't make sense anymore.
    Elevator sorting is ok since that's stuff which is beyond what the typical
    drive can do for us, so it needs help.

    The one way elevator is clearly a trade off and it's a sensible one for the
    average Linux system. For stuff like RAM disks or intelligent hostadapters
    with currently upto half a gig of RAM on it the elevator is just a waste of
    effort, the hostadapter is supposed to offload this part of processing from
    the host. Since the filesystems we care about scatter data more or less
    equally over the entire blockdevice as a way to reduce fragmentation I guess
    a two way elevator might be a better tradeoff for disks of software RAID arrays.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.021 / U:21.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site