Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!julius.cs.uiuc.edu!apple!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Quien es mas macho? (HD caching)
Message-ID: <2729@atari.UUCP>
Date: 1 Nov 90 02:01:26 GMT
References: <1990Oct30.220831.17172@math.lsa.umich.edu> <1990Oct31.162831.10747@cs.ucla.edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 56

People seem a little unsure of how GEMDOS's cache (the one CACHEXXX.PRG
adds to) works.

There are two lists of buffers.  CACHE030.PRG, for example, will add 30
buffers to each list.  You can give it arguments to explicitly give  a
certain number to each list.

Both lists are write-through: all writes happen right away.

The first list caches FAT and root directory sectors.  Any FAT or root
directory access will use this cache.

The second list caches data sectors, defined as those which aren't FAT
or root directory.  Subdirectory sectors always use this cache. Normal
file data sectors only use this cache if your program doesn't do reads
and writes of complete sectors.  Then the data sector is read into the
cache, and the piece your program wanted is copied.

Whole-sector or multi-sector reads and writes don't use the GEMDOS
cache at all.  They always go straight to disk.  That's where the other
caches in the world can help.

With enough cache buffers, all of the FATs and root directories on all
of the drives on your system will end up in the first cache and never
be replaced.  It's a waste of space to have more sectors in the first
list than you have FAT and root directory sectors.

Having a lot of buffers in the data-cache list will mean that all your
subdirectory sectors will get cached, and in addition the parts of
files that get accessed as fragments, not as whole sectors.  One
example of this kind of access is in GEMDOS itself: Pexec reads the
header of a file to find out how big it is, and since the Pexec routine
only wants $1c bytes of data, the sector lands in the cache.  Then,
Pexec reads the text+data part of the file, and since it probably
doesn't end on a sector boundary that last sector winds up in the
cache.  Finally, Pexec reads the fixup information, and that probably
doesn't begin or end on sector boundaries, resulting in two more
fragments. (The end of the text+data and the beginning of the fixups
will be the same place unless there are symbols in the file.)

You can tell if you have "enough" sectors in each list by doing a "show
info" from the Desktop on all your drives, then doing it again.  If the
second time doesn't actually hit any disks, it means all the FAT, root
directory, and subdirectory sectors are in the cache.

Both caches are managed LRU: each time there is a "cache hit" on a
buffer, it gets moved to the beginning of the list, and when the time
comes to replace a buffer, the replacement is chosen from the end of
the list.

All this information is subject to change: I make no guarantees about
the workings of GEMDOS's cache system past, present, or future.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt