Path: utzoo!attcan!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: An FS idea - good or bad?
Message-ID: <638@philica.ica.philips.nl>
Date: 25 Jul 90 14:25:31 GMT
References: <1766@ccadfa.adfa.oz.au>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 31

In article <1766@ccadfa.adfa.oz.au> wkt@rodos2.cs.adfa.oz.au (Warren Toomey) writes:
>Assume the FS doesn't block on a read/write to a device task, but just
>sends the request to the task, marks the block in the cache as `in transit',
>saves the user's request info somewhere [as extra fields in the cache?],
>and goes back to the main loop.
>
>Eventually, the FS will receive a reply from a device task, and then it
>can reply to the requesting process that has been blocked all the time.
>At this point, it can note that the device task is now `waiting for a
>request'.

Not messages, the FS sends to tasks, are sent on behalf of user processes.
The FS has also to read/write inode and zone bit-maps, the inode table,
directories and (double) indirect blocks. It would be nice if the FS would
only block on these `administration blocks', and not on real data blocks.
But that way, when you issue a copy of many files to floppy, the FS can
slow down the system just as easilly.

What state should be stored when the FS does a request for an
administration block? Where should it be stored? How do you return to
an execution thread of the FS? longjmp?

A stated FS asks for a lot of rewriting. I think that most people are
waiting for someone to post an easy and short solution, which can be
patched quickly. I think that those people can wait long. A multi-threaded
FS, with one FS code + data segment, but several (say 5) FS process entries
in the kernel tables (proc[]), will not be the most beautiful solution
but still an effective solution with not that many changes.

Adrie Koolen (adrie@ica.philips.nl)
Philips Innovation Centre Aachen