Messages in this thread | | | Date | Sun, 21 Mar 1999 23:15:30 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: [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/
| |