meulenbr@cstw01.UUCP (Frans Meulenbroeks) (06/30/88)
After seeing a number of cache programs, I decided to scribble down what
I wanted to see in an ideal cache program.
I am posting this for two reasons:
1) to get feedback about missing items, problems to be expected etc.
2) because I have little time to start the actual implementation, someone
else might give it a try. (Hint, hint). If you want to, drop me a note
saying so, in order to avoid duplication of effort.
Don't expect an implementation from me soon.
How my ideal cache looks:
- startable from auto folder or accessory which installs itself silently
- settings (like size) taken from program name or data file
- resizable when in operation
- selectable which devices are cached
(it is not too useful to cache a ram disk)
- works both with floppies and hard disks
- selectable whether or not write-through
- if not write-through:
- has an auto "sync" facility, which will flush all written buffers
- interval of above facility is user definable
- has a command to flush explicitly
- detect media change and warn (insist?!) that the previous floppy is
re-inserted when unwritten buffers exist.
- intelligent replacement algorithm (something like Least Recently Used)
- (optionally) read ahead (cache the complete track when a sector is
requested)
- perhaps (optionally) always cache FAT and root dir.
I think this can lead to a safe write-delayed cache.
Since a number of things can be modified during operation, the cache will
most likely be implemented as an accessory.
--
Frans Meulenbroeks
Centre for Software Technology
...!mcvax!philmds!prle!cst!meulenbr or ...!uunet!prlb2!cst!meulenbr
or perhaps meulenbr@cst.prl.philips.nlegisin@watmath.waterloo.edu (Eric Gisin) (07/04/88)
In article <157@cstw01.UUCP>, meulenbr@cstw01.UUCP writes:
< After seeing a number of cache programs, I decided to scribble down what
< I wanted to see in an ideal cache program.
<
< How my ideal cache looks:
< - startable from auto folder or accessory which installs itself silently
< - settings (like size) taken from program name or data file
I don't do this in my cache and other resident programs
because I is so trivial to write a small (<1K) program
that reads a file (AUTO.BAT) containing commands of the form
<command> <arguments>
and Pexec's the commands. Put this program in \AUTO.
This also avoids the problem of order of execution of AUTO programs.
< - resizable when in operation
If I want to implement this by having a configuration program
(CCONFIG.TTP) pass the request to the resident cache program,
how do I get TOS to arrange that the Malloc'd block are associated
with the resident program, not the configuration program?
How do resizable ram disks do this?
< - selectable whether or not write-through
< - if not write-through:
< - has an auto "sync" facility, which will flush all written buffers
< - interval of above facility is user definable
A delayed write-through cache seems like the best idea,
but I don't know how to implement it. A VBL routine could check
whether it was called from user mode and flush dirty sectors then,
but you are rarely in user mode when waiting for input (shell prompt).
Anyone have any other ideas on this?
< - has a command to flush explicitly
< - detect media change and warn (insist?!) that the previous floppy is
< re-inserted when unwritten buffers exist.
< - intelligent replacement algorithm (something like Least Recently Used)
< - (optionally) read ahead (cache the complete track when a sector is
< requested)
< - perhaps (optionally) always cache FAT and root dir.
Making the FAT permanent is unneccessary with any reasonable replacement routine,
the FAT is referenced constantly by TOS.
<
< I think this can lead to a safe write-delayed cache.
< Since a number of things can be modified during operation, the cache will
< most likely be implemented as an accessory.pes@ux63.bath.ac.uk (Smee) (07/04/88)
My (rather limited) investigations lead me to believe that your '(optional) read-ahead' -- i.e. convert sector reads to track reads and cache the whole track -- unless of course you've already got it -- probably offers the greatest potential for speedup. However, I haven't yet designed such a thing clever enough to deal with the fact that not all my disks are laid out with the same number of sectors/track. Cheers, Paul
poole@forty2.UUCP (Simon Poole) (07/05/88)
In article <157@cstw01.UUCP> meulenbr@cst.UUCP () writes: >After seeing a number of cache programs, I decided to scribble down what >I wanted to see in an ideal cache program. .... >2) because I have little time to start the actual implementation, someone > else might give it a try. (Hint, hint). If you want to, drop me a note > saying so, in order to avoid duplication of effort. > Don't expect an implementation from me soon. Hmmmm, I would suggest waiting for the new TOS version first (which hopefully isn't all to far away) before spending all too much time on a project like this. -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
jason@lakesys.UUCP (Jason) (07/06/88)
In article <2752@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) writes: > > My (rather limited) investigations lead me to believe that your '(optional) > read-ahead' -- i.e. convert sector reads to track reads and cache the whole > track -- unless of course you've already got it -- probably offers the > greatest potential for speedup. However, I haven't yet designed such a thing > clever enough to deal with the fact that not all my disks are laid out with > the same number of sectors/track. > > Cheers, Paul No, you wouldn't be able to figure out exactly what a track was, but it wouldn't seem that it would matter all that much... The things that need the most speedup are the floppies, so you could use the Sectors/Track value from the floppies (Of course, there may be problems there too, due to the different formatters running around), and just use the same value for HD buffering. It would seem that even though you'd get more seeks than would be completely optimal, it'd be an improvement over the original (non-buffered) scheme. Of course, you could have a config (or run-time if it were a DA) that would allow the user to set different sector/track ratios for each unit (drive letter, whatever you want to call it), with reasonable default values. This would allow for a very respectable speedup for those who don't know much about the guts of their machine, and a larger speedup for the techies in the crowd. -- Jason - Not your average iconoclast
pes@ux63.bath.ac.uk (Smee) (07/07/88)
I was specifically worried about different sectors/track on floppies. (I can't afford a hard disk yet.) I run MOST (but not all) of my 'active' floppies at 10 SPT for the space; and MOST (but not all) of my 'archive' floppies (non-image backup) at 9 SPT because its 'approved' and so feels safer. The problem isn't insurmountable (the system knows what the SPT of the mounted flopsies are); it's just finding a clean, release-independent method of getting the info into the cache routine, without using the offical TRAP call (since you're already in a TRAP handler) and without imposing unacceptable time penalties (like duplicate reads of Sector 0. Biggest problem is that my present schedule isn't leaving me any time for playing with my ST, and the cache is pretty far down my play list. Sigh.