Path: utzoo!lsuc!ncrcan!brambo!morgan
From: morgan@brambo.UUCP (Morgan W. Jones)
Newsgroups: comp.sys.amiga
Subject: Re: simple AmigaDos thrashing solution
Message-ID: <293@brambo.UUCP>
Date: 28 Feb 88 16:46:39 GMT
References: <8504@sunybcs.UUCP> <1177@goanna.oz> <107@boing.UUCP> <5282@well.UUCP>
Reply-To: morgan@brambo.UUCP (Morgan W. Jones)
Organization: Bramalea Software Inc., Bramalea, Ont.
Lines: 23

In article <5282@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>	If anyone should be responsible for caching disk data, it is the
>client to the trackdisk.device (in this case, the filesystem).  Only the
>client program "knows" what its behavior is going to be like, and only it
>can make intelligent decisions regarding caching.  The client can also copy
>its caches out to FAST RAM if it exists.

To an extent, you are right.  If anything is going to cache sectors
from the disk, it should be something at a higher level than the
trackdisk.device.  However, the trackdisk device should cache tracks,
at least until the simulataneous access problem is solved.  This is
because the trackdisk.device accesses by tracks but only returns
sectors; thus two processes accessing files at the same time will
cause the same tracks to be re-read several times.  The filesystem
could cache sectors 'till it was blue in the face and it still
wouldn't solve this problem.

>Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\

-- 
Morgan Jones - Bramalea Software Inc.        morgan@brambo.UUCP
      ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan
"These might not even be my opinions, let alone anyone else's."