> All this talk about UIDE prompted me to investigate this tool. > It looks interesting. How does the caching work for disk writes?
UIDE uses "Write Through" caching, meaning all output data is written to disk immediately. For SATA/IDE disks handled internally by UIDE, if data fits in one cache block (75% of the time, for 64K blocks used by larger caches), data is moved to that block and output from there. UltraDMA is 32-bit and will do I-O from anywhere in memory, so direct cache I-O is possible. If output "crosses over" more than one cache block, data is written from the user output buffer, or from a 64K XMS buffer if the user's buffer is unsuitable for UltraDMA ("odd address" etc.), then moved to cache afterward. For smaller UIDE caches using less than 64K cache blocks, or when I-O crosses over multiple blocks, all I-O occurs on the FIRST block (NO "fragmented" reads/writes!) and UIDE moves data to the required cache blocks later. Diskettes, SCSI and other disks, whose I-O is handled by their drivers, cause UIDE to "call the BIOS" (or a "callback" subroutine for a "user" driver) then cache data after that call returns to UIDE. I experimented with "Write Back" caching ("delayed" writes) but never got it to work, and decided that it needed too many "hooks" into DOS, e.g. timer, Ctrl/Alt/Del vector, etc. For "Write Through" caching, UIDE needs to "hook" only the Int 13h vector for hard-disks, which is more reliable than "snaking through" the whole DOS system as SMARTDRV or Norton NCACHE2 must do. There is also a problem of power-failure whose only "true" solution is a U.P.S. (Uninterruptible Power Supply) and I shall NOT be the one to "recommend" such things for UIDE users! Finally, "modern" hard disks all have their own on-board write caches which pretty-much eliminate the need for a "Write Back" cache -- Note how fast deleting a large directory now occurs, with or without UIDE, and you will conclude that the disk write-cache must be "helping" for many operations! > I assume that when the cache is full the next sector read in will > cause the oldest sector to be written out? Absolutely! UIDE has a "least-recently-use" (LRU) linked-list which is part of its cache-block tables, and that list is updated for every I-O. When the cache is "full", the cache block at the "tail" of the list, i.e. the LRU entry, is made "free". This occurs at the end of every input or output, so UIDE always has a "free" cache block to use on the next I-O. Simpler logic, handling things that way! > Is there any sort of a timer which will flush the cache to the hard > drive periodically? No, and none is required, as UIDE does not "delay" any writes at all! > How do you make sure that the RAM cache is written to the disk? I simply output all data IMMEDIATELY -- NO "delayed" writes at all! That is both the beauty and the benefit of using only "Write Through" caching -- NO possibility of data LOSS, due to "waiting too long" and suffering a power-failure, a "bumbling user" on the keyboard, etc. as with a "Write Back" cache like SMARTDRV and NCACHE2! They may still be a bit faster, for some compiler or database operations. But UIDE compensates by being a very FAST "Write Through" cache, using only 5K of assembly-language (NO wretched "C" here!), with up to a 4-GIGABYTE cache capacity! None of the older caches can get that high! > I poked around in the documentation but did not find this information. Sorry, the source file for UIDE does say that it uses "Write Through" caching, but I did not put this in the README, which others will note is already "technical ENOUGH"! Jack R. Ellis ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Freedos-user mailing list Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user