Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.arch
Subject: Re: Incremental sync()s and using disk idle time
Summary: ordering has been done
Message-ID: <91814@sgi.sgi.com>
Date: 16 Mar 91 22:33:49 GMT
References: <1991Mar8.142031.9098@bellcore.bellcore.com> <3268@crdos1.crd.ge.COM>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 29

In article <3268@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>  ....
>   If you need A to be written before B you would have to do a SYNC after
> A, true. If you were able to promise that writes from a single process
> would be done in order, without SYNC that might be all you need. While I
> can visualize a simple way to do this, I can't claim to have seen it
> implemneted in an interface to a controller.
> ...


Years ago, at a start-up, I led the development at of a small, multiuser,
multiprocessor system.  We built a radically smart disk controller--it had
a whole 8085.  The controller patrolled a linked list of requests, with each
request containing the obvious unit number, word count, disk block number
(not sector/head/track--unsual in that era), completion bit and status,
etc.  Each request also contained an optionally non-null pointer to
another, "predecessor" request.  The controller was allowed to service
requests in any order it thought good, subject only to the prior completion
of the precessor.

It took lots of energy to convince the people working on the controller
that something more than a fixed array of word-count/sector/head/track was
possible, let alone a good idea.  We sold a few of the controllers to other
companies, but no one else ever seemed to think the predecessor idea was
worthwhile.  The company is long dead and forgotten.  Sigh--the universe is
unfair.


Vernon Schryver,   vjs@sgi.com