HP StorageWorks XP Remote Web Console Software - Manual (Page 18)

NOTE: XP Continuous Access Asynchronous operations continue uninterrupted if the disk array
reboots or the disk array's internal Service Processor (SVP) fails.
Sending recordsets to the RCU
The MCU sends asynchronous XP Continuous Access recordsets to the RCU in a manner similar to
XP Continuous Access synchronous updates. The MCU's initiator ports act as host processor channels
and issue special I/O operations, called remote I/Os (RIOs), to the RCU. The RIO transfers recordsets
in FBA format (not CKD) using a single channel command, eliminating overhead associated with
FBA-CKD conversion and thus providing more efficient data transfer. The MCU can send several
recordsets using a single RIO, even if their sequence numbers are not contiguous. Therefore,
recordsets are usually sent to the RCU in a different order than the arrivals at the MCU. The RCU
ensures that records are applied to the S-VOLs in the correct sequence. This method of remote I/O
provides the most efficient use of MCU-to-RCU link resources.
The parameter length and detailed specification of the XP Continuous Access Asynchronous channel
command are different than for XP Continuous Access Synchronous RIOs. You must ensure that
your channel extenders support this command. For further details, contact your HP account support
representative.
Storing recordsets at the RCU
The RCU maintains queues to control storing recordsets in the sidefile and committing updated
records in the S-VOLs. The RCU queuing mechanism for XP Continuous Access Async uses sequence
numbers provided by the MCU to check for missing updates.
The MCU does not remove the sidefile entry for a recordset from its cache until it receives an I/O
completion signal (device end) from the RCU. This is true even if the MCU and RCU are connected
via a channel extender product. If a recordset is lost in transmission from the MCU to the RCU, the
MCU's cylinder bitmap ensures that the missing recordset is identified and resent to the RCU.
Selecting and settling recordsets at the RCU
The RCU selects recordsets to be promoted to formal data (or “settled”) as follows:
1. The RCU checks for a valid entry at the top of each queue in the consistency group. If the top
of any queue is empty (recordset not yet received), the RCU waits for that entry.
2. When the top of each queue contains a valid entry (recordset), the RCU selects the entry with
the earliest sequence number, and settles that recordset.
3. The RCU repeats this process to select and settle XP Continuous Access Asynchronous recordsets.
Figure 3 (page 19) illustrates recordset selection and settling at the RCU. In this example, the top
of the queue contains a valid entry: S1. The RCU selects recordset S1 to be settled, because S1 is
the earliest sequence number. When S1 is removed from the MCU queue, recordset S2 becomes
the top entry, but it is empty. When recordset S2 arrives the RCU selects S2 as the next recordset
to be settled. The recordset the RCU selects is marked as “host-dirty” and treated as formal data.
The RCU settles the updated records in the recordset as follows:
•
If the corresponding track is in cache (track-hit), updated records in the recordset are copied
to the existing cached track, and cache space for the sidefile is released.
•
If the corresponding track is not in cache (track-miss), the RCU changes the cache designation
of the sidefile to formal data. Data is not physically moved.
18 Overview of XP Continuous Access operations