AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/12/89)
>Date: Fri, 10 Feb 89 21:07:39 GMT >From: Doug McIntyre <marque!lakesys!dougm@CSD1.MILW.WISC.EDU> >Subject: [GS/OS cache] >Will Apple someday let us to turn of[f] caching a disk completely off? I hope not! It'd be about as slow as ProDOS 16 then. >This would be mainly for development. I read someplace that [GS/OS] >caches the most recent directory access info, and the cache NDA, only >controls the block caching done by [GS/OS]. Correct: directory blocks and bitmap blocks are the stuff you typically find in the cache these days. (Other stuff can get cached, but the program has to ask for it.) The Cache NDA provides you a method of adjusting the cache size (and 0 is actually 16K). Removing the Cache NDA removes your method of adjusting the cache's size, but it doesn't remove the cache itself. (The NDA just updates the cache-size setting in battery-RAM and asks GS/OS to re-size the cache.) >I've just had a directory crash yet again on my hard drive, [...] >This happend from a program, trying to create a file to a directory >that didn't exist... Getting a tad sick of having my hard drive >directory structur being completely wiped out by most anything that >can go wrong with [GS/OS]... I assume you mean this happened from a program _that you are writing_. If so, I suggest the obvious: test your program with your hard drive turned off! You seem to imply that a GS/OS "CREATE" call caused your drive to be trashed just because a "path not found" error was returned. I have a very had time believing something like that, _although_ if your program is _ignoring_ errors and continuing to make other calls that assume the previous ones succeeded, I can easily see how your drive could get fried. For the cache to help a disk get fried, some program has to accidentally overwrite the cache memory. If your program (and all the DAs you're using, etc) only writes to memory that it has allocated through the memory manager, this won't happen. Note that I didn't say "If your program _intends_ to write only to memory it has allocated through the memory manager...." If you're allocating non-fixed memory blocks, you have to be sure to check their locations each time you use them if they have been unlocked during any operations that can allocate memory. If the program that helped trash your drive is not one you are developing yourself, I suggest you test it further on scratch disks & get in touch with its author. By the way--I _would_ like to see GS/OS do checksumming on its cached blocks. This would get you a nice fatal error when a program stomped over the cache, instead of getting you a trashed volume. I've suggested this to Apple & will keep bugging them about it until somebody admits it's a good idea. >UUCP: uunet!marque!lakesys!dougm Compuserve: 70611,2215 >INET: dougm@lakesys.lakesys.COM APLE: DougMac --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons