Re: File Access: cache-on-HDD, more

[Adrian Ratnapala <s369625@student.uq.edu.au>]

On Sun, 15 Nov 1998, Christian Reiniger wrote:

> Ok, next issue.
> 
> Shai suggested that we provide som sort of cache-on-hdd, e.g. for caching
> many smaller files to circumvent the long CD-ROM seek times or to cache
> files after decompression etc.
> 
> Another feature that more or less goes hand in hand with that is
> transparent aliasing, i.e. aliasing file names/access paths at runtime,
> e.g. to faciliate i18n or - to redirect accesses to cached files.
> 
> 

Hmm, maybe I don't see what it has to do with i18n since users
should be isolated from filenames (except for savegames). 

Let's see:

hdd cache: should we be doing it or the app?

alias: Well, the pakfile system will need a filename
cache anayway.  We could then use this filename cache to redirict
requests for files on the PAK file to outside it.  

This brigns me to an important question:

How is our pakfile going to help us with speed?  As I see it, it
will mostly be acting as a fast directory cache.  We read the pakfile
and store an in memory map of path<->offset.  Does this make a really
big difference?  Should we be worrying more about things like the cache.

I am out of my depth here, where can we get info about he performance
effects of a PAK file, maybe they are just a hack to get around the 
stupidity of FAT.

> 
> AAAAA - American Association Against Acronym Abuse
> 
Australian
Association
Avidly
Advocating
Accurate
And 
Appropriate
Acronyms

That's only 8, I got it up to 10 once.  (Besides the `And' and `Avidly'
are cheating).