Path: utzoo!attcan!uunet!snorkelwacker!think!samsung!cs.utexas.edu!mailrus!ncar!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: comp.unix.aix
Subject: Re: SCSI hiding geometry
Message-ID: <18494@boulder.Colorado.EDU>
Date: 16 Mar 90 19:37:08 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <132788@sun.Eng.Sun.COM>
	<1990Mar11.045128.17732@ico.isc.com> <106@alruna.UUCP>
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Followup-To: comp.unix.aix
Organization: University of Colorado at Boulder
Lines: 18
In-reply-to: mats@alruna.UUCP's message of 13 Mar 90 23:01:57 GMT

>>>>> On 13 Mar 90 23:01:57 GMT, mats@alruna.UUCP (Mats Wichmann) said:
MW> doing something.   So say you want to build a controller that takes a
MW> request, seeks to the right track, and starts pulling data into the buffer
MW> right there, up until the right sector spins around.  That doesn't cost you
MW> anything more - otherwise you just wait - and it might gain something.
MW> Then, just for kicks, if there is no other pending request, or if another
MW> request in the queue is in the same area, you can go on and read the rest
MW> of the track.  If there is something more important to do, you go do that
MW> right away (we built such controllers at Dual Systems long ago (long ago?
MW> six years?) - where, incidentally, Matt Jacob also worked).
--

If I understand you correctly, than some SCSI controllers already do
this.  E.g., the Wren V/VI/VII all have an on-controller read-ahead
cache that reads up to 32K. Using this, and the Ultrix filesystem, I
can pull >1000Kb/s from my Wren V. Admittedly, that's not stunning
from a mainframe point of view, but it's not bad for a fetch-on-demand
system.