lkml.org 
[lkml]   [1999]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [OFFTOPIC] Re: disk head scheduling
    On Sun, 21 Mar 1999 yodaiken@chelm.cs.nmt.edu wrote:

    > On Sun, Mar 21, 1999 at 12:16:40PM -0800, Matthew Jacob wrote:
    > > Then there was "Enriching the File System-Storage System Interface"
    > > work-in-progress (Drew Roselli, Jeanna Neefe Matthews, Tom Anderson
    > > (drew@cs.berkeley.edu) which talked about informing the storage subsystem
    > > with info hints as for file block lifetime, etc... I think this might have
    > > been what you were thinking of?
    >
    >
    > I think this is what Jim must have had in mind. Tell the disk drive which
    > blocks are related, which blocks are unlikely to be written, ... so that the
    > drive can optimize geometry. If I'm not mistaken, sct said that ext3 will
    > support this kind of thing.
    >

    There have been some responses from those who declare that I
    have been talking about "old technology", some who declare
    as usual that I don't know what I'm talking about, and some
    that agree.

    Nevertheless, I will present some ideas which I hope will make
    a few persons think, rather than just reject this information.

    The technology to which I referred that interleaves sectors is
    indeed old technology. It is old simply because it has been
    moved from the external world into the internals of the Disk
    drives. The elementary physics of Disc drives has not changed
    since IBM Engineers first developed the 3030 which, because
    of its part number, became known as the Winchester drive.

    I am sure that I will get some flames from some who will claim
    that the part number was 3006 and the thirty-ought-six will
    out-shoot a thirty-thirty any day. Sorry, I beat you to it.

    Basically you move a head over some magnetic media and write
    data in a circular track. When you want that data back, you
    switch the head into a read amplifier and read it.

    These data are written and read as a serial stream of NRZ data.
    NRZ is used so there is no overall magnetic bias and it is self-
    clocking. This serial bit-stream is generated and recovered by
    a device known as a serializer.

    Heads have changed over the years, media has changed, and support
    mechanisms including electronics and I/O devices have changed.
    However, the basic stuff works according to the original principles.

    In the "olden" days, you could optimize the throughput by altering
    the sector interleave during a formatting operation. By matching
    the rate at which data could be written or read with the rate
    at which you could send or receive these data from the external
    world, you could optimize the I/O performance of the disk drive.

    In recent years, the emphasis has been upon increasing the storage
    capacity of these Disc drives. The storage capacity, which used
    to be specified in terms of kilobits per square inch, called
    areal density, is now specified in terms of gigabits per linear
    centimeter.

    This means that read amplifiers that used to handle data at up
    to 10 MHz are now handling data at 800 Mhz to 1 GHz. You can
    check the numbers yourself. The bits per second that travel under
    the read head is now much greater than the bits per second that
    any I/O interface can handle. This means that sector interleave,
    spiral compensation, and other tricks are now worthless because
    nothing you do along these lines will allow you to actually use
    data as fast as it becomes available. The data just arrives too
    fast. Because of this, sectors are no longer interleaved.

    Marketing persons, seizing buzzwords, cite this as an advantage
    and quote 1:1 interleave as though it were a benefit. Instead it
    is simply a side-effect.

    Expensive disk drives now do full track buffering. This costs
    money because RAM costs money. To buffer one full track on a
    Disc drive requires CAPACITY / (HEADS * CYLINDERS) which can
    be upwards of 100 megabytes of high-speed SRAM. Sector buffering
    is always necessary. It is part of the de-serializer and is
    required because the Disc internals are never synchronous with
    the outside world.

    Full track buffering suffers from the possibility that the next
    read or write will be on a different head. If the buffer was
    dirtied by a write, it is flushed to the physical media before
    any other operation can take place. To save time, the whole
    track is written. This saves time because you can start the
    write anywhere. However, it still takes 1 revolution of the
    platter.

    Because of this, rotational latency now means nothing either.
    This is another buzzword gone obsolete.

    Full track buffering and other expensive disk optimization techniques
    are usually done in SCSI Disks. However, some enhanced IDE drives
    now provide these features, but not the "Saturday night specials".

    The "smarts" are generally provided by an ASIC which is a large
    programmable gate-array which can be just as smart as a CPU
    and 200 or more times faster. However, it is "application-
    specific", not something to which you'd port Linux.

    Some IDE drives provide "read ahead". In plain language
    this means that the sector buffer is larger than one sector so,
    if enabled, the sector buffer will be filled on a read. There
    is a non-zero probability that the data you need next will
    be in the sector buffer so it is possible to improve performance
    by using this feature if you read continuous sectors.

    In summary, the internals of Disc drives necessary to provide high
    capacity, make it impossible for the outside world to enhance the
    drive's performance. As Linus has said; "It's just a linear group
    of blocks...".

    There are a few things that can be done though.

    (1) Queue reads and writes separately. If the drive is given
    a group of blocks to write, it can optimize head-travel and
    even servo settling times to improve throughput. It is not
    useful to sort writes because, what may seem adjacent to you
    may, in fact, not be accessible on the same track or head on
    the physical drive.

    Write queueing is the least expensive in software because you
    know when a buffer has gotten dirty. Just wait until quite a
    few are dirty and write a bunch all at once. How many? Don't
    know.

    Read queueing generally wastes time because the application really
    needs the new data now. However, finishing a concurrent write
    before doing the read, may improve performance marginally.

    (2) Use separate queues for each physical drive. SCSI Discs can
    disconnect while they do their thing. This allows other SCSI
    activity to occur. If the next read or write in the queue is
    for the drive that disconnected, you wait. You have no choice.
    However, if you have separate queues, you get to read or write
    to another device during this time.

    This may improve swap performance for those who have set up a
    separate swap drive.

    In conclusion, all this bandwidth will be wasted in a year or
    two anyway. Disk drives currently under test use static RAM.
    This is not the Slow........ NVRAM where you write then read-read-
    read-read, etc., until it finally "takes". This is real static
    RAM with a 3-volt battery to keep it alive for 20 years. These
    drives use standard interfaces so you can just put them in your
    PC and be done with it. Initially they will be expensive, about
    4-1/2 times the cost of an electromechanical equivalent. They
    will be marketed as high-speed improvements for file-servers and
    the like. As the market develops, the cost will come down.
    Storage Tek, IBM, and, Fujitsu are testing these things now.
    Probably Seagate and others are also, but they are keeping quiet.

    The speed of these drives will be solely dependent upon the
    bandwidth of the I/O interface so I wouldn't spend much time
    working upon elevators.


    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/

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