Browse Prior Art Database

Non-Volatile Cache Storage Allocation Algorithm

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

Publishing Venue

IBM

Related People

Bello, KA: AUTHOR [+6]

Abstract

Disclosed is a cache allocation algorithm which removes present Non-Volatile Storage size constraints from cache storage control subsystems (e.g., IBM* 3990) and so allows greater performance than is presently attainable. This algorithm allows the modified data area of the non-volatile cache to expand and contract in response to fluctuations in the frequency of DASD Fast Write channel programs, constrained only by the total cache size.

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

Non-Volatile Cache Storage Allocation Algorithm

      Disclosed is a cache allocation algorithm which removes present
Non-Volatile Storage  size constraints from cache storage control
subsystems (e.g., IBM* 3990) and so allows greater performance than
is presently attainable.  This algorithm allows the modified data
area of the non-volatile  cache to expand and contract in response to
fluctuations in the frequency of DASD Fast Write  channel programs,
constrained only by the total cache size.

      Cache Nodes - The configuration consists of two or more cache
nodes Each cache node  has its own microprocessor, battery backed-up
(non-volatile) cache and power supply.  In the case of a power outage
at the storage control, the modified data from all cache nodes is
dumped to DASD.

      Primary and Journal Cache Storage  - Cache Storage  at any
cache node  can be used as storage for both track images and for
modified records.  Track image storage is named Primary storage, and
modified record storage is named Journal storage.  There is no fixed
partitions between Primary and Journal storage, as will be discussed
in the Allocation section.

      The storage control attempts to distribute the amount of data
allocated over the several cache nodes, in a balanced manner.  When
the subsystem powers up, the SEASTAR  control code chooses a Primary
and Journal cache node  for each CKD track in the subsystem, ensuring
that Primary and Journal cache data will be allocated to separate
failure boundaries.

      Write data, e.g., an Update Write, modifies a record or records
in a track image, and is written to Journal storage in a separate
cache node.  Thus, there are two copies of the modified data, and
each copy resides in a separate cache node, on a separate failure
boundary.

Cache Allocation
  o  A cache node  has its cache partitioned into different size
      segments.  Segments of the same size are chained together to
form
      a pool of segments of a given size.  E.g., segment sizes could
be
      256 bytes, 1 KB, 2KB, 4KB, 8KB, etc., up to a maximum number of
      pools.
  o  Record fields are allocated to available best fitting segment.
      Record fields that are stored in segments are the Key field (if
      it exists), and the Data field (the Count field, which is a
fixed
      size, is stored in the record's Track Descriptor Vector
element,
      which is described in a subsequent paragraph).  There are no
      contiguity restrictions on the allocation of the fields for an
      individual record.  Not more than one field can be stored in a
      cache segment, although a field can consume multiple segments.
       This method of cache allocation gives great flexibility at
      the cost of possibly some wasted space in individual segments.
  o  When a cache miss occurs, the following happens:
     1.  If the accessed track...