Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!news
From: news@steinmetz.ge.com (news)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Disk Cache programs vs. BUFFERS=: Whats the diff?
Keywords: disk cache, DOS buffer
Message-ID: <12321@steinmetz.ge.com>
Date: 8 Oct 88 14:33:59 GMT
References: <3017@dalcs.UUCP>
Reply-To: dixon@control.steinmetz.ge.com (walt dixon)
Distribution: na
Organization: General Electric CRD, Schenectady, NY
Lines: 51

some of the mechanisms involved in dealing with them.  It is unclear whether
the DOS buffer mechanism was ever intended to be a general purpose cache;
the original design was probabaly tuned for original PC's (small memory,
floppy disk) and never was enhanced significantly.
From: dixon@control.steinmetz (walt dixon)
Path: control!dixon

DOS uses its buffers to hold FAT and directory blocks.  The only time a
buffer is used for read or write is when a partial block is being processed.
Internally DOS calls cached read/write routines when there is a possibility
of using its cache (eg directory search);  otherwise it sends requests directly
to the device driver.   The DOS buffer mechanism caches individual blocks.
DOS maintains the cache as a linked list and searches it linearly.  The
caching code is actually some of the more brain-damaged code within DOS.

What does the previous explaination tell us?  DOS absolutely must have one
buffer available to process partial read/write requests.  (This one buffer
is actually allocated by IBMDOS initialization code so IBMBIO can process
CONFIG.SYS).  Since DOS also uses buffers for FAT and directory block reads,
we probably want to have a minimum of one block available for each of these
blocks to avoid disk thrashing.

In reality you probably want several more buffers.  FAT size,  directory
size,  and usage contribute to optimum number of buffers.  Because the
buffer cache is searched linearly,  allocating a large number of buffers
eventually hurts you.  Note that the DOS buffer cache contributes nothing
to program i/o performance unless you are processing a lot of partial blocks.

How does a real cache help?  It can improve performance substantially.
Using a better seach (ie hash)hcan speed up directory/fat access.  If you
run applications that repeatedly access the same disk blocks,  a real cache
program would eliminate some disk access.  If you really like living
dangerously,  a cache could defer writing some disk blocks (not recommended
for directory and fat blocks).  A cache program can also do intelligent read
ahead (eg read a cluster at a time).  The disk cache need nt be in the
lower 640K.

To summarize certain applications can benefit greatly from a cache.  Unless
one really wants to muck around with DOS internals,  one cannot prevent DOS
from searching its own cache for directory, fat, and partial read/write
requestsUsing a cache will effect the optimal value of buffers=;  you
probably want a fairly small number of DOS buffers.


Walt Dixon     {ARPA:      dixon@ge-crd.com    }  }
               {USMAIL:    ge crd                 }
               {           po box 8              }
               {           schenectady, ny 12345 }
               {PHONE:     518-387-5798          }

standard disclaimers