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    [from the cache]
©2003-2011 Jasper Spaans