Browse Prior Art Database

Performance Assist for Checksum DASD

IP.com Disclosure Number: IPCOM000037222D
Original Publication Date: 1989-Dec-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 3 page(s) / 32K

Publishing Venue

IBM

Related People

Tetzlaff, WH: AUTHOR

Abstract

This describes a way to assist a CPU-intensive aspect of writing "checksum" DASD blocks. An example of "checksum" DASD is the IBM System/38 usage to provide a form of duplexing of DASD. This disclosure places the two Exclusive OR operations in the I/O subsystem in order to reduce the CPU time needed to prepare the checksum record and to eliminate cache damage.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 3

Performance Assist for Checksum DASD

This describes a way to assist a CPU-intensive aspect of writing "checksum" DASD blocks. An example of "checksum" DASD is the IBM System/38 usage to provide a form of duplexing of DASD. This disclosure places the two Exclusive OR operations in the I/O subsystem in order to reduce the CPU time needed to prepare the checksum record and to eliminate cache damage.

The System/38 is a system that uses n + 1 DASD devices in order to store n devices worth of data with increased reliability. In the System/38 this is called checksumming. In such a system a group of DASDs has an additional drive which is used to store the Exclusive OR of all of the physical blocks residing in corresponding physical locations. Should one drive fail, it is possible to reconstruct the contents by doing an Exclusive OR of the remaining drives with the checksum drive. The checksum drive contents can be reconstructed from the contents of the data drives. In order to keep the checksum drive accurate it is necessary to change the checksum each time any physical block is written. The checksum block need not be recreated from all of the data blocks. It can be recreated by Exclusive ORing the old block with the checksum (thus removing its effect) followed by Exclusive ORing in the new block. The result is then written to the checksum device. Naturally some form of caching is normally used to reduce the reads of the checksum drive. Presumably the record that is being changed has been recently read and thus is in the cache too. While this description is done in terms of a CPU communicating with an I/O subsystem the technique is equally valid within a DASD control unit with a cache.

The figure shows the usual relationship between the system structure elements that has been described. For simplicity the checksums are all shown on one drive, in fact the checksums can be divided into address ranges and distributed across all drives in order to distribute the activity of the checksum writing. When a record A is to be changed to contain A' it is necessary to also change X to X'. X' is calculated from the Exclusive OR of A, A' and X. The process of creating the Exclusive OR of the blocks normally is done by CPU instructions.

The use of normal CPU instructions has two primary disadvantages. First, the Exclusive OR operation must be done twice with each one referencing two very long data fields and storing another, thus taking a very long time. Second, on cache machines, the very long operands are brought into the cache and become the most recently referenced cache lines despite the fact that they are not apt to be used, because they are about to be written to DASD.

This disclosure proposes to eliminate both problems by placing the Exclusive OR operation in the I/O subsystem. This allows the I/O subsystem to make the storage references independent of the cache and it allows the Exclusive OR operations to become a normal part of the movement of...