Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: Re: Mac Cache
Message-ID: <107@apple.UUCP>
Date: Wed, 30-Jul-86 21:32:15 EDT
Article-I.D.: apple.107
Posted: Wed Jul 30 21:32:15 1986
Date-Received: Thu, 31-Jul-86 21:20:07 EDT
References: <932@hounx.UUCP> <842@wang.UUCP> <2017@calmasd.CALMA.UUCP> <2787@sdcc6.ucsd.EDU> <104@apple.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Development Group, Apple Computer
Lines: 72

I think I have the definitive statement about caching.  The next batch of
Tech Notes (which are currently being reproduced and will be available
shortly) includes a Tech Note on caching.  Here is a summary of that
information.

There are several caches on the Macintosh.  

The first type has always been present.  Under MFS, each volume has a 1
block buffer for all file/volume data.  (The volume allocation map gets
saved in the system heap, but that's not really caching.)

With HFS, the cache is bigger: each volume gets 1 block of caching for the
volume bitmap, 2 blocks for volume/file data, and 16 blocks for HFS B-Tree
control buffering.

The cache lives in the system heap (except if HFS is using the type 3 cache
below). 


The type 2 cache is only present with the enhanced Sony driver (found in
the 128K ROM and in the RAM-based HFS).  This caches the current track and
IS write-though.  Successive reads from the same track will come from the
cache.  This caching only takes place for synchronous I/O calls.

This cache also gets space from the system heap.


The type 3 cache is only available under the 128K ROMs.  This is the cache
controlled by the Control Panel, and it is NOT write-through.

Based on how much space the user allocates in the Control Panel, the File
System will set up a cache that can accommodate a certain number of blocks.
This storage is allocated by moving the BufPtr, which reduces the size of
the application heap.  

The bulk of the caching code is loaded above BufPtr at application launch
time.  This is accomplished by the INIT 35 resource which is installed in
the system heap and initialized at boot time.  At application launch time,
INIT 35 checks the amount of cache allocated via the Control Panel and
moves BufPtr down accordingly, before bringing in the balance of the
caching code.  The caching code is in the resource CACH 1 in the System
file.

Up to 36 separate files are buffered by the cache, each of which has a list
of cached blocks.  Each cached block has aging information and blocks are
flushed using an LRU algorithm.

When the cache is enabled by the user, all files that are read or written
by HFS are subject to caching.  The cache is not write-through like the
track cache.  Blocks are buffered in the cache until the block is released,
the volume is flushed, or the application terminates.  (Note that ejecting
a diskette flushes the volume.)

It is important to note that Inside Macintosh already says to call FlushVol
after you close a file to prevent loss of data (page II-86), so this is not
something new.  The main disadvantage to turning on the cache is that your
application heap size is reduced.  Turning on the cache WILL speed up your
system noticeably.

I hope this clears up a few things.  I have purposely omitted some of the
details; the full version of the Tech Note (#81) should be distributed in a
couple of weeks.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET