Methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment

Methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment are disclosed. According to one method, a clone group is stored on a disk array, the clone group including a logical unit (LUN) representing a storage partition on the disk array and a clone of the LUN, the clone being a copy of the data referenced by the LUN. The clone group is associated with a first storage processor (SP) for writing data to the disk array. Changes between the LUN and the clone are tracked by maintaining a data structure indicative of the changes in a memory associated with the first SP. The association of the clone group is changed to a second SP for writing data to the disk array without transferring the data structure to memory associated with the second SP.

TECHNICAL FIELD

The subject matter described herein relates to trespassing of logical units (LUs) within a disk array environment. More particularly, the subject matter described herein relates to methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment.

BACKGROUND

Disk arrays may include groups of physical disks that are logically bound together to represent contiguous data storage space for applications. For example, disk arrays may be divided into redundant array of inexpensive disks (RAID) groups, which are disk arrays created by logically binding individual physical disks together to form the RAID groups. RAID groups represent a logically contiguous address space distributed across a set of physical disks. Each physical disk is subdivided into pieces used to spread the address space of the RAID group across the group (along with parity information if applicable to the RAID level). The physically contiguous pieces of the physical disks that are joined together to create the logically contiguous address space of the RAID group are called stripes. Stripes may form blocks and blocks may be allocated to create logical representations of storage space for use by applications within a system.

Applications access and store data incrementally by use of logical storage array partitions, known as logical units (LUNs). LUNs are made up of collections of storage blocks of a RAID array and are exported from the RAID array for use at the application level. LUNs are managed for use at the application level by paired storage processors (SPs). Ownership of a LUN is determined when the LUN is mounted by the application, with one of the paired SPs designated as the owner SP and the other SP acting as a backup processing device for the first.

LUNs may be duplicated by copying the contents of a source LUN to another LUN including new storage blocks, thereby creating a new LUN that is a duplicate of the source LUN (e.g., a clone). Clones may be used for archival purposes, such as point-in-time backups, and for restore points in the event of system failures or in order to retrieve older data. Data referenced by a source LUN or by a clone (when the clone is not used as a restore point) may change over time. These changes may be tracked by the use of bitmaps, known as delta maps or fracture logs, and configuration information. Delta maps are bitmaps that may track changed blocks by use of a bit associated with each physical storage data area referenced by a LUN. Configuration information may track processing objectives between a source LUN and a clone. For example, within a clone group, which includes a source LUN and related clones, configuration information may be used to identify synchronization processing activities between a clone or set of clones and a source LUN within the clone group.

Ownership of a LUN may change under a variety of circumstances. For example, ownership of a LUN may migrate from one SP to another for host load balancing reasons, for host failover events, for SP failures, and for manual trespass operations initiated by a user at an application level. Further, entire clone groups traditionally trespass together from one SP to another. The term “trespass,” as used herein, refers to a change of association of a clone group from one SP to another SP.

In conventional systems, when ownership of a LUN migrates from one SP to the paired SP, data structures (e.g., delta maps) and configuration information for each LUN that is migrated are required to be communicated between the SPs. However, these data structures are not required for the change in ownership/association to occur. This information communication has traditionally been required to be completed prior to accessing a migrated LUN for input and output (I/O) operations. Accordingly, a migrating LUN is not useable for I/O purposes. Under some of the above-described circumstances where ownership may change, such as during a host failover event or an SP failure, many LUNs may need to be migrated from an owner SP to the paired SP. Under these circumstances, the time required for communicating delta map and configuration information for a migrating LUN may be lengthy due to I/O bandwidth limitations, resulting in degraded I/O performance.

Synchronization between a source LUN and a clone may occur either periodically or upon request from the application level or a system administrator. On conventional systems, synchronization requires a separate communication of data structures and configuration information between the original owner SP and the paired SP. Accordingly, conventional systems, in addition to imposing an unavailability associated with a trespass operation, also duplicate communication of delta maps and configuration information between original owner SPs and the paired SPs when a synchronization event follows a trespass operation. As well, certain configuration information that was transmitted during a trespass operation is only needed during a synchronization event. Accordingly, much of the communication bandwidth associated with a trespass operation is unnecessary in conventional systems.

Accordingly, in light of these difficulties associated with conventional trespass of LUNs, there exists a need for improved methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment.

SUMMARY

According to one aspect, the subject matter described herein comprises methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment. One method includes storing, on a disk array, a clone group including a logical unit (LUN) representing a storage partition on the disk array and a clone of the LUN, the clone being a copy of the data referenced by the LUN at a point in time, associating the clone group with a first storage processor (SP) for writing data to the disk array, tracking changes between the LUN and the clone by maintaining a data structure indicative of the changes in a memory associated with the first SP, and changing the association of the clone group to a second SP for writing data to the disk array without transferring the data structure to memory associated with the second SP.

The subject matter described herein for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment may be implemented using a computer program product comprising computer executable instructions embodied in a computer-readable medium. Exemplary computer-readable media suitable for implementing the subject matter described herein include chip memory devices, disk memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer-readable medium that implements the subject matter described herein may be distributed across multiple physical devices and/or computing platforms.

DETAILED DESCRIPTION

In view of the problems described above with respect to conventional trespass of LUNs, the subject matter described herein provides for postponing bitmap transfers and eliminating configuration information transfers associated with trespass operations. Where previously a trespass of a LUN or clone group initiated a communication of delta maps and configuration information between an owner SP and a paired peer SP which manage LUNs within a RAID array, resulting in lengthy delays for I/O operations, the methods, systems, and computer program products described herein postpone bitmap transfers and eliminate configuration information transfers associated with trespass operations to improve trespass times in a RAID environment. By adapting trespass operations to postpone bitmap transfers and to eliminate configuration information transfers associated with the trespass operations, trespass times may be reduced and I/O operations may be improved. Certain information previously communicated as part of the configuration information may be more rapidly calculated from information stored redundantly in memory associated with each SP and persistently to disk rather than communicated, as will be described in more detail below.

Information that is stored redundantly in memories associated with each SP includes state information for all clones within each clone group and reverse synchronization image (revSyncImage) information for each source LUN. This information is generated and stored in a local memory associated with an SP when any clone is created and when any subsequent changes are made to a clone or to a source LUN. Upon generation of this information, the generating SP will communicate this information to the peer SP and store the information to disk. In this way, the redundant SPs will be aware of all clone groups within the system. Further, by storing this information persistently to disk, either SP may access the information upon reboot after any event that has removed the information from the memories that are associated with the peer SPs.

Information that was previously communicated as part of the configuration information during a trespass operation includes an image phase (imagePhase) indicator. The image phase indicator is used to synchronize a clone with a source LUN or to reverse synchronize a source LUN to a clone, as will be described in more detail below. Because the image phase indicator may now be calculated from the state of a clone and reverse synchronization image information, communication of this information during trespass operations is no longer needed. This information may be calculated faster than communicated between the SPs because initiation and completion of communications between the SPs takes more time than calculation of the image phase indicator locally. Accordingly, trespass times may be improved relative to conventional systems by calculating image phase indicators rather than communicating them between SPs.

The following state table will be used to define clone states and actions related to calculating an image phase.

TABLE 1Calculation of Image Phase for a CloneImage Phase of a CloneState of CloneReplay Fracture Log1)Out of Sync2)Synchronizing3)In Sync4)Consistent “and” (Reverse Sync ImageIndex of source LUN != index of clone)Replay Reverse Fracture1)Reverse Out of SyncLog2)Reverse Syncing3)Consistent “and” (Reverse Sync ImageIndex of source LUN == index of clone)

As can been seen from Table 1, an image phase for clone may have two values: “replay fracture log” and “replay reverse fracture log.” The image phase may be set to replay fracture log when the state of the clone is any one of “out of sync,” “synchronizing,” “in sync,” and “consistent” when a reverse sync imagine index of the source does not equal the index of the clone. The imagine phase of a clone may be set to replay reverse fracture log when the state of the clone is any of “reverse out of sync,” “reverse syncing,” and “consistent” when a reverse sync imagine index of the source equals the index of the clone.

As will be described in more detail below, the reverse sync image index value for a source LUN may be set to an index of a clone within a clone group to indicate that the clone referenced by the index is being used to reverse sync the source LUN. Accordingly, the image phase of a clone may be set to replay reverse fracture log when a reverse sync has been requested by an application and is either queued or in process. The image phase of a clone may be set to replay fracture log when an application has requested a sync operation to synchronize a clone with a source LUN and that request is either queued or in process.

FIG. 1illustrates an exemplary disk array application environment100for providing storage processing functions for an application within a disk array. An application102may interface with a storage processor module104. Application102may include in the application with storage requirements that may be implemented using a disk array. Storage processor module104may provide redundant storage processing capabilities for disk array application environment100.

Within storage processor104, a storage processor1(SP1)106may interface with a memory1108. SP1106may include one or two central processing units (CPUs) to provide increased performance capabilities within SP1106. Memory1108may be used for storage of data structures information used by SP1106to process storage requests from application102.

An SP2110and a memory2112represent redundant storage processing capabilities within storage processor module104and may be used for load balancing and failure mode activities within storage processor module104.

A communications management interface (CMI) BUS114interconnects SP1106and SP2110. CMI BUS114may be used for inter-processor communications related to redundant storage activities within disk array application environment100and for load balancing in failure mode operations.

A data storage pool116represents a logically contiguously view of a physical RAID array118, and as such, provides a mapping of storage extents120on to RAID array118. For simplification, data storage pool116is illustrated as a logical layer that resides adjacent to RAID array118, which may include physical disks. However, it is understood that one or more logical layers, such as aggregations of pools116and RAID groups, that reside between data storage pool116and the physical disks that make up RAID array118without departing from the scope of the subject matter described herein. An exemplary hardware platform on which disk array application environment100may be implemented is the CLARiiON® platform available from EMC Corporation of Hopkinton, Mass.

A source LUN122may be used to map a virtual address space for application102onto data storage pool116and RAID array118. Storage blocks120within data storage pool116may be allocated either contiguously or non-contiguously within disk array application environment100, and the logical address space of source LUN122may, thereby, be mapped to physical storage space within data storage extent pool116and RAID array118.

Application102may request point-in-time copies of source LUN122to be created for archival and restoration purposes. Accordingly, a clone1124up to a clone Z126may be created over time by the allocation of new storage blocks within data storage pool116and RAID array118or within another data storage pool in RAID array by the allocation of new storage extents and the copying of data from storage extents associated with source LUN122. Accordingly, when a clone is created, new storage extents may be allocated and data may be copied from physical storage extents associated with a source LUN to a newly allocated storage space associated with the clone. In this way, a clone may provide a persistent representation of data within the logical address space of application102.

Source LUN122and any associated clones, such as clone1124through clone Z126may be associated within a clone group128. Accordingly, clone group128may increase and decrease in size over time as clones are created and destroyed.

Ownership of source LUN122and any clones clone group128may be assigned to either SP1106and SP2110.FIG. 1depicts a solid line between SP1106and clone group128to represent that SP1will be assumed to be the current owner of clone group128.

Under certain circumstances ownership of a source LUN and any associated clones within a clone group may be trespassed from SP1106to SP2110. For example, host load balancing, host failover, SP failures, manual trespass operations initiated by a user of application102, and trespass of clones in response to a trespass of a source LUN all represent exemplary situations in which a trespass of ownership from SP1106to SP2110may occur. A dashed line entitled “Trespass” and a dashed line between SP2110and clone group128indicate that the ownership may change from SP1106to SP2110based upon a trespass operation, as will be described in more detail below.

FIGS. 2A-2Billustrate a magnified view of the exemplary RAID application environment including storage extent tracking data structures for managing trespass operations within disk array application environment100. For purpose of illustration, clone group128is shown to include source LUN122and clone1124withinFIGS. 2A and 2B. Further, memory1108associated with SP1106is also depicted withinFIGS. 2A-2B. Other portions of storage processor module104are not depicted withinFIGS. 2A-2Bto simplify the description herein.

As described above, storage extent pool116may be dynamically allocated from available storage extents within storage extent pool116and RAID array118as application102generates data for regions of its virtual address space.FIG. 2Aillustrates a point in time when source LUN122has been used by application102and clone1124has just been created. A storage pointer structure202within source LUN122is indexed from 0 to N−1 to represent storage locations that make up the virtual address space of application102. Storage pointer structure202may be stored either in memory1108or within a storage block of storage extent pool116. Dashed lines withinFIG. 2Arepresent that storage pointer structure202is stored in block1204of storage extent pool116. Storage pointer structure202includes block numbers three (3), five (5), nine (9), and seven (7) at indices zero (0), one (1), two (2), and three (3) within storage pointer structure202. Arrows withinFIG. 2Aillustrate that block3206, block5208, block9210and block7212have been allocated for these regions of the virtual address space represented within source LUN122. It should be noted that the storage extents are non-contiguous within storage extent pool116, but contiguous allocation are also possible.

