Path: utzoo!attcan!uunet!samsung!rex!uflorida!palmetto.cis.ufl.edu!bp
From: bp@palmetto.cis.ufl.edu (Brian Pane)
Newsgroups: comp.os.minix
Subject: Re: An FS idea - good or bad?
Message-ID: <23944@uflorida.cis.ufl.EDU>
Date: 24 Jul 90 16:13:43 GMT
References: <1766@ccadfa.adfa.oz.au>
Sender: news@uflorida.cis.ufl.EDU
Reply-To: bp@beach.cis.ufl.edu (Brian Pane)
Organization: UF CIS Department
Lines: 28

In article <1766@ccadfa.adfa.oz.au> wkt@rodos2.cs.adfa.oz.au (Warren Toomey) writes:
>I have had some ideas about alleviating the FS's single-threadedness, so
>
[...]
>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.
>
>Can anybody suggest ways around this problem?
How about implementing the file system as two processes: one which
accepts requests from user processes (but blocks when there is no room in
the queue) and another that sends requests to the device driver (and
wakes up the first when the full queue becomes empty)?  
Or, you might be able to do this with only one process, which accepts
messages from anywhere if there is room for more user requests in the
queue but only from device drivers if there isn't.

-Brian Pane

-------------------------------------------------------------------------
Brian Pane	University of Florida Department of Computer Science
bp@beach.cis.ufl.edu		Class of 1991
"If you can keep your expectations       |#ifdef OFFENDED_ANYONE
 tiny, you'll get through life           |#  include "disclaimer.h"
 without being so whiny" - Matt Groening |#endif
-------------------------------------------------------------------------