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