Clone1124is illustrated to include a storage pointer structure214stored in block11216of storage extent pool116. Because clone1124represents a point-in-time back up of source LUN122, data has been copied from storage extents associated with source LUN122and referenced within storage pointer structure202to newly allocated storage extents reference by storage pointer structure214within clone1124. Accordingly, block12218, block13220, block14222, and block15224have been referenced within storage pointer structure214at indices zero (0), one (1), two (2), and three (3), respectively. With the storage extents allocated within storage pointer structure214of clone1124and with data copied to them from the storage extent referenced by storage pointer structure202of source LUN122, a redundant data set has been created for application102that may be used to reference changes in either source LUN122or clone1124against the other.

In order to track changes in either source LUN122or clone1124against the other, a fracture log226is illustrated including indicators228indexed from 0 to N−1, each representing an indication of changed data referenced by either storage pointer structure202within source LUN122and storage pointer structure214within clone1124, as will be described in more detail below.

A source LUN tracking structure230is illustrated within memory1108, including a reverse sync image index field set to a null value of zero (0), an owner field set to SP1to indicate that SP1106is the owner of source LUN122, and a group field including an indicator that clone1124is a member of clone group128with source LUN122. Source LUN tracking structure230may be used during trespass operations, as will be described in more detail below, to manage migration of clone groups and ownership change as well as to indicate when sync operations are to be preformed between a source LUN and a clone.

A clone tracking structure232is illustrated within memory1108including a state field representing a current state of “in sync.” Many states are possible for a clone, some of which have been illustrated and described above in relation to Table 1. Because clone1124is assumed to have just been created withinFIG. 2A, its state may be considered to be in sync with source LUN122because there are no differences between the data represented in the respective storage locations referenced by each LUN. As well, all indicators228within fracture log226are cleared to represent that there are no differences between the data referenced by source LUN122and clone1124.

An image phase234is illustrated within memory1108. An image phase, as described above, may be calculated upon a trespass of a clone group from one SP to another SP and may be used as an indication of a future sync operation or reverse sync operation that may be preformed. Image phase234includes an initial value of “replay fracture log” to coincide with the “in sync” state of clone1124represented within clone tracking structure232, as described in more detail above in relation to Table 1.

FIG. 2Billustrates a state change within disk array application environment100after application102has written data to two storage extents referenced by source LUN122. For purposes of illustration, it will be assumed that application102wrote to block5208and block7212at indices one (1) and three (3) within storage pointer structure202and fracture log226. Accordingly, two indicators within facture log226at indices one (1) and three (3) have been set withinFIG. 2B.

Because data referenced by source LUN122has been changed by application102, data referenced by clone1124no longer mirrors the data represented by source LUN122. The state field within clone1tracking structure232has been changed to a “consistent” state. A consistent state for a clone may exist when data represented by a clone accurately represents valid data for the point in time at which it was created, but that the data represented by a source LUN associated with the clone has since changed. Accordingly, should application102need to revert to the data set represented by clone1124, clone1124may be used to reverse sync source LUN122because the state of clone1124is consistent. Further, as described in more detail below, clones may be synced to source LUNS after clones have been created. In this way, a clone may be kept periodically synchronized with a source LUN to maintain a redundant data set without creating new clones to represent the point-in-time copy associated with the point in time when the sync operation occurred.

FIGS. 3A-3Dillustrate disk array application environment100tracking structure communications and updates associated with trespass operations and sync operations.FIGS. 3A-3Dadd memory2112in order to illustrate inter-processor communications and resulting operations on data structures between SP1106and SP2110.FIGS. 3A-3Dalso have detailed depictions of storage extent mappings for source LUN122and clone1124onto storage extent pool116removed.

FIG. 3Adepicts a state of disk array application environment100after clone group128has been updated in memory2112of SP2110. Within memory2112, data structures similar to those described above in relation to memory1108are illustrated. Accordingly, a source LUN tracking structure302, a clone tracking structure304, an image phase306, and a fracture log308are illustrated within memory2212. Each of source LUN tracking structure302, clone tracking structure304, image phase306, and fracture log308may be used as described above and in more detail below for tracking information associated with clone groups that may be trespassed between SP1106and SP2110. Fracture log308includes indicators310which may be used to mirror the contents of fracture log226within memory1108, as will be described in more detail below.

As described above in relation toFIG. 2B, source LUN122and clone1124differed by the contents of two storage extents represented by indices one (1) and three (3) in fracture log226. Accordingly, as can been seen fromFIG. 3A, source LUN tracking structure230has been communicated over CMI Bus214from SP1106to SP2110. Upon receipt, SP2110has updated source LUN tracking structure302equivalent to source LUN tracking structure230with comparable fields as described above. Clone tracking structure304has also been updated in memory2112to be equivalent to clone tracking structure232in memory1108. Image phase306has also been updated to reflect the current setting of image phase234within memory1108. However, fracture log308has not been updated and includes default values. As described above and in more detail below, fracture log308may be updated after a trespass operation in response to a sync event.

By periodically communicating source LUN tracking structures and clone tracking structures associated with clone groups from an owner SP to an non-owner SP, trespass operations may occur and the non-owner SP may become the owner SP without excessive data structure communications by already having current information related to the clone group stored in local memory. Accordingly, during a trespass operation these tracking structures may be accessed directly from the non-owner SP that is to become the owner SP without a need to communicate the tracking structures over CMI Bus114at that point in time.

In conjunction with periodically updating a non-owner SP with clone group tracking structures, the clone group tracking structures may also be written to disk and stored, for example, within storage data pool116. In this way, clone group tracking structures may persist between power cycles within disk array application environment100.

FIG. 3Billustrates disk array application environment100after a trespass operation has occurred and SP2110has become the owner of clone group128. As can be seen fromFIG. 3B, the owner field of both source LUN tracking structure230and source LUN tracking structure302have been changed to indicate that SP2110is now the owner of clone group128. This change in ownership may be initiated by either SP. Accordingly, with the trespass initiated by SP1106, SP1106may change the owner field within source LUN tracking structure230prior to initiating a trespass or in response to a successful completion of a trespass and may communicate information associated with the trespass occurring over CMI Bus114to SP2110. In response SP2110may update the owner field within source LUN tracking structure302. In the alternative, when a trespass operation occurs under control other than the control of SP1106, for example during a temporary failure of SP1106, SP2110may update the owner field within source LUN tracking structure302and may communicate the ownership change to SP1106when it recovers. In response, SP1106may update the owner field of source LUN tracking field230to indicate that SP2is the current owner of clone group128.

FIG. 3Balso illustrates that an image phase306has also been calculated and stored within memory2112by SP2110. An image phase, as described above, may be calculated upon a trespass of a clone group from one SP to another SP and may be used as an indication of a future sync operation or reverse sync operation that may be preformed. In contrast to conventional systems, disk array application environment100may postpone bitmap transfers and may eliminate configuration data transfers during a trespass operation and may, thereby, make clone groups accessible to applications, such as application102, without the delays associated with communicating bitmaps and configuration data in conventional systems. As described above, during certain failover events, many clone groups may need to be trespassed from one SP to another SP. Accordingly, in conventional systems, where bitmaps and configuration data were transmitted for each trespass operation, significant bandwidth consumption was involved. In contrast, disk array application environment100may provide for a more rapid trespass of clone groups from one SP to another.

By postponing bitmap communication and by removing configuration data communication and by calculating image phase306on SP2110in response to a trespass operation, SP2110may perform a future sync operation at a scheduled interval or in response to a request from application102and may request fracture log228at that future point in time when bandwidth requirements have decreased.

Image phase306includes an indicator set to “replay fracture log.” As described above in relation to Table 1, an image phase set to replay fracture log suggests that when a sync operation occurs, the synchronization may be a forward synchronization from source LUN122to clone1124. Alternatively, when image phase306is set to “replay reverse fracture log,” it suggests that when a sync operation occurs, the synchronization may be a reverse synchronization from clone1124to source LUN122. By default, image phase306may be calculated, based upon the criteria specified in Table 1, and in this case, because the state of clone1124is consistent within clone tracking structure304and because the reverse sync image index field of source LUN tracking structure302does not equal one (1), the index of clone1124, the image phase may be set to replay fracture log.

FIG. 3Cillustrates disk array application environment100tracking structures after starting a sync of clone1124relative to source LUN122. Sync requests may be queued and scheduled. For purposes of illustration, it will be assumed that any delay associated with queuing the sync operation has passed and that the state of disk array application environment100depicted inFIG. 3Cis at a point in time after the sync operation has begun.

