Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucbvax!vax135!cjp From: cjp@vax135.UUCP (Charles Poirier) Newsgroups: comp.sys.amiga Subject: Re: FACC Message-ID: <1829@vax135.UUCP> Date: Mon, 20-Jul-87 12:26:26 EDT Article-I.D.: vax135.1829 Posted: Mon Jul 20 12:26:26 1987 Date-Received: Tue, 21-Jul-87 05:53:57 EDT References: <405@sugar.UUCP> Reply-To: cjp@vax135.UUCP (Charles Poirier) Organization: AT&T Bell Labs, Holmdel, NJ Lines: 29 Keywords: Problems, suggestions. Summary: FACC II does it In article <405@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Point. Facc does not allow the number of buffers to be specified ahead >Point. Facc doesn't background itself. We can't think of a good reason to >Question. Does FACC II come up with a window by default? We would prefer >Question. Does FACC preferentially cache directory and file header blocks. These things and more are handled in FACC II. Remember that ASDG promises free lifetime upgrades on FACC, so there's no point in waiting for FACC II's release. >Question. When Facc caches stuff, does it cache the whole track read in > when the block is read?.... I don't know this. >I remember reading something about someone's idea for making FACC a disk >cache rather than a drive cache. That seems an admirable idea, and would >make any sort of RAM disk far less important. Is it possible without total >rewrite? It's depressing to watch 1600 buffers go out the window when you >pop a disk. My idea, and I've bashed on Perry about it. But it would, in fact, require a total rewrite. FACC installs itself at a point where the volume name is not in the I/O request, only a drive unit and block number. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."