Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: ASDG Floppy Accelerator (and other rumors) Message-ID: <282@l5comp.UUCP> Date: Wed, 3-Jun-87 21:11:59 EDT Article-I.D.: l5comp.282 Posted: Wed Jun 3 21:11:59 1987 Date-Received: Tue, 9-Jun-87 01:56:05 EDT References: <558@gryphon.CTS.COM> <3173@well.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Distribution: world Organization: L5 Computing, Edmonds, WA Lines: 76 Summary: Facc is a 'Write Thru Cache' and notes on soft memory and caches In article <3173@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: >In article <558@gryphon.CTS.COM>, richard@pnet02.CTS.COM (Richard Sexton) writes: >> What happens when my machine guru's with Facc? Can I lose data ? >> > [ long article which may or may not have cleared it up for the original > poster ] As originally stated Facc uses a 'write thru' cache. What this means is that when writes to the disk occur the data is written to the disk without hanging around in Facc for awhile. The intent of this is to get the data onto the drive as quickly as possible to avoid the problem brought up about Mr. Guru coming by for a visit at the wrong time. However, there are some fine points about this kind of caching that Perry did not address in his posting. 1. Some 'write thru' caches will copy the data to the cache before the data is written to disk. This leaves a small window in which data can be lost. Perry states that Facc doesn't change the order in which things get written. This probably means Facc doesn't fall into this type of cache. 2. You CAN have a write thru cache that doesn't copy into the cache on writes. But these kinds of caches must invalidate any cached data for the block that was just written. And must re-read the block just written into the cache. This is bad because I've noticed that amigadog writes file extension blocks and then turns right around and re-reads them. 3. A write thru cache can write the data and THEN copy it into the cache. But most often when the phrase 'write thru cache' is used # 2 above is the scheme. Perry also writes: >then there is no difference with our without Facc. If you guru during a read >from floppy then there is no difference with or without Facc (in fact, Facc >might even prevent disk damage if the sector was being read from an internal >buffer thus the heads would *not* be in motion when the guru occured). If I fail to see what advantage there is to the heads not being in motion when a guru occurs. This smells of the misleading data that others wish to suppress around here. It should also be pointed out that the "System Request Task Held" requester is NOT the end of the road in many cases. Multi-tasking is usually still active so that non-write thru caches, like the one used by trackdisk.device, can get a chance to write out to the disk before Mr. Guru pops up and shuts down the box. In fact you can often use popcli to get a CLI to use to copy files off RAM: before clicking continue to go see the guru. Such files should be inspected carefully for damage though once the system is back up. Loose pointers get program's guru'd and files in RAM: damaged. And for those that REALLY want something to worry over, ;) a loose pointer can also wack a cache just before it gets written to disk... Which makes the grace period given by the "Task Held" requester somewhat suspect, but I'm a bettin' man. I'd rather risk the odds that a loose pointer didn't get my trackdisk.device (or xxxdisk.device) cache than risk that there IS something undamaged in a cache that should be written out. But if the memory in your Amiga goes "soft", like the ram in my Amiga is doing, the odds of a cache going bad DO go up. I've had various files on my floppy and hard disks go bad recently that I've only READ not written. For example I had a header file from C-A that had the misfortune of being on the same track as a file I had been writing to convert to gibberish part way through the file. Since the Amiga doesn't have parity checked main memory it's important to take evidence that the main memory in your Amiga is getting soft SERIOUSLY. The floppy you save could be your one and only copy of something. :) Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)