dce@Solbourne.COM (David Elliott) (05/24/89)
Over the last few months, I've somehow gotten the impression that
there is something strange about the RAM cache, and that it's
best to keep it very small (32K) to avoid problems.
Is this impression incorrect?
What is the most generally useful value (either exact size or
RAM/cache ratio)?
--
David Elliott dce@Solbourne.COM
...!{boulder,nbires,sun}!stan!dcerubinoff@linc.cis.upenn.edu (Robert Rubinoff) (05/25/89)
I have also been having problems that I think are caused by the RAM cache. Does anyone know what it actually caches, and whether it's write-through? Several times I've had the machine crash and rebooted to discover that files I had saved weren't there any more. If this is because they're somehow being cached until some later time, this means that the RAM cache is very dangerous. It's nice to get the speedup the cache gives, but not at the risk of losing files (or corrupting the disk directory). Does anyone know if there is a safe size to set the cache that will prevent this? Robert
mec@mtfmi.att.com (M.CONNICK) (05/25/89)
In article <1260@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: > Over the last few months, I've somehow gotten the impression that > there is something strange about the RAM cache, and that it's > best to keep it very small (32K) to avoid problems. > > Is this impression incorrect? > > What is the most generally useful value (either exact size or > RAM/cache ratio)? I've been using a 192K disk cache on a 2 meg Mac running under MultiFinder for over a year without a single problem attributable to it. Prior to running MultiFinder I had it set to 1 meg, again without problem. The "optimal" size of the cache depends on what operating system environment you run and what kinds of applications you use. Determining the exact size that's right for you is pretty much a matter of trial and error experimentation. ----------------------------------------------------- Michael Connick att!mtfmi!mec 201-957-3057 AT&T Bell Labs MT 3F-113 (Dept. 79153)
mec@mtfmi.att.com (M.CONNICK) (05/25/89)
In article <11353@netnews.upenn.edu> rubinoff@linc.cis.upenn.edu (Robert Rubinoff) writes: > I have also been having problems that I think are caused by the RAM cache. > Does anyone know what it actually caches, and whether it's write-through? > > Several times I've had the machine crash and rebooted to discover that files > I had saved weren't there any more. If this is because they're somehow being > cached until some later time, this means that the RAM cache is very dangerous. > > It's nice to get the speedup the cache gives, but not at the risk of losing > files (or corrupting the disk directory). Does anyone know if there is a safe > size to set the cache that will prevent this? The Mac disk cache is not a write-through cache. But then, the UNIX system buffer cache isn't either! A bigger performance gain is obtained by not doing so. The Mac disk cache will flush file updates to disk immediately when the file is closed though. To me this is about the best compromise possible between performance and guaranteed file integrity. Even if you don't have the cache enabled, a crash before an updated file is closed will usually mean lost data, simply due to the normal buffering taking place in the Mac file system. The only way to make sure that a file is updated to disk on a record-by-record basis is to call FlushVol after every output. Of course, if you're crashing often enough for buffering/caching to be a real problem, then you really should be addressing what's causing all the crashes! ----------------------------------------------------- Michael Connick att!mtfmi!mec 201-957-3057 AT&T Bell Labs MT 3F-113 (Dept. 79153)
denbeste@bgsuvax.UUCP (William C. DenBesten) (05/25/89)
From article <11353@netnews.upenn.edu>, by rubinoff@linc.cis.upenn.edu (Robert Rubinoff): > I have also been having problems that I think are caused by the RAM cache. > Does anyone know what it actually caches, and whether it's write-through? > ... > It's nice to get the speedup the cache gives, but not at the risk of losing > files (or corrupting the disk directory). Does anyone know if there is a safe > size to set the cache that will prevent this? For the complete scoop on caching on the macintosh, check out Macintosh Technical note # 81. The control panel cache is not write-through. Apple recommends (in MTN 81) that programmers call FlushVol() after writing a file to the disk. I always harp on users not to use a paper clip indiscriminately and to always pull shutdown before they turn off their machine. I have empirically found that setting the cache at 32K is best. Using no cache is much slower, and I do not notice significant improvement with a larger cache. A smaller cache will also reduce the amount of stuff that you can have waiting to be written to disk, so it will reduce your chances of damage in a crash. -- William C. DenBesten denbeste@bgsu.edu denbesten@bgsuopie.bitnet
englandr@phoenix.Princeton.EDU (Scott Englander) (05/26/89)
A MacWeek of a few weeks ago showed a graph in which time to launch an
application was increasingly reduced up to a cache size of 96k, but then
levels off. So that's what i set mine at (with 2.5 meg ram).
--
- Scottsklein@cdp.UUCP (05/28/89)
Keep in mind that if you have a really big cache it may take longer to search the cache than it would have to just read the hard disk. This is especially true on the MacPlus and SE where the 68000 runs at only 8 Mhz
mec@mtfmi.att.com (M.CONNICK) (06/02/89)
In article <141200040@cdp> sklein@cdp.UUCP writes: > Keep in mind that if you have a really big cache it may take longer to > search the cache than it would have to just read the hard disk. This > is especially true on the MacPlus and SE where the 68000 runs at only > 8 Mhz Somehow I doubt that Apple is using a serial search to access disk blocks in the cache! I'm sure they are using some type of hashing scheme. ----------------------------------------------------- Michael Connick att!mtfmi!mec 201-957-3057 AT&T Bell Labs MT 3F-113 (Dept. 79153)
d88-jwa@nada.kth.se (Jon W{tte) (06/03/89)
In article <1147@mtfmi.att.com> mec@mtfmi.UUCP (79153-M.CONNICK) writes: >Somehow I doubt that Apple is using a serial search to access disk >blocks in the cache! I'm sure they are using some type of hashing >scheme. Picking the TechNotes of the shelf reveals: TechNote #81 page 2 of 3 line 36ff: Up to 36 separate files may be buffered by the cache. Each queue is a list of blocks cached for that file. Information is kept about the age of each block, and the blocks are also kept in a list in the order in which they occur in the file. It also says that the least recently used blocks are the ones to go when new blocks are read. It ALSO states that INIT 35 handles the cache, through loading the caching CODE into the cache buffer in the application heap, so you could write your own, hashing, code for this, I suppose. But Apple Computer Inc (TM) stick to their sequential lists, also used in the Resource Manager, List Manager, Dialog Manager, Text Edit ... (Sorry about all the tech talk in this group) -- __ Jon W{tte (The dread Smiley Shark) email:h+@nada.kth.se / \ (+46 (0) 8 258 268) /--- (c) 1989 Yessbox Allright Professional Products Inc. - Y.A.P.P.I. / -- No More --