Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!aplcen!samsung!munnari.oz.au!basser!metro!natmlab.dap.csiro.au!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: filesystem cache blocks
Message-ID: <2350@ditsyda.oz>
Date: 11 Dec 89 09:42:02 GMT
References: <9374@microsoft.UUCP>
Reply-To: evans@ditsyda.oz (Bruce Evans)
Organization: CSIRO DIT Sydney, Australia
Lines: 38

In article <9374@microsoft.UUCP> stevesc@microsoft.UUCP (Steve Schonberger) writes:
>Is it possible to allow the filesystem process to use all (or most of)
>free memory as disk cache?  (If it does that already, excuse the dumb

Everything is possible :-). This is a good idea.

>Are there any obvious problems with this other than the need for
>someone to code it?  Any more subtle problems?  Has this been

It is a !@#@$# to code in C in small model without far pointers. The file
system code depends on buffers being accessible with normal pointers. Much
copying would be required. Direct copying by the file system task is taboo,
and using a system call to copy takes 3 times as long. So a 3-layer cache
(FS memory, "extended" memory, and disk) is probably required.

The interaction with the memory manager will be messy. When space is wanted
for a new process, FS may have to truncate the cache and rearrange it to
get rid of holes. I think considerable copying to do the rearrangement would
be worthwhile. Even now, it is easy to waste 100K due to fragmentation.

The cache ought to compete with the RAM disk for memory too. The RAM disk
should have some fixed size smaller than the memory size. Blocks on it not
in files should not be be allocated. I'm not sure what the raw /dev/ram
should do with non-allocated blocks.

I have implemented about half these things on a 2 MHz 6809 system with 560K
RAM and an MMU. The RAM disk competed with programs for memory. The cache
size was fixed but could be varied using a system call. I/O was 2 to 4 times
faster than Minix's on a 5MHz PC, and effectively more since the system
wasn't disk bound (there was useful stuff in ROM and the C compiler and
support were locked into RAM).

I now have 32-bit mode working on a 386 so there is no 64K limit on pointers
in FS. I use a 320K cache. Currently, FS is not allowed to access memory
outside its data segment, and has no way to allocate such memory. The MMU
will make many things easier at the cost of portability.
-- 
Bruce Evans		evans@ditsyda.oz.au