As described above, fracture logs may be requested at the time of a sync request. Accordingly, SP2110may request fracture log226. In response to receipt of the contents of fracture log226, SP2110may update fracture log308in memory2112. It should be noted that fracture log226withinFIG. 3Chas all indicators cleared. When SP2110request the contents of fracture log226and updates fracture log308locally within memory2112, SP1106may, as a part of the request operation for fracture log226, clear all indicators in fracture log226contained in memory1108upon a successful transmission of the contents of fracture log226to SP2110. Accordingly, all indicators in fracture log226have been cleared and indicators within fracture log308corresponding to storage extents within source LUN122that contain changed data have been set.

Because image phase306is set to “replay fracture log,” the contents of changed data storage extents associated with source LUN122may be copied to corresponding storage extents associated with clone1124. As can be seen fromFIG. 3C, the state field within clone tracking structure304has been changed to “synchronizing.” As part of the request operation for fracture log information associated with the synchronizing event, SP2110may also instruct SP1106that a synchronization operation is progressing. Accordingly, SP1106may change the state field of clone tracking structure232to indicate that clone1is synchronizing. In this way, both SPs maintain current information regarding the state of clones within a clone group. Should there be a scheduled SP reboot or some other situation requiring a trespass of clone group128back to SP1106, SP1106may recognize that the state of clone1is synchronizing and may retrieve fracture log308from memory2112by issuing a request on CMI bus114to SP2110. In this way, even under circumstances where a sync operation does not complete, either SP may complete the sync operation.

FIG. 3Dillustrates disk array application environment100after a forward sync operation has been completed. As can be seen fromFIG. 3D, indicators310at indices one (1) and three (3) of fracture log308have been cleared. As well, the state field within clone tracking structure304has been changed to “in snyc.” As described above, tracking structures are maintained in a consistent fashion in memories associated with both SPs. Accordingly, SP2110has copied the state information associated with clone1124and clone tracking structure304over CMI bus114to SP1106. In response, SP1106has modified the state field within clone tracking structure232to indicate that the state of clone1124is “in sync.”

FIGS. 4A-4Bdepict a reverse sync scenario for disk array application environment100. In contrast to forward sync operations depicted inFIGS. 3A-3D,FIGS. 4A-4Bdepict a reverse sync operation wherein a source LUN is updated from a clone. The initial state ofFIG. 4Awill be assumed to be after a trespass operation has occurred and after a request for a reverse sync operation has been received from application102, but prior to an initiation of the reverse synchronization. Indicators310at indices one (1) and three (3) in fracture log308are set to indicate that data at those regions within either source LUN122or clone1124contain new data since the last operation that synchronized the data within the two LUNs. For purposes of illustration, it will be assumed withinFIGS. 4A-4Bthat application102wishes to discard updates to data represented by source LUN122at the regions referenced within fracture log308and that application102wishes to revert to the data represented within clone1124.

It should be understood that application102may also mount clone1124for I/O operations, may make modifications to data represented by clone1124, and may reverse sync clone1124to source LUN122. In such a circumstance, fracture log308may represent changed data represented by clone1124. In this way, fracture log308may be used to represent changes in source LUN122and clone1124. For example, application102may mount an older version of data by mounting clone1124, may modify that data, and may verify the changed data before overwriting the data represented by source LUN122using a reverse sync operation.

As described above, it will be assumed that the changes to source LUN122are to be overwritten by the archived data represented by clone1124. Accordingly, in response to the request from application102to reverse sync source LUN122to clone1124, SP2110may set image phase306. As can be seen fromFIG. 4A, image phase306has been set to “replay reverse fracture log.”

Because application102has requested a reverse sync operation, SP2110has set the reverse sync image index field within source LUN tracking structure302to one (1) to indicate that a reverse sync operation is to occur and that clone1124is the clone with which to synchronize source LUN122. As described above in relation toFIG. 3B, the state of clone1124may be consistent after a trespass operation and prior to a sync operation activating. It should also be noted that the reverse sync image index field within source LUN tracking structure302may be set to any type of indicator capable of referencing a clone. For example, using integer clone indices, a clone with an index of two (2) may result in a reverse sync image index of two (2) when the clone with an index of two (2) is used to reverse sync the source LUN. For purposes of illustration, the index of clone1124is assumed to be one (1).

