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.202500.4119@dsuvax.uucp>
Date: 25 Jul 90 20:25:00 GMT
References: <1766@ccadfa.adfa.oz.au> <1990Jul25.133131.3289@dsuvax.uucp>
Organization: Dakota State University
Lines: 24

In <1990Jul25.133131.3289@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:

>In <1766@ccadfa.adfa.oz.au> wkt@rodos2.cs.adfa.oz.au (Warren Toomey) writes:
>> [Non-blocking FS suggestion...]

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

I thought of something while I was on the road today --- if the queue size
is set to NR_PROCS (number of user processes allowed, I believe), every
user process in the system could generate I/O requests and FS would never
have to block while waiting for an unused queue slot.

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