In data storage systems, it may be desirable to store multiple copies of data in one or more locations. For example, a data storage system may include a first data storage location that stores original data (hereinafter referred to as a “source”) and one or more copies of the data (hereinafter referred to as “clones”). For example, an organization may continuously copy data so that copies of the data are maintained in at least two places for subsequent retrieval operations.
The process of copying data from the source to a clone is referred to as mirroring. As changes are made to the source, the changes are replicated to the clone. Thus, a clone continuously represents an up-to-date point-in-time copy of the source.
It may be desirable to restore source data using clone data. The process of copying data from a clone to a source is referred to as a reverse sync operation. During a reverse sync operation, requests to write data to the source (hereinafter referred to as “write requests”) may continue to be received and processed, where processing a write request received during a reverse sync includes writing the requested data to the source and replicating the change to the clone. Because changes resulting from received write requests are automatically replicated to the clone during a reverse sync operation, the clone being copied from may continue to be updated during the reverse sync. While a reverse sync performed while updating a clone ensures that a clone accurately represents the most recent point-in-time copy of its source, it does not allow the user to restore the source to a snapshot of the source as it existed at an arbitrary point in the past, because the clone data can be overwritten with new data.
Because a user may wish to cease automatic mirroring of changes to the clone so that the clone may represent a complete point-in-time copy of the source for a specific time in the past, conventional data storage systems provide for logically disconnecting, or fracturing, a clone from its source by discontinuing copying of data from the source to the clone. Upon fracturing, a fractured clone may represent a point-in-time copy of the source at the time it was fractured. Thus, in order to create multiple copies of the source corresponding to multiple points in time, a user may fracture one or more clones at different times. For example, a user operating a data storage system including a source and seven clones may fracture a different clone each day of the week. Therefore, the source may be restored to any day during the previous week by initiating a reverse sync with the appropriate clone.
It may be desirable to restore source data using clone data from a fractured clone. The process of copying data from a fractured clone to a source is referred to as a protected restore operation. During a protected restore operation, data is copied from the clone to the source while changes to the source made as a result of write requests received during the protected restore operation are not replicated to the clone. Therefore, the integrity of the fractured clone is protected during the protected restore operation.
In addition to receiving write requests, read requests may be received during a protected restore operation. However, the processing of read requests received during a protected restore operation may produce undesirable results if the requested data has not yet been copied from the clone back to its source. For example, upon initiating a protected restore operation, the process of copying data from the clone to the source may appear to the user to occur instantly. However, depending on a number of factors, such as the amount of data to be copied and the speed of the physical data storage devices, the process of copying data during a reverse sync may not occur instantly. Instead, a significant amount of time may be required to complete a protected restore operation. Thus, read requests may be received during the execution of a protected restore operation which are directed to data that has not yet been copied back to its source.
One conventional solution for processing read requests received during a protected restore operation includes queuing a read request if it is determined that the requested data is located on the clone (i.e. it has not yet been copied back to the source). In some implementations, this determination may be made by detecting whether the requested data content on the source is different from the corresponding data content on the clone. For example, source and clone data may be divided into one or more contiguous data blocks hereinafter referred to as extents. If the read request is directed to a source extent which differs from the corresponding clone extent, the read request is queued so that the extent may be copied to the source before the data is read from the source.
One problem with the conventional processing of read requests received during a restore operation described above (i.e. queuing read requests) is that as the number of queued read requests increases, the degradation in host read performance also increases. Specifically, in data storage systems where protected restore operations require significant periods of time to complete, the time required to process read requests received during a protected restore operation may be unacceptably long.
Accordingly, a need exists for improved methods, systems, and computer program products for processing read requests received during a protected restore operation.
USPTO Backgrounds
USPTO Backgrounds