> 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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
