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..."