Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!kunivv1!wn2!janhen
From: janhen@wn2.sci.kun.nl (Jan Hendrikx)
Newsgroups: comp.sys.cbm
Subject: Re: SEQ file access speedup
Summary: Some corrections after looking at the DOS disassembly
Keywords: 1541 DOS 2.6 disassemble
Message-ID: <340@wn2.sci.kun.nl>
Date: 20 Feb 89 13:19:10 GMT
References: <89Feb10.182100est.2732@godzilla.eecg.toronto.edu> <338@wn2.sci.kun.nl>
Organization: University of Nijmegen, The Netherlands.
Lines: 29

In article <338@wn2.sci.kun.nl>, I wrote:
> As far as I remember without my references around, (I don't have a 64
> anymore for over two years now), the algorithm is about the following:

To be complete, I now have an Amiga and a 64 emulator :-)

> There is a routine which takes a buffer number and sets a pointer to
> that buffer somewhere. It maintais a Least Recently Used stack, based
> on the requests it gets.

After looking at the disassembly for some time, I found the following:
The LRU table is not a table of disk buffers, but of Logical INDeXes.
That is something like an internal file number for the disk. Every time
a block is read or written through a LINDX, the LRU is updated.

> Some other things I would need to look up are whether files open for
> writing also have an inactive (write-behind) buffer, and whether
> (trying to) allocate an inactive buffer may cause another inactive
> buffer to be discarded.

Both of these are true. It even appears that when switching to the
other (inactive) buffer, there is _always_ a need for a (temporary)
second buffer. If no such buffer can be found (or stolen), you get an
error #70, no channel. I have not found, however, any guarantee that
such a temporary buffer "almost always" will be available. So maybe one
of you netters can go out and write a program that produces error #70
when you are just writing to (or reading from) an ordinary file...

-Olaf Seibert