Browse Prior Art Database

Foreground/Background Checking of Parity in a Redundant Array of Independent Disks-5 Storage Subsystem

IP.com Disclosure Number: IPCOM000116021D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 175K

Publishing Venue

IBM

Related People

Faunce, MS: AUTHOR [+4]

Abstract

A method of checking for parity corruption in a redundant array of independent disks-5 (RAID-5) storage subsystem is disclosed. Two policies for determining when to initiate the parity checking are addressed; "Foreground" and "Background".

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

Foreground/Background Checking of Parity in a Redundant Array of
Independent Disks-5 Storage Subsystem

      A method of checking for parity corruption in a redundant array
of independent disks-5 (RAID-5) storage subsystem is disclosed.  Two
policies for determining when to initiate the parity checking are
addressed; "Foreground" and "Background".

      When a RAID-5 array is NOT exposed (i.e., no device is
currently failed), parity data can be checked for corruption by the
following steps:
  1.  A device and Logical Block Address (LBA) range on that device
is
       selected
  2.  Read operations are performed to all devices in the array
(except
       for the selected device) to corresponding LBA ranges in the
       parity stripe such that all the data read is XORed together,
the
       result being placed in a buffer
  Note: This type of operation is commonly known as an "exposed
         mode read".
  3.  A normal read operation (with no XOR) is performed to the
       selected device to read data for the selected LBA range into a
       2nd buffer
  4.  The two sets of data are compared
  Note: This sequence does not address such necessary steps as the
         allocation of the buffers, obtaining a lock on the
corresponding
         parity stripes (to prevent the updating of parity while it
is
         being checked), etc.  However, these types of steps are
         routinely performed in a RAID-5 controller and are not
included
         here in order to simplify the discussion.

      Given that parity is not corrupt for the parity associated with
the device and LBA range selected in step #1, the data in the two
buffers should be identical when compared in step #4.  The reads
performed as part of step #2 exactly mimic those which would be
executed for a host requested read of the same device/LBA range given
the device were failed and the array were exposed (i.e., an "exposed
mode read").  However, in this scenario the array is not exposed and
thus step #3 above can be used to read the actual data stored on the
selected device/LBA range in order to verify the results of the
"exposed mode read".

      The figure shows a simplified layout of "diagonal" parity
stripes as used on current AS/400* internal RAID-5 Direct Access
Storage Device (DASD) Input/Output Processors (IOPs).  If, for
example, an LBA range within parity stripe #1 on device "B" were
selected for step #1 (i.e., an LBA range within the "U1" group of
data on device "B"), the parity data which would end up being checked
would be on device "A" (i.e., a corresponding LBA range within the
"P1" group of data on device "A").  To perform step #2, corresponding
LBA ranges on devices "A", "C", and "D" (i.e., an LBA range within
"P1" on device "A", within "U1" on device "C", and within "U1" on
device "D") would be read and XORed together, the result being placed
in a...