Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!texbell!uudell!loft386!dsuvax!ghelmer
From: ghelmer@dsuvax.uucp (Guy Helmer)
Newsgroups: comp.os.minix
Subject: Re: An FS idea - good or bad?
Message-ID: <1990Jul25.133131.3289@dsuvax.uucp>
Date: 25 Jul 90 13:31:31 GMT
References: <1766@ccadfa.adfa.oz.au>
Organization: Dakota State University
Lines: 48

In <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.

Sounds like an interesting idea.

>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'.

I assume there will be some mechanism for a "timeout" if a device doesn't
reply.

>The problem is of course, what should the FS do if it needs to send a request
>to a device task that _isn't_ `waiting for a request'? If it does so, it will
>block.

A queue of even two entries would make much better use of machine resources
than the current FS, especially if processes are generating requests
for multiple devices.

>One alternative is to store a queue of outgoing read/write requests, and
>this queue can even be reordered to improve efficiency at the device level.
>However, this queue is probably static. What should be done if the queue
>of device requests fills up, and no device tasks have replied yet?
>Throwing away user requests is not a good idea.

If the queue fills up, make FS block and wait for a device to either
respond or timeout.  I'll bet the user will notice if it happens frequently,
and he/she can tweak the size of the queue.

Another option could be to throw away the request and return an
error.  The user would notice that real fast :-).

>Can anybody suggest ways around this problem? Or is it just a bad idea?!

>    Warren Toomey VK2XWT, chocolated.
> Deep in the bowels of ADFA Comp Science.
>        `Shut up Nick - jem'

This shouldn't require too much hacking to implement.  Any takers?
-- 
Guy Helmer                                 ...!bigtex!loft386!dsuvax!ghelmer
DSU Computing Services    dsuvax!ghelmer@cs.utexas.edu,  helmer@sdnet.bitnet
           Small is beautiful, but looks aren't everything...