Shared Memory

[John Macdonald]

On Tue, Feb 01, 2005 at 10:33:36AM -0500, Lennart Sorensen wrote:
> > Readahead too has been a standard feature of Unixoid systems for decades.
> 
> I suspect most drives also implement some read ahead caching using their
> onboard cache.  I haven't read any actual specs on how the cache on
> hardisks is actually managed.  Not even sure the drive makers publish
> that information.

I believe that the most common form of read-ahead done by
drives is simply to read an entire track into cache even when
the original request was for a smaller amount.  Then, if the
"next" portion is requested shortly thereafter, the track is
still be in the cache and the data can be returned immediately.
There may be some drives that get fancier perhaps, but this
simple approach, combined with a good readahead policy from the
operating system works pretty well.  (The OS knows better than
the disk drive where the "next" sector of a file is located.
The track read works well for nicely clustered file allocations,
the OS readahead is needed to keep the disk "on track" when
the file jumps to a different series of sequential sectors.
That puts a limit on how clever the drive can be about
readahead. The one aspect that it can try to be clever is to
notice when the cached track has been successfully used and at
that point prefetch the subsequent track in hopes that this
will continue the sequential operation.  However, this could
actually slow the disk down - if it is always busy prefetching a
track "on spec" when the OS requests data that it really needs,
the apparent response time will be worse.  That's why you need
the OS to do most of the clever pre-fetch scheduling - it can
know when the next sector on the disk has nothing to do with
the file that is being read and thus when *not* to pre-fetch.)

-- 
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml