Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!im4u!milano!baxter From: baxter@milano.UUCP Newsgroups: comp.sys.m6809 Subject: Re: 512K RAM upgrades Message-ID: <5034@milano.UUCP> Date: Thu, 6-Aug-87 12:31:27 EDT Article-I.D.: milano.5034 Posted: Thu Aug 6 12:31:27 1987 Date-Received: Sat, 8-Aug-87 11:49:31 EDT References: <5013@milano.UUCP> <1107@wlbr.EATON.COM> Sender: baxter@milano.UUCP Organization: MCC, Austin, TX Lines: 124 Summary: How disk cache is implemented (Warning: long message) In article <1107@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes: > Disk Cache, eh?? Can you elaborate on how it is implemented?? Is > it only cached on the read side (writes go directly do disk for > file system hardening)? Also, is the cache memory usurping precious > system address space (probably not, if you're using the board...).. If > not, how is it getting the memory for the cache allocated to the > driver?? I believe that an OS9 F$srqmem will respond to a device > driver's request with SYSTEM memory. You have my full attention.. I'd > like to hack a similar goody into the GIMIX.. > The cache is a really dandy replacement for a RAM disk. The major advantages are that you: a) Need not load up a RAM disk before you start using it b) Don't have copy files from other disks when you discover you need them c) Don't have think about what you do next d) Don't have to worry about losing a whole day's work because of a power blink. How does it work, you say? The cache is both a read- and write- buffering cache. I run it with about 300kb of the 512kb dedicated to the cache, so the last 1200 sectors (LRU: least recently used) are retained (which means practically everything I do). Read requests are first tested against the cache; if it has it, no disk I/O occurs. Whether a read occurs or not, the fetched sector is made "most-recently-used" (MRU), which is a hueristic indication of the likelyhood it will be needed again later. Sectors which have not been referenced implicitly age as other sectors are made MRU; the oldest sector is called the LRU. Writes to disk go instead to the cache unless it is full and the oldest stuff in it is dirty; in that case, the oldest dirty stuff is forced to disk and the new dirty stuff is dropped into the cache to maintain the MRU property. Writing to the disk is done in "segments", i.e., all dirty disk blocks with sequentially increasing sector numbers, up to a cylinder boundary, starting with the oldest dirty disk block, are written, so one seek gets rid of a lot of dirty stuff, really quickly. Both the floppy content and the Wini content are intermixable in the cache. It is great fun to work on the floppy: initially, there's lots of seeks... and they gradually fade away, as the "floppy" gets faster and faster. The cache is almost (within inches!) big enough to hold the entire content of two floppy disks without doing any I/O; in practice, it holds everything you work with. Who needs a hard disk (:-})? It even speeds up a hard disk system, radically in the case of lots of random I/O, and by a factor of about two when a process insists on reading one big file sequentially and writing another sequential file at the same time. When a 20 second "no disk requests to the OS" fuse expires, the cache dumps the oldest dirty segment, marks all the sectors in that segment as clean (retaining them in the cache), and continues doing that until everything in the cache is clean or a disk I/O request happens from an application or the OS, at which point the 20 second fuse is re-enabled. The effect of this is that the operators think time (or pure compute time of an application) is used to keep the file system up to date. The fuse almost always ensures that the cache contents are clean in any practical situation, which means writes are always virtually instantaneous. In 9 months of use, I have lost only a little bit... that's because I debug inside the OS and let programs run away once in awhile. In normal use, only a power fail before the 20 second fuse can get you, so it is really quite reliable. You can also force the cache to flush all the dirty stuff for a particular disk with a special system call (CC:DUMPBUFFERS) or a command interpreter DISMOUNT command. (This allows programs or users to express their paranoia about particular data). The DISMOUNT command is necessary when you switch floppy disks, or are about to turn off the machine and don't want to wait 20 seconds. When fuse-flushing, the disk head can jump about quite a bit if you have done lots of writes to random places on the disk recently, but this time is free anyway, and the idea is that it is most important to get rid of the oldest (i.e., most-probably-useless) stuff. The DUMPBUFFERS/DISMOUNT flush is different than the fuse-flush in that dirty segments are dumped in lowest-sector-number-to-highest order, which means the disk heads DON'T jump around... they simply sweep across the disk in cylinder-increasing order, dumping data as fast as the machine can write. It takes about 15 seconds to dump 300Kb of dirty cache to the Wini doing this; 160Kb of dirty floppy takes more like a minute, but it is done with verify (2 passes over every sector), and this NEVER happens in practice. Cache code does usurp precious system address space... about 1kb. Seems like a small price to pay for the performance it buys. There is zero effect on the max size of a user program; mine can be as large as $FE00 bytes in size. You do need to give it a lot of RAM (as I said earlier, I give it 300Kb), but I can still run two 65Kb processes, which is about all I can personally figure out how to use at one time anyway (i.e., some nasty compile in the background, running screen editor in the foreground). Now that your tongue is hanging on the floor I'm going to stomp on it. The bad news is that this cache is implemented for a little known operating system call SDOS, not OS/9, which I happen to like partly because I am the author of it; it is not commercially available on CoCos right now. Some other interesting quirks of the CoCo3 implementation of SDOS: a) Talks to any SCSI-compatible Wini (Up to 250 Mb) (two at once, if you want) b) It does provide a RAM disk, but I NEVER use (can't seem to find ANY advantages, but I couldn't resist implementing it; only took two pages of assembly code). c) It knows how to do decent floppy I/O: I can use the screen editor even when SDOS is flushing to the floppy, as it doesn't lock out the processor to disk I/O. Yes, it does this with the standard Radio Shack controller. d) Floppy I/O is fast: about 6Kb/second continuous read rate. Writes are ALWAYS verified, but are still pretty fast (1/2 the read rate), because the write process for a segment does WRITE/.../WRITE then VERIFY/.../VERIFY e) Floppy disk sizes of 170Kb, 360Kb, and 720Kb are all supported. The cache supports all of this junk. -- -- Ira Baxter Microelectronics and Computer Technology Corporation / STP (512) 338-3795 3500 West Balcones Center Drive, Austin, Texas 78759