Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!uw-beaver!cornell!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.sys.atari.st
Subject: Re: TurboDos observations
Message-ID: <4402@batcomputer.tn.cornell.edu>
Date: 13 Apr 88 14:00:34 GMT
References: <207@forty2.UUCP>
Reply-To: braner@tcgould.tn.cornell.edu (braner)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 26
Summary: It's more than a cache

In article <207@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes:
>I was able to play around a bit with the GEMDOS 'Ersatz' from Atari France:
>...
>              GEMDOS      TurboDOS
>  LaTeX  |  9 min 40 s |  9 min 40 s | Comment: tmp files on Ramdisk
> 50 files|  3 min  6 s |  0 min 42 s |

- seems that TurboDOS is more than a cache: creating new files on an
almost-full HD is slow since GEMDOS has to analyse the FAT to find empty
space, and it does so very inefficiently.  No disk cache (of the kind
that just keeps _sectors_ in RAM) can fix that, Turbodos must intercept
the GEMDOS functions that operate at the _file_ level.  The Latex
test did not speed up since it was mostly calculating rather than
I/O, and the tmp files were created on a (small?) RAMdisk (small FAT
to analyse).  It _is_ true that GEMDOS could benefit from caching of
(sub)directory sectors, something that it does not do much of.  It
could also use hashing of files found in directory trees, for faster
finding of them next time (i.e., the second time you access the file,
say a compiler library file or a utility program, via a long PATH
variable).  This could be done inside a shell, too.

Any chance TurboDOS could be posted on Usenet or put up for FTP?

- Moshe Braner

PS: PENICILIN, since it is supposed to suppress a VIRUS, should have
been named INTERFERON  :-)