Messages in this thread |  | | | Date | Mon, 22 Mar 1999 11:15:45 +0100 | | From | Vojtech Pavlik <> | | Subject | Re: [OFFTOPIC] Re: disk head scheduling |
| |
On Sun, Mar 21, 1999 at 11:15:30PM -0500, Richard B. Johnson wrote:
> 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.
Current drives have separate read and write portions on the head. You can only read with a magnetoresistive head ...
> 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.
Yes, this was during the OMTI (ST-xxx, I don't recall the number), interface days, when drives used to do MFM, and the better RLL ...
But even those, as soon as the controller cards got more RAM than 512 bytes (16 kilobytes were needed, for one track of 17 (MFM) or 26 (RLL) sectors), all were formatted to 1:1 interleave, because anything else was only slowing them down.
Interleaving died fairly soon, and as far as I know was never needed since that time.
> 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.
Geez, I don't think you got the numbers right. If a harddrive had a gigabit per linear centimeter, it'd have 3 GB (gigabytes) on just the outer track ... which isn't the reality.
Should you be saying something like 0.1 Mbit/cm, I'd believe that.
> 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.
I did. Quantum says for their current fastest IDE drive: Maximum internal data rate: 241 Mb/sec. That's megabit per second. And, that makes it 30 MB per second, which the drive will easily transfer to the host over it's UDMA66 interface.
> 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.
I can't agree with you here. Should the data be too fast for the interface, interleaving OF COURSE would help, since for 2:1 you'd read the whole track in two revolutions instead of one, effectively halving the data rate that the interface needs to transfer to the host.
> 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.
It's more likely a necessity. Any other interleave would slow the drive down, which isn't at all what manufacturers wish. They could just let it spin slower ...
> 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.
All disks can do full track buffering now. And, if you think that cylinders are somewhere in the range of hundreds, then I guess you're off by a couple orders of magnitude. A track can easily fit into the 512 KB buffer on your usual IDE drive.
> Because of this, rotational latency now means nothing either. > This is another buzzword gone obsolete.
Hmm, then why all manufacturers state it? "Average Rotational Latency: 5.56 ms"
> Some IDE drives provide "read ahead".
All of the recent ones.
Have fun, Vojtech
- 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/
|  |