Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!chp!rph From: rph@chp.UUCP Newsgroups: comp.sys.m6809 Subject: Re: 512K RAM upgrades (Caching) (too long) Message-ID: <1987Aug25.163719.1827@chp.uucp> Date: Tue, 25-Aug-87 16:37:19 EDT Article-I.D.: chp.1987Aug25.163719.1827 Posted: Tue Aug 25 16:37:19 1987 Date-Received: Thu, 27-Aug-87 06:53:14 EDT References: <5013@milano.UUCP> <1987Aug19.210404.455@chp.uucp> <2004@lsuc.UUCP> Reply-To: rph@chp.UUCP (Pontus Hedman) Organization: The Coach House Press Lines: 104 Keywords: OS9 CACHE SDOS Checksum: 3756 Before I start blathering, I'll just give my bottom line here at the top for those who otherwise would never see it: o Ramdisks are nice if you have piles of memory. o Caching is nice and doesn't need piles of memory. o It's nicest to use both at once. o As for the caching, personal experience has shown me that it doubles disk write throughput and doesn't cause reliability problems despite my endless crashing. Now for the blathering: In article <2004@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >In article <1987Aug19.210404.455@chp.uucp> rph@chp.UUCP (Pontus Hedman) writes: >>... 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 run OS9 Level 1 with two 500k floppies... I've found caching is very useful for it. Flushing the cache (by typing "unmount") is no big deal, and 80% of the time unnecessary because it's already gotten flushed automatically in idletime. I think what really matters is that with R/W caching, you stick in a disk, edit/whatever a file, type "unmount" after which everything will be safely sitting on disk. Total time, 30s. Without the write caching, the drivers thrash about doing unnecessary writes (by a factor of 2-3; I did tests) and although you don't need to type "unmount", your total work time becomes 60s. Btw if you don't do any more writing the blocks will automatically get flushed anyway and you won't need to type unmount - when the disks stop spinning you're safe. >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. I tried ramdisk first, then I tried read-only caching. Can't do both (snif). I have 32k of non-OS9 memory which makes for an all but useless RAM disk - but it makes one heckuva good cache. The read caching worked wonders for file access but I still noticed that writes were really pathetic and that's why I added write caching. I'd never go back to read-only caching. >>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. I assume those disks that got lunched were not write cached? If so it should be apparent that your disks will get wrecked whether write cached or not :-). > 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) Ah now THAT is the most significant problem with write caching! When it comes time to flush a block and you find that the block won't write, what should the driver do...? Mine currently ignores the error (BOO HISS BOO). I do get to hear the drives rattling and then I get to try to guess what recently-written file has gotten munged. But ah well, write failures happen no matter what. There are far fewer physical writes with caching which reduces disk wear so I guess that makes up for it. > 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 >... >[w.out write cache] 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'm not sure what a "critical" write means here; for me it means a file descriptor sector or LSN 0. I gathered statistics on this when doing the caching (by hanging hooks into the driver to note block access)... without write caching, those blocks are constantly getting written out. With write caching, the FD sectors tend to get written out only when the file is all updated and closed and left alone. When your computer dies with write files open those files are pretty well guaranteed to be messed up anyway. With the write caching, when I fix up the disks I usually end up with the filesystem the way it was 10 seconds *before* the crash, which I kinda like. Not much I can say except "works for me". My machine runs a BBS 24h/day and used to run read caching only. Then I added write caching. It's just quieter and faster and wears out disks less due to less seeks. The machine has lousy memory so it crashes incessantly but I don't lose files. -- Pontus Hedman {utzoo|utgpu}!chp!rph