Browse Prior Art Database

Redundant Arrays of Independent Disks Implementation in Library within a Library to Enhance Performance

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

Publishing Venue

IBM

Related People

Day III, K: AUTHOR [+3]

Abstract

Multiple requirements must be satisfied for the use of storage libraries in the future. It is desirable to have very high performance, along with high availability, low cost, and the ability to tune for improved performance.

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

Redundant Arrays of Independent Disks Implementation in Library within
a Library to Enhance Performance

      Multiple requirements must be satisfied for the use of storage
libraries in the future.  It is desirable to have very high
performance, along with high availability, low cost, and the ability
to tune for improved performance.

      Redundant Arrays of Independent Libraries (RAIL) based on a
number of small libraries can solve the high availability and low
cost requirements---however, it is exposed to performance bottlenecks
when the disks in one library have a queue of read and/or write
requests.  This is exacerbated when the library has a single drive,
as all requests must be satisfied sequentially.  In the extreme, all
but one library may be completely idle, while requests to one library
continue to grow so response time continues to degrade.

      The concept of libraries within a library can be utilized to
tune for performance.  The picker of the large library could move
disks among the stacks of the small libraries.  However, unless done
as outlined below, this would compromise the implementation of RAIL.
The innovative portion of this disclosure is the implementation which
allows use of the large library picker to manage queues in the small
libraries while preserving RAIL characteristics.

      The concept of RAIL is to use several independent small
libraries, and to spread data across cartridges within the libraries
in such a way that data can be reconstructed if any one failure
occurs in a library or cartridge.  (Of course, the controller must be
protected against failure as well, possibly with a redundant
controller or similar).  This is analogous to RAID implementations,
except that the data may be stored in a library slot rather than
actively accessible by the drive.

      Fig. 1 shows the simplest configuration where 5 independent
libraries are utilized to implement a RAIL 4 scheme analogous to RAID
4.
  SLIB(1)       SLIB(2)       SLIB(3)       SLIB(4)       SLIB(5)
    a1            a2            a3            a4            a5
    b1            b2            b3            b4            b5
    c1            c2            c3            c4            c5
    d1            d2            d3            d4            d5
    e1            e2            e3            e4            e5
  DRV(1)        DRV(2)        DRV(3)        DRV(4)        DRV(5)
  Figure 1.  RAIL implementation using M=5 Disks.  N=5 Libraries.

The difficulty with this implementation is that bottlenecks may
occur.  For example, if data is needed from the a5, b5 and c5
cartridges, then a queue develops.  Moving a cartridge from the 5th
library...