Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ptsfa!ihnp4!inuxc!inuxf!matt
From: matt@inuxf.UUCP
Newsgroups: comp.os.minix
Subject: Re: Disk Scheduling (& note to Dr T.)
Message-ID: <239@inuxf.UUCP>
Date: Tue, 3-Mar-87 09:22:04 EST
Article-I.D.: inuxf.239
Posted: Tue Mar  3 09:22:04 1987
Date-Received: Thu, 5-Mar-87 21:35:44 EST
References: <236@inuxf.UUCP> <108@illusion.UUCP>
Organization: AT&T Consumer Products, Indianapolis
Lines: 46

> In article <236@inuxf.UUCP> matt@inuxf.UUCP (Matt Verner) writes:
> >I am planning on adding true disk scheduling to MINIX as part of an over-all
> >study of operating system efficiencies.  The existing method in MINIX is a 
> >First-come-first-served pipeline with no disk i/o queue.  I would like to
> >through out a straw man proposal for a method so that the alert among you
> >folks can poke holes, make suggestions, etc.
> ...
> >	2) Create a new procedure, say floppy_sched(), that examines the
> >queued requestes for the shortest seek time request and issues a do_rdwt()
> >for that request.
> >	3) floppy_sched() then will prepare a return message for the proper
> >process and send() a reply to that process.
> >	4) floppy_sched() re-examines the queue and the process continues.
> 
> I would think that there is a potential performance problem here... 
> 
> Unix implements a so-called `elevator algorithm' which attempts to order
> requests so that the closest block IN THE CURRENT MOVEMENT DIRECTION is
> serviced next, if there are none, then the direction is reversed.  This
> tends to sweep the head across the disk more than is absolutely necessary,
> and so it is sub-optimal in a global sense, but it does insure that all
> requests will be serviced without undue delay.
> 
> marcus hall
> ..!ihnp4!illusion!marcus

I am well aware of the shortcomings of the Shortest-Seek-First algorithm.  I
am also well aware of other algorithms ( SCAN, LOOK, C-SCAN, C-LOOK, FCFS, etc)
and their respective advantages/disadvantages.  What I am truly looking for is 
a discussion on how to add the queueing mechanism to the floppy (and/or harddsk)
so that true scheduling can occur.  I appreciate the mail and this posting that
point out SSF shortcomings but that is not truly the issue at hand.  In short,
How does one go about adding a queue and a seperate task that will service
that queue independant of other processes.  With the existing message passing
scheme the driver must recieve() and then send() before going into another
recieve().  This means the driver cannot recieve() and queue, recieve() and
queue, etc.  Or am I missing something entirely?

 Matt Verner   				UUCP:  ...ihnp4!inuxc!matt
 AT&T Graphics Software Labs		AT&T:  (317) 844-4364
 Indianapolis,  IN

           "The whole point of this sentence is to clearly
             explain the point this sentence is making."

*** REPLACE THIS LINE WITH YOUR MESSAGE ***