Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I/O Optimization

At 1:11 PM -0800 1/28/01, David A. Gatwood wrote:

No, not really. If you're doing a long read of nearly contiguous data,
number the tracks from 0 to 31 on platter A, 63 to 32 on platter B, 64 to
95 on platter C... or similar. That's a perfectly reasonable ordering if
the drive has multiple platters. An increasing read steps the heads
towards the inside of the disk on platter A, then steps back out to the
outside on B, etc.

This is not reasonable; it hurts performance. It's significantly faster to select a different head within a cylinder (vertical group of tracks) than it is to do a track-to-track seek. Going in and out as you describe requires a relatively expensive seek for every track. The scheme which is actually in use in all drives is to instead go down (or up, doesn't matter which) through the tracks in a cylinder, then in.

You can see this in the legacy IDE addressing scheme, which is called "CHS" because block addresses are (Cylinder, Head, Sector) triplets. Tracks are not addressed individually.

There has been justifiable grumbling about the lack of facts in this discussion, so here are some for contemplation: The IBM UltraStar 9LP (a 7200 RPM SCSI drive) requires a minimum of 2.13ms to switch cylinders and a minimum of 0.83ms to switch heads within a cylinder (ref: pg 40 of the Ultrastar 18XP/9LP Hardware/Functional Specification). The 9LP has 10 heads (5 platters), and a revolution of the disk takes 8.333ms. So:

Min. time per 10 tracks for in-out scheme (streaming transfer):
10 * (8.333ms + 2.13ms) = 104.63ms

Min. time per 10 tracks for up-down CHS scheme (streaming transfer):
10 * 8.333ms + 9 * 0.83ms + 2.13ms = 92.93ms

Given this, it should be clear why I am so confident that you can in fact depend on large block number deltas resulting in longer seeks than small deltas. The only sensible low level organization is CHS, and it will stay this way until there is a fundamental change in Winchester disk technology.

The point is that there's no way for the OS to really
know that information, even with Winchester drive designs.

My point is that it's pointless to worry about there being no way to know. The practical reality is that all rotating magnetic disk drives on the market do in fact work the way I've described. Every single one of them. And there is no reason to expect this to change within the next few years.

The other objections seem to boil down to "even now not everything is a hard disk". Fine, don't do optimization in those cases. And don't sweat it when it is highly unlikely to make a difference one way or another (i.e. flash). And don't invent boogeymen where there are none (RAID preserves the "seek time proportional to block # delta" characteristic, obvious if you think about how RAID works). And don't worry about blue sky possibilities like probe storage until they're out; just do a reasonably clean design and it will be easy to adapt to new technology when it's real.

Tim Seufert

References: 
 >Re: I/O Optimization (From: "David A. Gatwood" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.