Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!cica!iuvax!rutgers!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f
From: gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.os.minix
Subject: Re: Why does everything say "limit of 3 users"?
Message-ID: <1990Oct9.004554.18388@murdoch.acc.Virginia.EDU>
Date: 9 Oct 90 00:45:54 GMT
References: <32572@nigel.ee.udel.edu>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 71

In article <32572@nigel.ee.udel.edu> waltje%minixug.uucp@plains.nodak.edu (Fred van Kempen) writes:

>So, for many users, you must:
>
>1.  Have a fast CPU (>= 16MHz 286 or 386)
>2.  Have plenty of memory (>= 4Mb)
>3.  Have a (some) fast and large disk(s) (>= 40Mb, <= 28ms)
>4.  A lot of serial port boards (COM1: - COM4) and a MUX (AST FourPort)
>5.  Have the Virtual Console stuff from Gordon Irlam installed
>6.  Add Message Queueing and/or Multi-Threading to the operating system
>
>Well, items 1-5 are fully supported by NLMUG Advanced MINIX; item 6 is
>"yet to be done".  I think we should have another look at the message
>queueing stuff from Larry, and implement it in 1.5 FS.
>After that, we could start thinking about adding multiple threads per
>process to the kernel (Andy? How did you do it in Amoeba?) ...

Actually, Amoeba does the filesystem in an entirely different manner
from normal Unix or Minix -- it takes "small is beautiful" to mean
"RAM is cheap but the code should still be small." The FS is not
multithreaded, but it's fast because it burns RAM to make sure it
rarely waits. When a file is opened, for example, the entire file is
loaded into the cache and remains there.

If you consider why the Minix FS waits, this makes sense. When Minix
is bringing in a directory block from the disk for one process,
another process can't get at blocks which are cached and readily
available. Given that most files are typically read from beginning to
end, it makes sense to read them all at once, as long as you have plenty
of RAM.

So, one could design a really high-performance but RAM-hungry Minix
FS, you can follow Amoeba's lead and do it like this:

1) Add a file-system-switch, so that all FS does is call tasks which
do the real work. This keeps FS small and beautiful while allowing
the student/experimenter to play with new filesystems.

2) Write a FS that keeps ALL the directory information in RAM, and
stores files as contiguous segments on disk. Store changes to the file
structure in a log on the disk. When files are opened, read them into
RAM and leave them there until they are closed, whereupon you write
them back to disk all at once if they're dirty.

This FS rarely waits. Any inode information is available without
reading the disk. Reading from an already-open file or writing to a
file always uses memory buffers. When an uncached file is opened or a
cached file is flushed, it goes into a queue of things to be done.
Changes to the directory structure written into the log are combined
-- the more things to be done, the more changes we can write to the
log at once. And so on. Of course, the details of who calls whom are
nasty, but at least this FS can be a single-threaded finite-state
machine, and hence easy to understand.

[ While we're at it, I should note that you can compress the inode
information in memory somewhat, and we get /tmp for free by creating
cached states like "closed dirty file, write to disk should you be
forced to remove this file from RAM to load other files", etc. ]

3) Write other kinds of FS types, such as a networked FS using the
Amoeba networking protocol. If you're willing to accept a stated
protocol, it should be relatively simple.

The code for #2 could easily turn out to be smaller than the code for
the current FS, and it will certainly be faster. The question is how
much RAM it will munch.



--
"Restraint, hell. I'm just too fucking busy." -- Bill Wisner