Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!uwvax!puff!rt4.cs.wisc.edu!blochowi
From: blochowi@rt4.cs.wisc.edu (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: Directory trashed by GS/OS.  HELP!!!
Message-ID: <3837@puff.cs.wisc.edu>
Date: 22 Nov 89 20:26:03 GMT
References: <8911202203.AA06213@apple.com> <3955@crdgw1.crd.ge.com> <36691@apple.Apple.COM>
Sender: news@puff.cs.wisc.edu
Reply-To: blochowi@rt4.cs.wisc.edu (Jason Blochowiak)
Organization: U of Wisconsin CS Dept
Lines: 50

In article <36691@apple.Apple.COM> mattd@Apple.COM (Matt Deatherage) writes:
>In article <3955@crdgw1.crd.ge.com> rankins@zaire.crd.ge.com (raymond r rankins) writes:
>> [About his thrashed directory & Cat.Doctor]
>>I think I'll get rid of the
>>ram cache (800k) I have set in GSOS because I've heard that a disk can
>>get trashed if the system fails and a disk update is in progress in the
>>ram cache.  
>ACK!  ACK!  ACK!
>It is true that if the disk cache is corrupted while a session is in progress,
>things could get in serious trouble.  However, unless you have a misbehaving
>DA or INIT, this isn't too likely.

	Does GS/OS now verify the cache's integrity? Perhaps it'd be too
expensive to do all the time, but how about a "paranoia" bit in the system
preferences word (or is it a longword? whatever...) for those of us that
write programs that occasionally write to various parts of memory by
accident?

	Also, why is it that only a session could cause trouble? If a block is
cached, and then nuked by some entity residing in the machine, and then GS/OS
requests the block, sees that it's in memory, uses the data (and only changes
a little bit of it), and then writes the block back, then the file contents
(or the directory contents - assuming the damage wasn't so bad that GS/OS
barfed on the contents) would be toasted. Besides, DAs and Inits are the only
programs to make mistakes, so it would seem that an application could toast
the cache.

>However, 800K is *way too much* memory to be spending on a disk cache.  Under
>normal circumstances, directory blocks are all that's in the cache anyway
>(it's not wise to blindly cache everything you read, see GS/OS Technical Note
>#3 for more details).  GS/OS is smart enough not to allocate 800K, only as 
>needed, but a 32K or 64K maximum cache size should keep most systems flowing
>smoothly.

	I guess I haven't looked at #3 recently... However, seeing as I
generally have >512k unused, I figure I might as well have the OS using it for
caching stuff, especially as I tend to cycle through (some large) programs
fairly quickly. Having them fly in from cache would seem to be faster than
getting them from this horrendously slow 28ms HD I have ;)

> [Deleted stuff about GS/OS using the integrity checks available in the
>  ProDOS file system, whereas P8 doesn't. Also deleted mention of ProSel 16]
>>Ray Rankins          |  (518) 387-7340  | INTERNET: rankins@zaire.crd.ge.com
>Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome
>ThisNet: mattd@apple.com              | subsidiaries, in whole or in part,


--
      Jason Blochowiak - blochowi@garfield.cs.wisc.edu or jason@madnix.uucp
       "Education, like neurosis, begins at home." - Milton R. Sapirstein