As with other operations described above in relation to clone group tracking structures,FIG. 4Aillustrates that SP2110has communicated clone tracking structure information to SP1106. In response, SP1106has updated source LUN tracking structure230to indicate in the reverse sync image index field that one (1) is the index of the clone, clone1124, to reverse synchronize with source LUN122. Because the synchronization has not begun, the state field within clone tracking structure232remains set to indicate that the state of clone1124is “consistent.” In this way, should SP2110not complete the reverse sync operation, SP1106may recognize that clone group128was in the process of a reverse sync operation and may request fracture log308from SP2110stored in memory2112and may calculate an image phase of “replay reverse fracture log”. When the synchronization process is queued and begins, different states, for example “queued,” and “reverse synchronizing,” may be represented within the state field of clone tracking structure304and may be communicated to SP1106for placement within the state field of clone tracking structure232, as will be described in more detail below. Accordingly, should SP2110not complete the reverse sync operation, SP1106may recognize that clone group128was in the process of a reverse sync operation and may request fracture log308from SP2110stored in memory2112, may calculate an image phase of “replay reverse fracture log”, and may complete the reverse synchronization process from the last state completed by SP2110.

As described above, sync operations may be queued. When queued for a sync operation, the state of clone1124represented within clone tracking structure304may be set to “queued.” (Not depicted inFIG. 4A). As well, when a reverse synchronization has been initiated, the state of clone1124represented within clone tracking structure304may be set to “reverse synchronizing.” (Also not depicted inFIG. 4A). As described above, both of these states may be transmitted to SP1106in order to allow that unit to take over the sync operation and to complete it in the event that SP2110is unable to complete the sync operation.

FIG. 4Billustrates disk array application environment100after the reverse sync operation has been completed. As described above, intermediate states of the reverse sync operation have not been depicted. Those intermediate states included a “queued” state and a “reverse synchronizing” state. Accordingly, as can be seen fromFIG. 4B, with the reverse synchronization complete, indicators310at indices one (1) and three (3) in fracture log308have been cleared. Also, the reverse sync image index field within source LUN tracking structure302has been cleared and the state of clone1124within clone tracking structure304has been set to “in sync.” As well, source LUN tracking structure230and clone tracking structure232have been updated to reflect the operations performed by SP2110on clone group128.

FIG. 5illustrates an exemplary process by which a trespass of a clone group may occur in a RAID application environment with bitmap transfers postponed and without communication of configuration data. At block502, the process may provide a clone group associated with a first SP, the clone group including a LUN and a clone of the LUN for referencing storage locations in a RAID array to form redundant contiguous address spaces for an application. For example, clone group128may be provided with source LUN122and clone1124. Clone group128may be associated with SP1106by setting the owner field within source LUN tracking structure230to indicate that SP1106is the owner of clone group128.

At block504, the association of the clone group may be trespassed from the first SP to a second SP. For example, clone group128may be trespassed from SP1106to SP2110and the owner field within source LUN tracking structure302may be set to indicate that SP2110is now the owner of clone group128.

In response to a sync request, at block506the process may copy a fracture log including indicators for tracking changes to data stored in the RAID array in the storage locations referenced by one of the LUN and the clone within the clone group from a first memory associated with the first SP to a second memory associated with the second SP and may copy, using the fracture log at the second SP, changed data from storage locations in the RAID array referenced by the one of the LUN in the clone to corresponding storage locations in the RAID array referenced by the other of the LUN and the clone. For example, fracture log226may be maintained in memory1108by SP1106to indicate, using indicators228, locations referenced by one of the source LUN122and clone1124that have changed. In response to a sync request from application102, SP2110may copy fracture log226from SP1106over CMI bus114and store it in memory2112as fracture log308. Further, SP2110may copy, using indicators310within fracture log308data stored in storage extents120in storage extent pool116associated with changed data locations represented by source LUN122to storage extents120in data storage extent pool116associated with the corresponding locations referenced by clone1124.

FIG. 6illustrates an exemplary process by which input and output operations may be managed and by which change tracking information may be updated. At block602, the process may provide a clone group associated with a first SP including a LUN and a clone. At block604, the process may maintain a fracture log for tracking changes to storage locations in a RAID array associated with the clone group.

