Browse Prior Art Database

Creating Reference History for Optical Via Dismount Delay

IP.com Disclosure Number: IPCOM000121945D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 5 page(s) / 208K

Publishing Venue

IBM

Related People

Loen, LW: AUTHOR [+2]

Abstract

Optical subsystems are analogous to a paging system in many respects. The media (i.e., the platters) function as analogs of "virtual" pages. The optical drives function as analogs of "real" page frames. However, the analogy breaks down rapidly, in practice, at this point.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

Creating Reference History for Optical Via Dismount Delay

      Optical subsystems are analogous to a paging system in
many respects.  The media (i.e., the platters) function as analogs of
"virtual" pages.  The optical drives function as analogs of "real"
page frames.  However, the analogy breaks down rapidly, in practice,
at this point.

      The key problem is that to apply any sort of "page replacement
algorithm", it is necessary to collect predictive information about
the use of the current media in the drives and of those which are
waiting for the drives.

      Unlike a paging system, an optical subsystem may collect an
almost arbitrary amount of information.  There is no ambiguity from
hardware "reference bit" tracking. Precise reference information is
available as far back into the past as desired, permitting an exact,
idealized Least Recently Used or other related algorithm to be
employed. (For instance, "classes" of function, in an order favored
by the customer could individually employ Least Recently Used or even
FIFO if this is deemed better in a given case).

      Much of this obvious advantage is negated by the fact that a
straightforward implementation will quickly founder on the inability
to predict future operations in a granular manner.  While the past is
perfectly known, a simple, naive LRU kind of approach (even if the
notion of "classes" of function is introduced) will quickly make bad
choices, because, at typical application speeds, a new request will
come in for the same platter perhaps 2 to 5 seconds after the old.
This is short in terms of arm movement time (which is about 15 to 20
seconds for a typical device), but long in terms of an LRU decision
method running at processor speeds.

      The solution will be described after a brief definition of the
principal queues used to manage the I/O request (see the figure).
"Request" hereafter means an "I/O Request".
-  Incoming Queue.  Holds any new work requests for the Optical
Subsystem.  Also holds (in this embodiment) responses from the
devices.  There is one Incoming Queue per Optical Subsystem.
-  Master Queue.  Holds any request which needs an unmounted media
and has no requirement for immediate execution.  There is one Master
Queue per Optical Subsystem.
-  Special Drive Queue.  Holds requests which must execute as soon as
possible on a particular drive.  If that work mounts or dismounts a
media, other work waiting on the Drive queue may have to be moved
back to the Master Queue.  There is one Special Drive Queue per
Optical Drive in the subsystem.
-  Drive Queue.  Normal work currently assigned to a given drive.
This implies that the media is already mounted and is waiting for
work against that drive for that media.  Thus, all work on this queue
requires the same media.  There is one Drive Queue per Optical Drive
in the subsystem.
-  "To I/O Device".  In some embodiments, it may be a queue per
device; in this description...