Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!decvax!virgin!zinn!mem
From: mem@zinn.MV.COM (Mark E. Mallett)
Newsgroups: comp.sys.atari.st
Subject: Re: Turbodos and the ideal disk cache
Message-ID: <307@zinn.MV.COM>
Date: 3 May 88 04:26:12 GMT
References: <8804192256.AA06919@orville.nas.nasa.gov> <1042@atari.UUCP>
Organization: Zinn Computer Co., Litchfield NH
Lines: 46
Summary: FAT updates

In article <1042@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes:
< From article <8804192256.AA06919@orville.nas.nasa.gov>, 
< by rowley@orville.nas.nasa.GOV (Karl Rowley):
< 
< > How much a delayed write cache would really buy on the ST is a good 
< > question.  In a lot of cases it may not buy much over a write-through 
< > cache.
< 
< If you could save the writes to the FAT and directory until all the
< files are copied, you would save quite a bit.  Remember that the FAT and
< root directory are at the beginning of the disk, so the head is seeking
< back and forth all this time.  With cached reads AND DELAYED WRITES you
< save the seek time as well. 
< 
< Unfortunately, you don't know when the whole operation is complete. 
< That's why it's dangerous.  It gets much worse with removable media, of
< course. 

well, there's another answer somewhere between write-through and write-back
cache, and that is the idea of having some control over when updates are
posted to disk.  This works especially well when controlled judiciously.
four or five years ago, i had to do an MS-DOS filesystem implementation.
the way I did it was that all i/o went through a buffer cache.  i arranged
to be able to specify how the buffers were to be released to the cache, in
one of three ways: 1: buffer was unmodified; 2: mark buffer as modified; 3:
write the buffer immediately.  another function would write all "dirty"
buffers.  incremental file allocation was done such that the FATs were
released with the second mode.  With this scheme (and a little other
bookkeeping), it was possible to selectively sweep the cache (thereby
updating the cache) only at major checkpoints, such as the final update to
the directory entry.  i used variations on this scheme in later systems, as
well.

Another part of an answer (which I have combined with the above) is to
do preallocation.  Here, whenever a file is about to undergo automatic
extension, the extension can be done in an amount greater than a single
cluster (under control of some fixed or variable parameter).  this works
especially well when contiguous-best-try is used.  at file close time
(again, along with some bookkeeping), the extra clusters can be released.
must less wear and tear on the FAT, better data organization.

-mm-
-- 
Mark E. Mallett  PO Box 4188/ Manchester NH/ 03103 
Bus. Phone: 603 645 5069    Home: 603 424 8129
uucp: mem@zinn.MV.COM  (...decvax!elrond!zinn!mem   or   ...sii!zinn!mem)
BIX: mmallett