Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!lsuc!jimomura From: jimomura@lsuc.UUCP Newsgroups: comp.sys.m6809 Subject: Re: 512K RAM upgrades Message-ID: <2004@lsuc.UUCP> Date: Sun, 23-Aug-87 12:20:12 EDT Article-I.D.: lsuc.2004 Posted: Sun Aug 23 12:20:12 1987 Date-Received: Sun, 23-Aug-87 16:48:59 EDT References: <5013@milano.UUCP> <1987Aug19.210404.455@chp.uucp> Reply-To: jimomura@lsuc.UUCP (Jim Omura) Organization: Law Society of Upper Canada, Toronto Lines: 95 Keywords: OS9 CACHE SDOS Summary: Big RAM Disks are different In article <1987Aug19.210404.455@chp.uucp> rph@chp.UUCP (Pontus Hedman) writes: > >In article <1997@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >> Well, I have to disagree with the trend here. I don't like full >>cache for OS-9 systems. There are a *lot* of different approaches to >>speed and system integrity. Full read/write cache adds speed but at >>substantial risk of data loss and file corruption in the case of power >>failure or other hardware flakey failure. Thanks guys, but no thanks. >>Data integrity is too important for me to risk that. Read cache--which >>was done by TLM on the Atari ST OS-9 port was, in my opinion, the >>best compromise. Keep in mind that OS-9 allows you to *preload* >>object files. This is much more efficient than cache. Secondly, >>for datafiles, it's faster to throw intermediate files and reasonably >>small files into a RAM disk. If a file won't fit in, say a 512K RAM >>disk, a cache isn't likely to help that much either. A RAM disk has >>most of the same problems for data integrity as a cache, but at least >>you have an inherently better chance of retaining the "old copy" intact >>even if you lose the copy in RAM disk. A partially updated disk copy >>when the power goes down (or other "bad crash") is generally worthless. >> >>Cheers! -- Jim O. > >Humph. I've been running full R/W caching 24h/day for a year now and haven't >had any problems. The cache typically clears out within less than half a minute >of disk activity finishing, and if I'm about to test some dangerous >program, I manually flush the cache (some kind of manual cache-flushing >has to be provided anyway for when you want to change disks). Exactly. You have to flush the cache manually on occasion anyway. For some people that won't be often. For floppy users and small hard disk/floppy systems (which are the *most* common for OS-9 systems) it's more often. I note that the people who have been commenting on my previous posting have not addressed the Read cache but seem to think the only thing I talked about was RAM disk. Guys, have you even *tried* read cache without write cache with RAM disk? And then there's the *size* of the RAM disk. My Atari 1040ST RAM disk was 360K and for a while my QT was 512K RAM disk. My QT is back down to 128K now due to a memory card failure. In fact, when I get my memory card fixed I might go as high as 1 Meg. RAM Disk. It's hard to say. The half Meg. was fine for most things. I'm just thinking about what size I'll need when I start getting large databases up. 32K and 128K are pretty pointless really. >I haven't had any kind of disaster that I couldn't fix with DCHECK. Probably due to clean living. :-) Personally, I've had the following over the last year or so: 2 floppy drives went bad last winter due to power outages (along with a power supply) with disks lunched along for the ride. Power outages killed the RAM probably about a dozen times over the year (mostly 1 sec. range power drops--I suppose I should have bought a UPS by now, but I haven't and I mean only the contents of the RAM while the computers survived). I've also had a hard disk show signs of read/write failure due to overheating (this was the Supra on the Atari ST whereas the above problems were on the CoCo3) and also an Atari SH204 hard drive is not dead and in for repair, most likely due to media failure. The power outages haven't generally hit the QT/ST setup as hard as the CoCo3. I think the reserve capacitance seems to cover a bit over 1 sec in these two machines. I've found situations where the CoCo3 had reset and the ST and QT had survived with RAM intact. I've only had the ST for a year or so and the QT for about 1/2 a year so I'm just getting a feel for them. So far though I've only lost RAM contents in the QT a couple of times due to power drops. Still, it happens. Now, you say you've never lost critical data. That's a matter of straight percentages. As you note, the longest time between the system write call and the actual write for you is about 1/2 minute. Let's say it's typically 10 seconds (not an unusual mean time for some systems although 2 - 4 seconds mean time is also possible depending on usage patterns and the scheme used). If you have critical writes 100 times a day (pretty low for a business system) then you can figure the percentage of critical writes per day and then figure out the odds of hitting a critical write with power failure. It's pretty low. But what's low may not be small enough for someone else. It depends on what you're doing. It also depends on how much of a gambler you are. I'm just not that much of a gambler. >I write stuff in C and ASM and haven't yet lost a file. Obviously I have. >I used my extra RAM here as a ramdisk before. I find R/W caching >much faster and trouble-free. For C, for example, the edit-compile-test >cycle simply became shorter (admittedly I have only 32k to use for >ramdisk/caching; with bigger memory sizes a ramdisk might be faster). -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura