Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!purdue!umd5!ames!hao!noao!ut-sally!mothra!bryan
From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDos don't thrash no more!
Message-ID: <10385@ut-sally.UUCP>
Date: 18 Feb 88 06:17:59 GMT
References: <8504@sunybcs.UUCP> <3247@watcgl.waterloo.edu>
Sender: news@ut-sally.UUCP
Reply-To: bryan@mothra.cs.utexas.edu
Organization: Spam Detection & Removal Squad, Austin, TX
Lines: 50
Spam-Content: Negligible

In article <3247@watcgl.waterloo.edu> bmacintyre@watsol.waterloo.edu (Blair MacIntyre) writes:
=-In article <8504@sunybcs.UUCP> ugpete@sunybcs.UUCP (Peter Theobald) writes:
=-><Line Eater Motel. Line eaters check in.... but they don't check out!>
=->
=->AmigaDos should sort disk requests by track. This way if three processes
=->ask for three different files scattered all over the disk, instead of
=->jumping around like a Tasmianian Devil getting blocks from first one
=->file, then the other then back to the first, AmigaDos would load in the
=->blocks on the tracks currently nearest the read head. Then it would move
=->the head to the next track with requested data on it, etc... It could
=->continue this process sweeping the head back and forth across the disk
=->picking up what is needed, wasting the least amount of time.
=->	This would eliminate thrashing, and would speed up disk accesses
=->to boot! I think this is similar to what a clone of Peter da Silva meant by
=->single-threading loadSegs.
=->	How major a change in AmigaDog is this?
=-
=-Unfortunately, this scheme could cause starvation ( ie. a certain read 
=-request doesn't get serviced because it's on the opposite end of the
=-disk ) 

	Have we forgotten our disk-scheduling algorithms from undergraduate
OS class, hmm? :-) :-)  To prevent starvation and still get near-optimal
performance, one uses SCAN, aka the elevator algorithm.  Here, the head travels
in one direction all the time, filling the next closest request, until it gets
to the innermost (outermost) track, or until there are no more requests in that
direction.  Then it does the same thing in the other direction--just like an 
elevator.  If you don't want to favor requests that come in just before the
head turns around in their direction over those that "just missed the
elevator" a long time ago, then you use CSCAN, in which the head seeks quickly
to one end of the disk after each traversal, so that passes are always in only
one direction.  Think of the disk as a torus, or of an elevator that wraps
around from the basement to the roof.
	My guess is though, that (as always), access to the root block would
get in the way of this algorithm, and the performance wouldn't improve much.
The mainframe solution to this is to keep directory and data information on
separate drives, but I don't think that AmigaDoze (can you say 'zzzz', little
cloud?) has that luxury, especially with floppies.

=-not to mention problems with syncronizing reads and writes if you
=-start using a selection order other than first-come-first-serve.

	Huh?  Could you explain this?
 ______________________________________________________________________________
/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|
_No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___
|____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___|
___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan
|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|