Browse Prior Art Database

Three Challenges in the Implementation of Disk Mirroring

IP.com Disclosure Number: IPCOM000101785D
Original Publication Date: 1990-Sep-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 7 page(s) / 260K

Publishing Venue

IBM

Related People

Lawrence, KJ: AUTHOR [+3]

Abstract

Disk mirroring is an availability/recovery solution that duplicates disk data. The process of copying data from one disk unit to its mirror is called SYNCHRONIZING. When a disk unit fails, it is SUSPENDED so that the system does not attempt further access to it, and instead references its mirror.

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

Three Challenges in the Implementation of Disk Mirroring

       Disk mirroring is an availability/recovery solution that
duplicates disk data.  The process of copying data from one disk unit
to its mirror is called SYNCHRONIZING.  When a disk unit fails, it is
SUSPENDED so that the system does not attempt further access to it,
and instead references its mirror.

      One challenge is to update data on a disk unit while
synchronizing.  Disk mirroring requires disk units to be synchronized
in situations such as after repairing a unit, or when initially
starting disk mirroring.  A solution is presented to the problem of
allowing update operations to units that are being synchronized.  The
solution allows synchronization to proceed in one pass without
significant loss in performance of either the synchronization or the
update operations.

      A strategy of limiting the range of synchronizing sectors is
used to reduce the time required to synchronize changing data on a
mirrored unit.

      For the purpose of discussion, assume that units are
synchronized sequentially from low sector addresses to high.

      First, the unit is divided into logical blocks or "stripes" of
fixed size.  This partitions the unit into 10 to 30 stripes depending
on the capacity of the unit.  The task that controls the
synchronization process synchronizes one stripe at a time keeping
track of which stripes are synchronized.

      Only update requests in the synchronizing stripes are
considered for special treatment.  Updates in stripes not yet
synchronized can be made by simply writing to the unit used as the
source in the synchronization process.  Updates in stripes already
synchronized can be made by writing to both units.  By considering
only update requests in the stripe currently being synchronized, the
range of disk sectors requiring special treatment is reduced to
around 3 to 10 percent of the unit capacity.

      Second, a stripe that is being synchronized is further divided
into three areas (see Fig. 1).  One area is that which is already
synchronized, area A.  Another, area B, is that area currently being
synchronized.  The third area, C, is that area that is yet to be
synchronized.

      The size of area B depends upon the number of sectors that are
read or written in one I/O request and the number of outstanding
requests that are allowed (number of buffers).  It is typically on
the order of 1/100 of one percent of the total disk capacity.

      If the I/O task gets an update request for a stripe being
synchronized, it sends the request to the task controlling
synchronization of that stripe to determine how to handle it.  The
figure shows the I/O task sending an update request to the
synchronization task.  In Fig. 2, the request was in area A, so the
synchronization task sent the request back to the I/O task,
indicating that it should perform the update to both units.  (The
span of sectors in the up...