CacheX V1.0 by Steve Tibbett INTRODUCTION CacheX is a simple hard disk cache. Simple because it doesn't buffer writes, nor get really fancy about caching. But useful because it will cache anything, even things that the FileSystem buffers will not cache. It has a friendly user interface, and is a commodity. You can see the cache hit stats, free the buffers at any time, suspend the cache, and even tell it to hold onto the buffers it's got, to keep only specific items in the cache. It caches an entire physical device, not just individual partitions, though it is limited to only one physical device. CacheX requires Kickstart 3.0 or later and a 68020 or better processor. I think it's important to mention that CacheX isn't just a cheap ripoff of something like HyperCache (which, I believe, is commercial) or any other cache program. I wrote the first version of CacheX approximately two years ago, and intended to include it with my bulletin board. I only recently decided to release it as shareware. WARNING CacheX's job is caching hard disk reads. Bugs in CacheX, while none are known, could cause bad data to be read from your hard disk. Before trying CacheX, it would be wise to make a backup, especially on systems that CacheX has not been tested with. CacheX is known to work with the A3000 "scsi.device", but that is the only device I have tested it with. HOW IT WORKS: The Simple Explanation You tell CacheX the name of a partition that is on the drive you want to cache, and CacheX figures out the device and unit that that partition resides on. CacheX then begins caching any reads to that physical unit - so every partition on that device gets cached. HOW IT WORKS: Technically When you tell CacheX the name of a partition to cache, it finds that partition in the device list, determines what Exec device and unit it pertains to, and opens that device and unit. It looks at the io_Unit value that the device provides at OpenDevice() time, and remembers it. Only IORequests to this device that have the same io_Unit value will be cached. CacheX then SetFunction's the BeginIO() vector of the device, and checks every IORequest to see if it's for the unit we're caching, and if it is, checks to see if it's a CMD_READ. If it is, it tries to fill the request from the buffers and if it cannot, it goes to the disk for the read. When the read is done, CacheX then goes and fills it's own buffers from the data read from the disk. Upon a CMD_WRITE, it refreshes any of it's own buffers that the data being written contains. There are a few potential problems here. One of them is that the device must use a unique io_Data value for each unit number, or else CacheX can't tell Unit 0 from Unit 1, for example, and might return the wrong data. Another potential problem is that SendIO() effectively turns into DoIO(), since to cache the read, CacheX has to complete the read before returning from BeginIO(). CacheX is a low-memory-handler, so if a memory panic is about to fail a memory request, CacheX will step in and dump it's buffers which may allow the memory request to succeed. CacheX uses the 3.0 memory pool system to allocate its buffers, and the buffers are allocated on demand (not all at once) but since they come from the end of memory, and are in pools of 32 buffers, memory fragmentation should not be a problem. The CLIP option is normally set to 32K. When the number of buffers in a read request is larger than this number of buffers, the read will not be cached. This is to prevent very large reads from flushing all the buffers, and to speed things up when reading large files. (Copying the data from the Read buffer into the Cache buffers takes an amount of time, and can actually slow down your hard disk the first time you read something). If you want to cache every read, then set this value to a number larger than your number of buffers. FILESYSTEM BUFFERS VS CACHEX BUFFERS If you are going to use CacheX, you should only use a few FileSystem buffers (ie, ADDBUFFERS, or changing the Buffers value in HDToolBox). 30 is a good number. Since CacheX is a device cache, not a filesystem cache, it should happily cache blocks that foreign filesystems are using, such as the various MSDOS file systems out there. The main reason CacheX was written, is because FFS refuses to cache reads of data bigger than 512 bytes. What this means is that if you do something like "COPY C:LIST RAM:", it will go to the disk to get C:LIST every time, no matter how many buffers you have. If you have a noisy hard drive, and if you are running a BBS, or any other program that accesses a lot of small data files often, this program should quieten things down. THE CACHEX WINDOW When CacheX is started without the HIDE keyword, it will open a small window showing you the status of the cache, and give you some buttons you can push. These are: CACHE ACTIVE? This checkbox is normally on. When it is off, CacheX will do nothing. HOLD BUFFERS? This checkbox is normally off. When it is on, CacheX will not allocate any new buffers, keeping any data in the buffers from being flushed. Writes will still update the buffers that are already in memory. This option is used for loading a set of data into the buffers and then keeping it there. BUFFERS: This is the number of buffers. Changing the number of buffers will dump all data currently in the buffers. You have to hit return in this gadget to actually change the number of buffers. RESET STATS This will clear the statistics showing the number of reads, writes, hits, and the hit percentage. HIDE This will close the CacheX window. See below for more details. QUIT Terminate CacheX. HOTKEY: This is the commodities hotkey that you would use to summon CacheX when it's window is hidden. When you HIDE the CacheX window, it will try and open the commodities library, and if it can, it will close it's window, and set itself up as a commodity. Caching will continue normally. When you hit the hotkey, or use Exchange to tell CacheX to open, CacheX will reopen it's window and remove itself as a commodity. OPTIONS CacheX has a number of options, one of which is required (the name of the device to cache). The options are indicated by the template "DEVICE/A,BUFFERS/N,HOTKEY/K,HIDE/S,CLIP/N", which are: DEVICE/A The name of the device to cache. This should be the name of any partition on the device you want to cache. BUFFERS/N A number, which is the number of buffers you want. Each buffer is the size of the block on the device you're using, normally 512 bytes, but on CDTV (for example) this would be 2048 bytes. (NOTE that this program requires 2.04 so it won't work on CDTV). HOTKEY/K The commodities hotkey specifier, as described in the 2.0 manual, that will bring up CacheX when it is hidden. This string will normally contain a space, so must be specified as HOTKEY="the string". HIDE/S This switch tells CacheX to come up hidden. This is useful for having it automatically start up, as in your WBStartup drawer. CLIP/N This is the CLIP value as described in the technical description above. It's default value is 64 buffers, and you can normally leave it set to this. FAST/S Restrict CacheX to only using FAST memory for it's cache. If you use a large number of buffers, you can rely on the low memory handler to dump the buffers when you run out of memory, restrict it to FAST ram, and all your unused fast ram will turn into a disk cache. However, programs that ask for memory in this case may have their requests for any memory return chip ram since CacheX's low memory handler doesn't get told about this situation. These options can be specified on the command line from CLI, or can be set as ToolTypes when CacheX is being started from Workbench. INSTALLATION: Workbench To run CacheX from Workbench, you can simply double-click on it's icon. However, you must tell CacheX what device to cache. You do this by getting Information... on the CacheX icon, and changing the DEVICE= tooltype to the device name you want to cache, as in "DEVICE=Work:" (without the quotes). You can set any of the other options in the same manner. Once you have edited the tooltypes, double-click on the icon and CacheX should open it's window. To have CacheX automatically started when you reset your computer, you need to have it set up so the DEVICE= tooltype is present, and you also need a "DONOTWAIT" tooltype and the "HIDE" tooltype. When you have done this, drop CacheX's icon into your WBStartup drawer, and CacheX should automatically start up next time you reboot. (You won't know it's there unless you go looking for it, since it will be hidden). INSTALLATION: CLI To run CacheX from CLI, you just have to give the device name. "CACHEX WORK:" will open the CacheX window and start caching the Work: device. Any of the options listed above works as you would expect them to: "CACHEX WORK: HIDE BUFFERS=1000 CLIP=500" would start CacheX with 1000 buffers, the clip value set to 500, and would not open the window. Note that if you want CacheX to run in the background, you have to use RUN >NIL: