Browse Prior Art Database

Auxiliary Storage Pool Regression Detection

IP.com Disclosure Number: IPCOM000028864D
Original Publication Date: 2004-Jun-04
Included in the Prior Art Database: 2004-Jun-04
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Abstract

When facilities for making copies of collections of disks exist, it may be that a copy will be brought online that is not the copy the system most recently had online. This article describes a mechanism for detecting a back-level copy so that either the user or the operating system can take the actions it considers appropriate.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 2

Auxiliary Storage Pool Regression Detection

An auxiliary storage pool (ASP) is a collection of disk drives that together contain a logically complete network of software objects. An ASP can contain a relational database and one or more POSIX files system. If, within an iSeries cluster, storage management detects more than one instance of an ASP, it does not know which is the current copy and it deletes all copies. This situation can exist when a mirrored pair is split and each half is used independently. It can also occur in ESS flashcopy and Peer to Peer Remote Copy (PPRC) scenarios and in iSeries geographical mirroring scenarios. Were this to occur, a customer would be faced with down time while he recreates his ASP and restores data to it - including updates that were made after his most recent save. This invention removes the underlying cause for deleting the ASPs and helps the user select which copy to use. It also warns the customer when he has chosen, perhaps inadvertently, to use a back-level of his data. This invention also is used to detect and take preventive action when a copy of an ASP could cause integrity exposures due to regressing the virtual address generation mechanism.

     A unique identifier is generated for the ASP and is saved in the system when the ASP is varied on to the system. The identifier is written in the ASP when the ASP is taken offline. The next time the ASP is varied on, the unique identifier stored in the ASP is compared against the identifier stored in the system. If the two do not match, a warning message is given that contains a choice of actions for the user. An identifier mis-match might occur, for example, because flashcopy or PPRC was used to get a copy that does not have the latest changes to the contents of the ASP that were made on the system. This invention also implements a "detach level" that is used to allow copies to be made for backup or query purposes and to not have these uses result in warnings that a customer would consider extraneous when the ASP copies are used on the same system that also uses the original (the production) ASP. The following are the major data structures associated with this invention:
1. Each system has an array of vary identifiers with one entry for each ASP for which varyon has been done by the system. Each entry in the array contains a unique identifier, ASP identifier, and a detach level number. This information is stored in the system ASP with one unique identifier stored during varyon processing and a different identifier stored during varyoff processing. This information can be discarded when it is known to no longer be needed.
2. Each ASP has an array of vary identifiers with each array entry containing a unique identifier and detach level number for each system that has done varyon of the ASP. The maximum size of the array is configured to 127. Node entries in the array are ordered from the node most recently having done varyon of the ASP to the one th...