At decision point606, the process may determine whether any data is to be changed and may continue to check for data changes at decision point606until a data change occurs. When a data change has occurred, as determined at decision point606, the process may analyze the data change at block608and may update the fracture log to indicate the changed storage locations at block610. At decision point612, the process may determine whether to the data change results in a change to the state of the clone. When a clone state changes results from the data change, the clone state may be updated on both SPs at block614. When the clone state has been updated on both SPs or when the data change does not result in a clone state change, the process may send the data to the LUN for storage in locations referenced by the LUN. The process may then return to decision point606to await another data change.

FIG. 7illustrates an exemplary process by which clone groups may be trespassed from one SP to another with bitmap transfers postponed, without communicating configuration data, and with an image phase indicator calculated in order to manage a forward synchronization or a reverse synchronization operation. At decision point702, the process may determine whether a trespass operation has been initiated. When no trespass operation has been initiated, the process may determine whether a sync event has been initiated at decision point704. When no sync operation has been initiated, the process may return to decision point702to iteratively check for trespass and sync operations.

When a trespass operation has been initiated, as determined by decision point702, the process may associate the clone group with the other SP at block706. At decision point708, a determination may be made as to whether the state of the clone is “out of sync.” When the state of the clone is not out of sync, a determination may be made at decision point710as to whether the state of the clone is “syncing.” When the state of the clone is not syncing, a determination may be made at decision point712as to whether the clone is “in sync.” When the state of the clone is not in sync, a determination may be made at decision point714as to whether the state of the clone is “consistent” and whether the reverse sync index is not equal to the clone index.

When the clone is consistent and the reverse sync index is not equal to the clone index, as determined at decision point714, or when the clone is in sync as determined at decision point712, or when the clone is syncing as determined at decision point710, or when the clone is out of sync as determined at decision point708, the process may set the image phase to “replay fracture log” at block716and the process may return to decision point704to determine whether a sync operation has been initiated. In this way, a sync operation may follow a trespass operation or may be a separately scheduled event.

When a determination has been made at decision point714that either the clone is not consistent or the reverse sync index is equal to the clone index, the process may determine whether the state of the clone is “reverse out of sync” at decision point718. When the state of the clone is not reverse out of sync, a determination may be made at decision point720as to whether the state of the clone is “reverse syncing.” When the state of the clone is not reverse syncing, a determination may be made at decision point722as to whether the state of the clone is “consistent” and whether the reverse sync index is equal to the clone index.

When the state of the clone is either reverse out of sync as determined at decision point718, or reverse syncing as determined at decision point720, or consistent and the reverse sync index equals the clone index as determined at decision point722, the process may set the image phase to “replay reverse fracture log” at block724and the process may return to decision point704to determine whether a sync operation has been initiated. In this way, a sync operation may follow a trespass operation or may be a separately scheduled event.

When a determination has been made at decision point722that either the clone is not consistent or the reverse sync index is not equal to the clone index, the process may also return to decision point704to determine whether a sync operation has been initiated as described above.

When a sync operation has been requested, as determined at decision point704, the process may get the fracture log associated with the clone group from the other SP and update local memory at block726. The process may set the reverse sync image index at block728. As described above, the reverse sync image index may be set zero (0) if a forward sync is in process and to the index of the clone to be reverse synced with if a reverse sync is in process.

At block730, the state of the clone may be set and the peer may be updated with the current state information for the clone. As described above, by updating state information for the clone on the peer, the peer may maintain current information about the clone, and the peer may take over the sync operation in an event that the initiating SP may not finish the sync operation.

At decision point732, a determination may be made as to whether the sync operation is a forward sync or a reverse sync operation. When the sync is a forward sync operation, the process may copy any changed data from storage locations in the RAID array referenced by the LUN to corresponding storage locations in the RAID array referenced by the clone at block724and may return to decision point702to determine whether a trespass operation has been initiated.

When the sync is a reverse sync operation, the process may copy changed data from storage locations in the RAID array referenced by the clone to corresponding storage locations in the RAID array referenced by the LUN at block736and may return to decision point702to determine whether a trespass operation has been initiated.

As described above, the peer SP may be updated with clone tracking structure information for any changes to any clone tracking structure. For ease of illustration, certain of these updates have not been depicted withinFIG. 7. Reference may be made to the descriptions above in relation toFIGS. 3A-3Dand4A-4B for details of these operations.