Browse Prior Art Database

Managing Physical Drive Data Bandwidth in Volume Stacking Subsystem

IP.com Disclosure Number: IPCOM000117542D
Original Publication Date: 1996-Mar-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 141K

Publishing Venue

IBM

Related People

Kishi, GT: AUTHOR

Abstract

Disclosed is a method for managing limited data transfer resources to competing drives in a volume stacking system that reduces wait time.

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

Managing Physical Drive Data Bandwidth in Volume Stacking Subsystem

      Disclosed is a method for managing limited data transfer
resources to competing drives in a volume stacking system that
reduces wait time.

      An automated volume stacking subsystem consists of a number of
drives that read data (typically on cartridges), a buffer (typically
DASD), at least one automated cartridge accessor, and at least one
connection to a host computer.  When the host computer requests data
to be read from data volumes that are not currently resident in the
buffer, a cartridge must be fetched by the accessor and placed in a
drive for reading.

      In order to minimize contention, a number of drives are
provided on the subsystem to read cartridges.  The data transfer
capacity of the subsystem controller is assumed to be less than the
total simultaneous data transfer capability of all the drives on the
subsystem.

      This disclosure describes an algorithm that will allow such a
volume stacking subsystem to optimize its cartridge read performance
for either minimum average wait time, or minimum peak read time.
Data from a cartridge being read is transferred into the buffer, at
which time the host can access it.

      Because the volume stacking subsystem by its nature creates
stacked cartridges, and is a closed system, it has knowledge about
the volumes that a normal cartridge mount does not have.  The volume
stacking subsystem controller knows how big the volume is, how much
data has already been transferred into its buffer, and where it is
located on the cartridge.  The subsystem also knows how long each
mount request has been waiting to be serviced.

      Two different cases are disclosed.  In the first case, n drives
compete for a data transfer capacity of m (m<n).  In the second case,
n drives compete for a data transfer capacity of m, but n = the
maximum number of drives available, and at least one cartridge is
waiting for a drive.

      In either case, the algorithm establishes which "m" drives
should be allowed to transfer data.  Those drives not allowed to
transfer data must wait until one of the transferring drives
finishes, at which time this calculation is re-computed.  It is also
recomputed if any new drive is loaded and ready to transfer data, or
if no cartridge was waiting, but one is waiting now (Case 1 to Case 2
transition).

      For this disclosure, "i" will represent the index value for any
data representing a drive (where "i" ranges from 1 to n).
  o  Case 1
       In this case n drives compete for a data transfer capacity
      of m, with n <= the maximum number of drives available

          The time that would be required for each of the n drives
to     transfer its data to the volume stacking subsystem buffer,
T(i), assuming it had the data transfer resources can be calculated
by the following formula.
  T(i) = (volume_size(i) - data_already_transferred(...