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

On Sun, 28 Jan 2001, Timothy A. Seufert wrote:

> At 11:57 AM -0800 1/27/01, David A. Gatwood wrote:
>
> >With modern hard drives, there is no way to really know
> >the track numbers associated with block numbers. You can assume that
> >closely numbered sectors are near others, but increasing block numbers
> >could move the arm from the inside of the disk to the outside (nad
> >possibly vice-versa) several times.
>
> Why would this ever happen? Think about it a little more before you
> assume it's a possibility worth worrying about. Such behavior would
> destroy streaming read/write throughput for large files.

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. The point is that there's no way for the OS to really
know that information, even with Winchester drive designs.


> General purpose file systems designed for hard disks *all* know in
> their bones that laying out a large file with monotonically
> increasing block numbers, and few (if any) discontinuities, is the
> One True Path to high streaming throughput.

You can generally assume that contiguous block numbers are set up in such
a way that reading them in order is the most efficient way to get the
data. That is the _only_ assumption you can make about geometry, though.

For a good example, there's the problem of devices that don't even
resemble a Winchester disk, but look like one to the OS. Examples:
compact flash, probe-based storage, hardware RAID.... Large reads are
still more efficient, contiguous blocks are more efficient, but for
different reasons. An elevator algorithm would simply be wasted overhead
for compact flash, and could dramatically hurt performance in probe-based
storage, I suspect.

For people who don't know, probe-based storage involves heads that read
and write data by moving towards and away from a moving rectangular medium
that moves in two dimensions. It doesn't remotely resemble a winchester
drive, but when it becomes commercially available, it will probably look
like one as far as the OS is concerned. Performance optimizations are
completely different, however.


> I hope that we have now plumbed the depths of thinking about hardware
> devices from too abstract a POV... (in other words, one shouldn't
> assume that because something *could* happen that it *will*; it's
> important to think about what's actually likely to happen...)

What's likely to happen is nothing. I would expect the difference to be
only a fraction of a percent one way or the other for most normal hard
drives. This assumes that you keep the drive's queue mostly full. If you
feed it only one request at a time, my gut feeling says your performance
will tank. :-)

The suggestion for doing this for dumber optical drives makes a lot of
sense. And if I'm right, that the performance is only a fraction of a
percent either way, then it might be reasonable to put it in there for all
devices just to make the drive probe easier. If we start t see a big hit
on certain types of drives, it's easier to prune out a few than it is to
include a much larger number.

However, as we start to see more and more drives that aren't based on the
Winchester mechanism, the more optimization we put in now, the more we'll
have to take out later. Expect probe-based storage within just a few
years. Compact flash and hadware RAID are out there now. Assuming that
everything that looks like a disk really is a disk is simply no longer a
valid assumption.


David

---------------------------------------------------------------------
Check out my weekly web comic:
http://www.techmagazine.org

References: 
 >Re: I/O Optimization (From: "Timothy A. Seufert" <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.