Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!hplabs!pyramid!voder!wlbr!pete From: pete@wlbr.EATON.COM (Pete Lyall) Newsgroups: comp.sys.m6809 Subject: Re: on a Disk Cache for OS-9 Message-ID: <1114@wlbr.EATON.COM> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: wlbr.1114 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Sat, 15-Aug-87 01:32:47 EDT References: <5013@milano.UUCP> <1107@wlbr.EATON.COM> <5034@milano.UUCP> <1109@wlbr.EATON.COM> <989@pixar.UUCP> Reply-To: pete@wlbr.UUCP (0000-Pete Lyall) Organization: Eaton IMS, Westlake Village, CA Lines: 18 Keywords: OS9 CACHE SDOS In article <989@pixar.UUCP> bp@pixar.UUCP (Bruce Perens) writes: >The way I'd like to see an OS-9 disk cache implemented would be like the >SDOS cache, but with one more wrinkle - use all of the memory not being >used by processes, and when a process wants more memory, flush some >cache buffers and surrender that memory to the process. .... What a resource management nightmare that would be! Could you imagine having to flush the cache every time a new path was opened? How about when f$all64 required a new block? Even simple, non-executing f$load's ? Seems you'd spend as much time allocating & deallocating RAM as doing anything else. I suspect that it may be better to empirically determine the optimal cache size for your system, and then fix it at that size at system startup. -- Pete Lyall Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)