Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!nrl-cmf!ames!oliveb!amiga!cbmvax!steveb
From: steveb@cbmvax.UUCP (Steve Beats)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDos don't thrash no more!
Message-ID: <3338@cbmvax.UUCP>
Date: 18 Feb 88 14:41:07 GMT
References: <8504@sunybcs.UUCP> <3247@watcgl.waterloo.edu> <8626@sunybcs.UUCP>
Reply-To: steveb@cbmvax.UUCP (Steve Beats)
Organization: Commodore Technology, West Chester, PA
Lines: 50

In article <8626@sunybcs.UUCP> ugpete@joey.UUCP (Peter Theobald) writes:
>< This sure looks like line-eater food to me! >
>
>
>In article <3247@watcgl.waterloo.edu> bmacintyre@watsol.waterloo.edu (Blair MacIntyre) writes:
>>In article <8504@sunybcs.UUCP> ugpete@sunybcs.UUCP (Peter Theobald) writes:
>>>
>>>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.
>
>>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 ) not to mention problems with syncronizing reads and writes if you
>>start using a selection order other than first-come-first-serve.
>
>>Blair
>
>No, that wouldn't cause starvation. The disk would service every request on
>cylinders 0 - 79 in that order, and then service every request on tracks
>79 - 0 in that order (or however # of cylinders there are). This process
>would repeat until there are no more requests. A request cannot be starved
>because it must at most wait for the head to travel to one extreme and back.
>
>	-Pete
>
>Peter Theobald				SUNY/Buffalo Computer Science

No, that scheme wouldn't work either.  I tried putting access sorting into
FFS and backed out of it again because it didn't help.  FFS solves thrashing
problems by doing large, consecutive reads as large, consecutive reads and
doesn't split them into separate block requests to the disk driver.  If
you had two processes accessing oldFS, the requests would come in to the
driver as single block transfers from opposite ends of the disk anyway.
You would automatically be servicing requests in 0-79/79-0 order.

Let me take this opportunity to suggest that ALL file read and write requests
be done in the largest increments possible.  This ain't going to gain you
much under the current FS but you're going to be ready to take advantage
of FFS when it hits the streets.  A second caveat, try not to do requests
from odd addresses!  Although both OldFS and FFS support this, you are going
to get the MOST inefficient response from both systems if you do it.  Cache
buffers are used when the requested transfer address is odd and since these
buffers are allocated on even boundaries, it is nescessary to BYTE COPY all
the data to or from the user buffer.  Now I'm not saying that everyone should
start using half meg buffers, but keep 'em reasonable, say around 16K at least.

	Steve