mlr@hounx.UUCP (M.ROBINS) (07/23/86)
There has been plenty of talk about setting the cache on the Mac +, but I haven't heard any mention of the proper way to turn off your Mac when the cache is enabled. I have had some file changes blown away when I powered down after using a program. Does anyone know the best way to write the cache to disk so that a safe power down is possible. Mike hounx!mlr
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (07/24/86)
> There has been plenty of talk about setting the cache on the Mac +, > but I haven't heard any mention of the proper way to turn off your > Mac when the cache is enabled. I have had some file changes blown > away when I powered down after using a program. > > Does anyone know the best way to write the cache to disk so that a > safe power down is possible. > The best way is to choose "Shut Down" from the Finder. This flushes and ejects every mounted volume. The other advantage to exiting via Shut Down (instead of, say, by hitting reset) is that the file system sets a flag on HFS disks to indicate that they're in a consistent state. This saves a lot of time when the volume is next mounted, as it does some automatic recovery on potentially inconsistent volumes. Programming note: it recently occurred to me that programs that do direct disk I/O (such as full-disk backup programs, or FEdit) could be tripped up by the cache. I asked MacTech how to flush the cache, and they replied that _FlushVol forced write-through from the cache to the indicated volume.
leeke@cascade.STANFORD.EDU (Steven D. Leeke) (07/25/86)
I believe that if you use the Shut Down command from the menu the system will flush the cache to disk and things should be fine for you to then turn off the mac. If you don't do this I believe that you may lose things. This is primarily for HD users. I would hope that for floppies the cache would be flushed when a disk is ejected. Of course, if it is flushed when an application returns to the finder/desktop this is all meaningless... In general, DO NOT just use CMD-SHIFT-1/2 to eject disks and turn the Mac off when you are still in an application, but you have saved & closed your document. Return to the desktop, Shut Down, and then turn the Mac off. Steve Leeke
cjn@calmasd.CALMA.UUCP (Cheryl Nemeth) (07/26/86)
In article <932@hounx.UUCP> mlr@hounx.UUCP (M.ROBINS) writes: >Does anyone know the best way to write the cache to disk so that a >safe power down is possible. It's probably a good idea to shut down before you power down. If you desperately feel the need to turn off the mac from inside an application, ejecting all the disks should work.
cjn@calmasd.CALMA.UUCP (Cheryl Nemeth) (07/27/86)
Does the cache do an automatic write-through all the time? It seems like it would be very dangerous to use if it doesn't.
wert@iapetus.rice.edu@rice.EDU (Scott Comer) (07/29/86)
In article <167@cascade.STANFORD.EDU> leeke@cascade.UUCP (Steven D. Leeke) writes: > >... > >In general, DO NOT just use CMD-SHIFT-1/2 to eject disks and turn the Mac >off when you are still in an application, but you have saved & closed your >document. Return to the desktop, Shut Down, and then turn the Mac off. Any why not? _Eject does a _FlushVol, and CMD-SHIFT-1/2 does an _Eject. Your floppy is no more nor less safe than when doing a Shutdown from the Finder. Your hard disk is still vulnerable. Perhaps someone should write a flush all volumes DA? scott
bart@reed.UUCP (Bart Massey) (07/29/86)
In article <2017@calmasd.CALMA.UUCP> cjn@calmasd.UUCP (Cheryl Nemeth) writes: > Does the cache do an automatic write-through all the time? As near as I can determine, the answer is no. > It seems like > it would be very dangerous to use if it doesn't. Yup, I and others don't ever enable it. It's frightening to think how a non-write-through cache works with novice users, who don't know enough to turn it off... How hard would it really have been for apple to make the write-through *optional*, like the cacheing itself? Bart Massey UUCP: ..tektronix!reed!bart
naftoli@aecom.UUCP (Robert N. Berlinger) (07/29/86)
> Does the cache do an automatic write-through all the time? It seems like > it would be very dangerous to use if it doesn't. Although I know nothing of the implementation, I have studied its behavior somewhat and think that it does not do immediate write-through. By "immediate write-through" I mean that data destined to be written to disk will not necessarily be written right away. For instance, if I set a large cache and then launch Red Ryder and receive a file, the incoming data will not be written out until the file is closed (at the end of the transfer). So the write-through is not immediate, although it is "automatic" (a poor term). -- Robert Berlinger Systems Analyst Albert Einstein College of Medicine UUCP: ...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli Compuserve: 73047,741
eric@batcomputer.TN.CORNELL.EDU (Eric Fielding) (07/30/86)
In article <167@cascade.STANFORD.EDU> leeke@cascade.UUCP (Steven D. Leeke) writes: >I believe that if you use the Shut Down command from the menu >the system will flush the cache to disk and things should be fine for you to >then turn off the mac. If you don't do this I believe that you may lose >things. > >Return to the desktop, Shut Down, and then turn the Mac off. > >Steve Leeke Does anyone know if the QuickEject DA also flushes the RAM Cache before shutting down the system? I have not been able to bring myself to trust the Cache, and have just left it turned off on my Mac Plus. --Eric Fielding ARPA Internet: fielding%geology.tn.cornell.edu
ix21@sdcc6.ucsd.EDU (David Whiteman) (07/30/86)
In article <2017@calmasd.CALMA.UUCP> cjn@calmasd.UUCP (Cheryl Nemeth) writes: >Does the cache do an automatic write-through all the time? It seems like >it would be very dangerous to use if it doesn't. There is an Apple representative who speaks at our users group frequently. He once told us the cache is NOT write-through; although there are ways to flush the cache under programmer's control. There were also taken to insure data is not loss despite the lack of an automatic write-through. Apparently there is a cache bit which can be set for an application. If the application cache bit is set this means that the application's resources can be cached without problem. If the cache bit is not set caching still occurs, but only resources in the system file and perhaps the finder are cached. I did not understand whether the cache becomes automatic write-through if the cache bit is unset or not, or whether an application is just not suppose to change system resources. Also only resources are cached, and caching is primarily suppose to reduce time in relauching applications and relauching the finder. I don't know how true the above is. The Apple rep has a tendency to over simplify things. -- David Whiteman, University of California, San Diego The America Cup, don't leave Perth without it.
dudek@utai.UUCP (Gregory Dudek) (07/30/86)
I find it very hard to believe that the Cache could be designed
as dangerously as people have been suggesting. I use mine all the time
and despite many crashes experienced while mucking around, have
never seen any signs of corrupted disk blocks which might be due to
the cache.
Can anybody from apple confirm or refute the serious allegations?
As for the claim that disk I/O only seemed to take place when a file was
closed, wouldn't an obvious and safe design for the cache would be one that had
write-through only for file-system information, and maybe the Desktop.
If this is what's happening, couldn't it explain some of the observed
I/O activity. i.e. a file's data blocks
don't get write-through so ordinary file capture doesn't seem to cause
immediate disk I/O.
--
Dept. of Computer Science (vision group) University of Toronto
Usenet: {linus, ihnp4, allegra, decvax, floyd}!utcsri!dudek
CSNET: dudek@Toronto
ARPA: dudek%Toronto@CSNet-Relay
Paper mail: 10 King's College Circle, Toronto, Canada winkler@apple.UUCP (Dan Winkler) (07/31/86)
There has been a lot of confusion regarding the RAM cache on this network. I have asked the author of the RAM cache to write a brief response to some of the most common questions, such as how to make the RAM cache work with applications which need the second screen, and he has agreed to do so when his workload permits. In the meantime, let me pass on one simple point he made to me which has been repeatedly misunderstood: The RAM cache IS a write through cache! It is the file manager which is not strictly write through -- it will buffer up writes until it has a whole block to flush to the disk. This is true for any Mac, whether it's using the RAM cache or not. This is of course exactly what you want since there would be a severe performance penalty associated with doing a physical disk access for every single byte write.
lsr@apple.UUCP (Larry Rosenstein) (07/31/86)
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