Migrating data from a large extent pool to a small extent pool

A computer-implemented method according to one embodiment includes identifying a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, creating a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrating data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

BACKGROUND

The present invention relates to data migration, and more specifically, this invention relates to migrating data from a first extent pool to a second extent pool with a smaller granularity than the first extent pool.

Extent pools in storage products may have different extent sizes. For example, a 1 GB extent size may be implemented for a large extent pool and a 16 MB extent size may be implemented for a small extent pool. Some workloads may perform better in a small extent pool when compared to a large extent pool. However, current methods to transfer data are expensive, and involve using a host to copy the data or implementing a flash copy. There is therefore a need to efficiently migrate volumes from large extent pools to small extent pools.

SUMMARY

A computer-implemented method according to one embodiment includes identifying a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, creating a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrating data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool without having to use a host to copy the data or implement a flash copy. This reduces an amount of time and resources of one or more systems performing the data migration, which improves a performance of the one or more systems.

In one optional embodiment, creating the correspondence includes identifying VST entries within the volume that correspond to rank extents within the source storage pool that contain the data to be migrated, and creating a small VST for each identified VST entry.

According to another embodiment, a computer program product for migrating data from a large extent pool to a small extent pool includes a computer readable storage medium that has program instructions embodied therewith, where the computer readable storage medium is not a transitory signal per se, and where the program instructions are executable by a processor to cause the processor to perform a method including identifying, utilizing the processor, a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, creating, utilizing the processor, a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrating, utilizing the processor, data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

A system according to another embodiment includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor, where the logic is configured to identify a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, create a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrate data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

A computer-implemented method according to another embodiment includes identifying a request to migrate data associated with a volume from a source storage pool to a destination storage pool, identifying volume segment table (VST) entries corresponding to rank extents within the source storage pool containing the data, allocating and synchronizing small VSTs for the identified VST entries within the volume, allocating one or more rank extents within the destination storage pool, transferring the data associated with the volume from the rank extents within the source storage pool containing the data to the one or more rank extents in the one or more ranks of the destination storage pool, updating the small VSTs to correspond to the transferred data in the one or more rank extents in the one or more ranks of the destination storage pool, and freeing the data from the one or more rank extents within the source storage pool.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool. This may improve a performance of applications accessing the data in the destination storage pool, as the applications may perform better when utilizing smaller rank extents.

According to another embodiment, a computer program product for migrating data from a large extent pool to a small extent pool includes a computer readable storage medium having program instructions embodied therewith, where the computer readable storage medium is not a transitory signal per se, and where the program instructions are executable by a processor to cause the processor to perform a method including identifying, utilizing the processor, a request to migrate data associated with a volume from a source storage pool to a destination storage pool, identifying, utilizing the processor, VST entries corresponding to rank extents within the source storage pool containing the data, allocating and synchronizing, utilizing the processor, small VSTs for each of the identified VST entries within the volume, allocating, utilizing the processor, one or more rank extents within the destination storage pool, transferring, utilizing the processor, the data associated with the volume from the rank extents within the source storage pool containing the data to the one or more rank extents in the one or more ranks of the destination storage pool, updating, utilizing the processor, the small VSTs to correspond to the transferred data in the one or more rank extents in the one or more ranks of the destination storage pool, and freeing, utilizing the processor, the data from the one or more rank extents within the source storage pool.

DETAILED DESCRIPTION

The following description discloses several preferred embodiments of systems, methods and computer program products for migrating data from a large extent pool to a small extent pool. Various embodiments provide a method to create a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrate data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence.

The following description discloses several preferred embodiments of systems, methods and computer program products for migrating data from a large extent pool to a small extent pool.

In one general embodiment, a computer-implemented method includes identifying a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, creating a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrating data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool without having to use a host to copy the data or implement a flash copy. This reduces an amount of time and resources of one or more systems performing the data migration, which improves a performance of the one or more systems.

In another general embodiment, creating the correspondence includes identifying VST entries within the volume that correspond to rank extents within the source storage pool that contain the data to be migrated, and creating a small VST for each identified VST entry.

In another general embodiment, a computer program product for migrating data from a large extent pool to a small extent pool includes a computer readable storage medium that has program instructions embodied therewith, where the computer readable storage medium is not a transitory signal per se, and where the program instructions are executable by a processor to cause the processor to perform a method including identifying, utilizing the processor, a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, creating, utilizing the processor, a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrating, utilizing the processor, data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

In another general embodiment, a system includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor, where the logic is configured to identify a request to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size, create a correspondence between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool, and migrate data from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool.

In another general embodiment, a computer-implemented method includes identifying a request to migrate data associated with a volume from a source storage pool to a destination storage pool, identifying volume segment table (VST) entries corresponding to rank extents within the source storage pool containing the data, allocating and synchronizing small VSTs for the identified VST entries within the volume, allocating one or more rank extents within the destination storage pool, transferring the data associated with the volume from the rank extents within the source storage pool containing the data to the one or more rank extents in the one or more ranks of the destination storage pool, updating the small VSTs to correspond to the transferred data in the one or more rank extents in the one or more ranks of the destination storage pool, and freeing the data from the one or more rank extents within the source storage pool.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool. This may improve a performance of applications accessing the data in the destination storage pool, as the applications may perform better when utilizing smaller rank extents.

In another general embodiment, a computer program product for migrating data from a large extent pool to a small extent pool includes a computer readable storage medium having program instructions embodied therewith, where the computer readable storage medium is not a transitory signal per se, and where the program instructions are executable by a processor to cause the processor to perform a method including identifying, utilizing the processor, a request to migrate data associated with a volume from a source storage pool to a destination storage pool, identifying, utilizing the processor, VST entries corresponding to rank extents within the source storage pool containing the data, allocating and synchronizing, utilizing the processor, small VSTs for each of the identified VST entries within the volume, allocating, utilizing the processor, one or more rank extents within the destination storage pool, transferring, utilizing the processor, the data associated with the volume from the rank extents within the source storage pool containing the data to the one or more rank extents in the one or more ranks of the destination storage pool, updating, utilizing the processor, the small VSTs to correspond to the transferred data in the one or more rank extents in the one or more ranks of the destination storage pool, and freeing, utilizing the processor, the data from the one or more rank extents within the source storage pool.

Now referring toFIG. 3, a storage system300is shown according to one embodiment. Note that some of the elements shown inFIG. 3may be implemented as hardware and/or software, according to various embodiments. The storage system300may include a storage system manager312for communicating with a plurality of media on at least one higher storage tier302and at least one lower storage tier306. The higher storage tier(s)302preferably may include one or more random access and/or direct access media304, such as hard disks in hard disk drives (HDDs), nonvolatile memory (NVM), solid state memory in solid state drives (SSDs), flash memory, SSD arrays, flash memory arrays, etc., and/or others noted herein or known in the art. The lower storage tier(s)306may preferably include one or more lower performing storage media308, including sequential access media such as magnetic tape in tape drives and/or optical media, slower accessing HDDs, slower accessing SSDs, etc., and/or others noted herein or known in the art. One or more additional storage tiers316may include any combination of storage memory media as desired by a designer of the system300. Also, any of the higher storage tiers302and/or the lower storage tiers306may include some combination of storage devices and/or storage media.

The storage system manager312may communicate with the storage media304,308on the higher storage tier(s)302and lower storage tier(s)306through a network310, such as a storage area network (SAN), as shown inFIG. 3, or some other suitable network type. The storage system manager312may also communicate with one or more host systems (not shown) through a host interface314, which may or may not be a part of the storage system manager312. The storage system manager312and/or any other component of the storage system300may be implemented in hardware and/or software, and may make use of a processor (not shown) for executing commands of a type known in the art, such as a central processing unit (CPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc. Of course, any arrangement of a storage system may be used, as will be apparent to those of skill in the art upon reading the present description.

According to some embodiments, the storage system (such as300) may include logic configured to receive a request to open a data set, logic configured to determine if the requested data set is stored to a lower storage tier306of a tiered data storage system300in multiple associated portions, logic configured to move each associated portion of the requested data set to a higher storage tier302of the tiered data storage system300, and logic configured to assemble the requested data set on the higher storage tier302of the tiered data storage system300from the associated portions.

Now referring toFIG. 4, a flowchart of a method400is shown according to one embodiment. The method400may be performed in accordance with the present invention in any of the environments depicted inFIGS. 1-3 and 6A-D, among others, in various embodiments. Of course, more or less operations than those specifically described inFIG. 4may be included in method400, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG. 4, method400may initiate with operation402, where a request is received to migrate data associated with a volume from a source storage pool having a first rank extent size to a destination storage pool having a second rank extent size smaller than the first rank extent size.

Additionally, method400may proceed with operation404, where a correspondence is created between logical volume extents of the volume and physical offset locations within rank extents of the source storage pool. In one embodiment, creating the correspondence includes identifying VST entries within the volume that correspond to rank extents within the source storage pool that contain the data to be migrated. For example, a VST may store a logical representation of data stored within the volume, where the VST includes a plurality of entries. A subset of these entries may be identified within the VST that correspond to rank extents within the source storage pool that contain the data to be migrated.

Further, in one embodiment, creating the correspondence may include creating a small VST for each identified VST entry. For example, for each of the identified subset of VST entries, a small VST may be created. In another example, each of the small VSTs may be used to represent all of the logical volume extents within their corresponding VST entry at a higher granularity.

Further, in one embodiment, creating the correspondence may include setting the logical volume extents within the small VSTs to point to corresponding offset locations within the rank extents within the source storage pool that contain the data to be migrated. In this way, a direct correspondence may be established between the logical volume extents of the small VSTs of the volume and the offset locations within the rank extents within the source storage pool that contain the data to be migrated.

Further still, method400may proceed with operation406, where data is migrated from one or more ranks of the source storage pool to one or more ranks of the destination storage pool, utilizing the correspondence between the logical volume extents of the volume and the physical offset locations within the rank extents of the source storage pool. In one embodiment, migrating the data may include selecting a plurality of rank extents within the destination storage pool to receive the migrated data. For example, the plurality of rank extents may be selected randomly or according to one or more criteria (e.g., a rank numbering, a data retrieval speed of a corresponding rank, an amount of data currently being stored in the corresponding rank, etc.).

Also, in one embodiment, migrating the data may include transferring the data associated with the volume from one or more offset locations within the rank extents of the source storage pool to the selected plurality of rank extents within the destination storage pool.

In addition, in one embodiment, migrating the data may include freeing the data from the one or more rank extents within the source storage pool. In another embodiment, migrating the data may include adjusting the volume extents within the small VSTs to point to the corresponding locations of the migrated data within the selected plurality of rank extents of the destination storage pool that store the transferred data.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool without having to use a host to copy the data or implement a flash copy. This reduces an amount of time and resources of one or more systems performing the data migration, which improves a performance of the one or more systems.

Now referring toFIG. 5, a flowchart of a method500for migrating data from a source storage pool to a destination storage pool having a smaller extent granularity than the source pool is identified is shown according to one embodiment. The method500may be performed in accordance with the present invention in any of the environments depicted inFIGS. 1-3 and 6A-D, among others, in various embodiments. Of course, more or less operations than those specifically described inFIG. 5may be included in method500, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG. 5, method500may initiate with operation502, where a request to migrate data associated with a volume from a source storage pool to a destination storage pool is identified. In one embodiment, the volume includes a storage volume that organizes and presents a logical representation of the data in a contiguous manner to one or more hosts. In another embodiment, the volume includes a plurality of volume extents. For example, each volume extent may include a logical extent.

Additionally, in one embodiment, a storage pool includes one or more ranks. In another embodiment, each rank includes a redundant amount of storage (e.g., a RAID storage array, etc.). In yet another embodiment, data logically represented in the volume is physically stored in one or more ranks of a storage pool. For example, in one embodiment, each rank includes a plurality of rank extents.

Further, in one embodiment, the extents within a rank are represented as entries within a rank segment table (RST) for the rank, where each rank extent is either full or empty. For example, each rank extent represents a physical extent. In another example, each rank extent represents a predetermined amount of storage for storing data within the storage pool. In yet another example, full rank extents include a logical location of data within the volume (e.g., an identification of a volume and a volume extent within that volume where the data is logically stored and presented to one or more hosts).

Further still, in one embodiment, the source storage pool includes one or more ranks that initially store all data logically represented in the volume. In another embodiment, the data logically represented in the volume is physically stored in multiple ranks within the source storage pool.

Also, in one embodiment, the source storage pool has a first rank extent size, and the destination storage pool has a second rank extent size smaller than the first rank extent size. For example, the source storage pool may have rank extents with a size of 1 GB, and the second extent pool may have rank extents with a size of 16 MB.

In addition, method500may proceed with operation504, where VST entries corresponding to rank extents within the source storage pool containing the data are identified. In one embodiment, the volume extents are grouped within entries of a volume segment table (VST), where each volume extent is either full or empty. For example, in one embodiment, full volume extents include a physical location of data within the source storage pool (e.g., an identification of a rank and a rank extent within that rank where the data associated with the volume extent is stored). In another example, each entry of a VST includes a predetermined number of consecutive volume extents. In yet another example, the VST maps the logical extents of the volume (e.g., the volume extents) to physical extents of one or more ranks within a storage pool (e.g., rank extents).

Furthermore, method500may proceed with operation506, where small VSTs are allocated and synchronized for the identified VST entries within the volume. In one embodiment, small VSTs represent and manage the entries of the VST with a higher granularity. For example, each entry of the VST includes a grouped plurality of volume extents identified only by a VST entry number. In another example, a single VST entry may be represented by a small VST having entries corresponding to each of the plurality of volume extents grouped within the single VST entry.

Further still, in one embodiment, synchronizing the small VSTs may include setting the logical volume extents within each of the small VSTs to point to corresponding offset locations within the rank extents within the source storage pool that contain the data to be migrated. For example, the offset locations of a rank extent represent a logical rank extent number within a logical representation of the rank extent (e.g., that indicates a predetermined portion of the rank extent). In another example, a rank extent of size 1 GB may have a plurality of offset locations that each represent 16 MB portions of the rank extent (such that a single 1 GB rank extent would have sixty-four 16 MB offset locations, etc.). This allows for a representation of a rank extent at a higher granularity.

In another embodiment, synchronizing the small VSTs may include populating the small VSTs so that they include volume extents that contain offset locations within a corresponding rank extent within the source storage pool. In this way, the entries within the small VSTs are populated such that an organization (e.g., order, numbering, etc.) of entries within the small VSTs match an organization of offset locations within allocated rank extents corresponding to the small VSTs.

Also, method500may proceed with operation508, where one or more rank extents are allocated within the destination storage pool. In one embodiment, a number of rank extents allocated within the destination storage pool corresponds to a size of the volume. For example, a total size of data logically represented by the volume is allocated within the destination storage pool. In another example, the total size of the data logically represented by the volume is divided by a rank extent size of the destination storage pool to determine a number of rank extents that are allocated within the destination storage pool. In another embodiment, the one or more rank extents are allocated randomly, serially, non-serially, etc.

Additionally, in one embodiment, the one or more rank extents may be allocated according to one or more criteria. For example, the one or more rank extents may be allocated based on a data retrieval speed of the ranks within the destination storage pool. For instance, each of the ranks may be listed in order of decreasing data retrieval speed, and extents may be allocated in ranks according to the list (e.g., starting with ranks having a fastest data retrieval speed, etc.).

In another example, the one or more rank extents may be allocated based on an amount of data of data currently being stored in each of the ranks within the destination storage pool. For instance, the ranks may be listed in order of a decreasing amount of currently available storage space, and extents may be allocated in ranks according to the list (e.g., starting with ranks having most currently available extents, etc.).

In addition, method500may proceed with operation510, where the data associated with the volume is transferred from the rank extents within the source storage pool containing the data to the one or more rank extents in the one or more ranks of the destination storage pool. In one embodiment, transferring the data includes determining a location of all offset locations within the rank extents of one or more RSTs of the source storage pool that correspond to all previously allocated volume extents within the volume. In another embodiment, transferring the data includes determining all allocated rank extents within the destination storage pool.

Further still, in one embodiment, transferring the data includes transferring the data stored in the offset locations of the rank extents within the source storage pool to the corresponding allocated rank extents within the destination storage pool. For example, data stored in an offset location of a rank extent of a rank of the source storage pool is transferred to an allocated rank extent of the destination storage pool.

Also, method500may proceed with operation512, where the small VSTs are updated to correspond to the transferred data in the one or more rank extents in the one or more ranks of the destination storage pool. For example, volume extents are adjusted within small VSTs of the volume to point to the corresponding locations within the allocated one or more rank extents of the destination storage pool that store the transferred data.

Additionally, method500may proceed with operation514, where the data is freed from the one or more rank extents within the source storage pool. In one embodiment, freeing the data may include deleting the data from the one or more rank extents within the source storage pool.

For example, a volume extent within a small VST originally identifies an offset location within a logical representation of a rank extent in the source storage pool where the data logically represented by that volume extent is physically stored. In another example, the volume extent is updated within the small VST to identify the allocated rank extent of the destination storage pool where the data associated with the volume extent was migrated. In yet another example, the stored data is migrated from the offset location within the logical representation of the rank extent in the source storage pool to an allocated rank extent of the destination storage pool.

In this way, volume extents within the small VSTs of the volume match the allocated rank extents in the destination storage pool where data associated with those volume extents is stored. For example, a location of a volume extent within a small VST of the volume matches an allocated rank extent where data for the entry is stored. This simplifies and expedites data recall within the destination storage pool.

In one embodiment, one or more applications are provided access to the data at the destination storage pool. For example, one or more applications running on one or more hosts may send one or more data requests to the volume, and the volume may direct the data requests to the destination storage pool to implement data access. In another embodiment, the one or more applications may run more efficiently when accessing data using the smaller rank extent granularity within the destination storage pool compared to the larger rank extent granularity within the source storage pool.

In this way, data is migrated from a source storage pool to a destination storage pool having a rank extent size smaller than the rank extent size of the source storage pool. This may improve a performance of applications accessing the data in the destination storage pool, as the applications may perform better when utilizing smaller rank extents.

FIG. 6Aillustrates an exemplary storage environment600prior to a data migration, according to one embodiment. As shown, a VST602stores a logical representation of data stored within a volume 0604. Additionally, RSTs store a physical representation of the data as stored within a rank 3624of a source pool 0626. Also, the rank granularity of source pool 0626is 1 GB. For example, each rank extent within source pool 0626has a size of 1 GB.

Further, full volume extent VST entries632and634refer to locations630A-B within the RSTs where data is physically stored within source pool 0626. For example, rank extent 0630A of rank 3624of source pool 0626includes a link to VST entry 0632within volume 0604. Conversely, VST entry 0632within volume 0604includes a link to rank extent 0630A of rank 3624of source pool 0626.

Likewise, rank extent 64630B of rank 3624of source pool 0626includes a link to VST entry 2634within volume 0604. Conversely, VST entry 2634within volume 0604includes a link to rank extent 64630B of rank 3624of source pool 0626.

In this way, a connection between a logical representation of data in volume 0604is mapped to a physical representation of data in source pool 0626.

FIG. 6Billustrates an exemplary storage environment600in response to a migration request, according to one embodiment. The rank granularity of a destination pool 1622is 16 MB. For example, each rank extent within the destination pool 1622has a size of 16 MB. Since the rank granularity of the source pool 0626is 1 GB, the destination pool 1622has a smaller rank granularity than the source pool 0626.

In one embodiment, a request is received to migrate data from source pool 0626to destination pool 1622. In another embodiment, in response to the migration request, small VSTs614and616are created within volume 0604. For example, small VSTs614and616are used to represent the volume extents within VST entry 0632and VST entry 2634, respectively.

Additionally, in one embodiment, extents618A-E and619A-E within small VSTs614and616are updated to include links to corresponding offset locations640A-E and641A-E of allocated rank extents630A and630B. Logical representations636and638of offset locations640A-E and641A-E of allocated rank extents630A and630B are shown. For example, volume extent 0618A of small VST614may be updated to point to offset location 0640A of logical representation636of allocated rank extent 0630A, volume extent 1618B of small VST614may be updated to point to offset location 1640B of logical representation636of allocated rank extent 0630A, etc.

In this way, a correlation may be made between the extents618A-E and619A-E within small VSTs614and616and offset locations640A-E and641A-E of allocated rank extents630A and630B.

FIG. 6Cillustrates an exemplary storage environment600during a data migration from a source pool 0626to a destination pool 1622, according to one embodiment. As shown, rank extents620A-E and621A-E are allocated within destination rank 0610and destination rank 1612in the destination pool 1622. It should be noted that although the allocated rank extents620A-E and621A-E are serial, allocation may not be performed serially.

Additionally, although destination rank 0610and destination rank 1612are shown, rank extents from other ranks within the destination pool622may be allocated. For example, rank extents may be allocated amongst ranks within the destination pool622randomly, according to a data retrieval speed of the ranks, according to an amount of data currently being stored in the ranks, etc.

Further, as shown, data physically stored in offset location 0640A of rank 0630A of rank 3624has been transferred to rank extent 1621B of destination rank 1612, and volume extent 0618A of the small VST614is updated to point to rank extent 1621B. Conversely, rank extent 1621B of destination rank 1612of source pool 1622is updated to include a link to volume extent 0618A within volume 0604. This results in stale data at offset location 0640A.

Similarly, as shown, data physically stored in offset location 2640C has been transferred to rank extent 1620B of destination rank 0610, and volume extent 2618C of the small VST614is updated to point to rank extent 1620B. Conversely, rank extent 1620B of destination rank 0610of source pool 1622is updated to include a link to volume extent 2618C within volume 0604. This results in stale data at offset location 2640C.

Further, as shown, data physically stored in offset location 65641B has been transferred to rank extent 0621A of destination rank 1612, and volume extent 129619B of the small VST616is updated to point to rank extent 0621A. Conversely, rank extent 0621A of destination rank 1612of source pool 1622is updated to include a link to volume extent 129619B within volume 0604. This results in stale data at offset location 65641B.

Also, as shown, data physically stored in offset location 127641E has been transferred to rank extent 2620C of destination rank 0610, and volume extent 191619E of the small VST616is updated to point to rank extent 2620C. Conversely, rank extent 2620C of destination rank 0610of source pool 1622is updated to include a link to volume extent 191619E within volume 0604. This results in stale data at offset location 127641E.

FIG. 6Dillustrates an exemplary storage environment600after a data migration from a source pool 0626to a destination pool 1622, according to one embodiment. As shown, all data physically stored in rank extents 0630A and 64630B of source pool 0626is transferred to allocated rank extents within rank 0610and rank 1612of destination pool 1622. Additionally, corresponding volume extents in small VSTs614and616are updated to point to the corresponding rank extents that now store the migrated data.

This results in stale data in all offset locations of rank extents 0630A and 64630B, and data in such rank extents 0630A and 64630B is freed as a result.

In this way, data may be migrated from the source pool 0626to the destination pool 1622, and the volume 0604may be updated to reflect the migration.

Migration of Volumes from a Large Extent Pool to a Small Extent Pool

Extent pools in storage products could have different extent size. For example, DS8000 may use a 1 GB extent size for a large pool and a 16 MB for a small pool. Some workloads perform better using small pools, while others perform better in large extent pools. There is therefore a need to migrate volumes across different sized extent pools as the workload changes.

Extent migration is a building block of volume migration. At the beginning of extent migration, rank extents are allocated in the target extent pool as the migration target of the source extent. If the extent size is the source and target extent pool are same, the migration process includes allocating one extent in the target pool, migrating the data from a source to a target, holding backend I/O as migration is ongoing (or performing a mirror write), and switching I/O to the target once migration is complete.

A method is disclosed to migrate data from a large extent pool to a small extent pool in an efficient way, where migration is able to be resumed when it is interrupted (planned or unplanned).

In one embodiment, a Rank Segment Table (RST) is a mapping table for a rank (array) describing the state of rank extents and the logical volume extents that the physical rank extents belong to. For example, say rank rO is 1 T, and the extent size is 1 G, then this RST table would have 1024 entries, with each entry representing one physical extent. If rank extent 0 is allocated to logical extent 1 of volume 0x1010, then the entry in RST will have information indicating that the physical extent state is allocated, and it is allocated to logical extent 1 of volume 0x1010.

Additionally, in one embodiment, a Volume Segment Table (VST) is a mapping table for volumes that maps the logical extent of the volume to the physical extent of the rank, so that we can easily identify the physical location when host I/O arrives which is on a volume LBA boundary.

Further, in one embodiment, a Small Volume Segment Table (smVST) is also a mapping table for a volume that contains 64 entries with each entry map a small logical extent (16 MB) to the physical extent of the rank, so that we can easily identify a physical location when a host I/O arrives which is on a volume LBA boundary.

Further still, in one embodiment, only an RST is persistent in disks, and a VST is built and loaded into memory on demand based on the RST.

Also, in one embodiment, the following steps provide for extent migration from a large extent pool to a small extent pool:1. Pre-check to make sure the migration request can be fulfilled.2. Quiesce Thin Provisioning write if it is a Thin Provisioning volume.3. Update volume extent pool ID to targeting extent pool, turn on volume flag to indicate space allocation in progress and harden the volume structure.4. Allocate targeting RST objects for customer data.5. As for Thin Provisioning volume, if the source large extent is already allocated, allocate 64 small extents in the targeting extent pool and marked them as DSR_TGT. If the source extent is not allocated, there is no need to allocate small extents in the target pool.6. Allocate targeting RST objects for meta data.7. Resume Thin Provisioning write if it is a Thin Provisioning volume.8. Harden changed RST objects by using an RST changed bitmap.9. Quiesce Thin Provisioning write if it is a Thin Provisioning volume.10. Allocate smVST if all entries are in an unallocated state.11. Send mail to peer LPAR to sync smVST (This step is valid only for ESE volumes).12. Resume Thin Provisioning write if it is a Thin Provisioning volume.13. Turn off a volume allocation flag, turn on a volume migration flag and harden a volume structure.14. Proceed to migrate volume extents.15. Find a small extent in DSR_TGT state in the target pool and pair it with the source small extent chunk to start small extent migration; hold I/O in 16 MB unit.16. Switch to a metadata update phase once the 16 MB customer data from the source extent is all in the target.17. Change and harden the state of target RST to TGT_CMPLT state.18. Allocate a smVST if smVST does not yet exist.19. Initialize smVST entries to point to the related small chunks in a source large extent.20. Update smVST to point to the new target small extent on all available clusters.21. Release all held stage & destage I/O.22. CACHE SCAN to have CACHE destage all modified tracks in the extent.23. Free the source extent if it is the last small chunk to migrate to the target, otherwise, go back to step 15 to handle the next small chunk.24. Change and harden the state of target RST to an ALLOCATED state.

Method to Allocate Space and the Timing to Allocate/Update smVST Mapping Table

In one embodiment, space is pre-allocated in the targeting extent pool before migration starts. 1 GB large extent equals 64 16 MB small extents, so if the source large extent is allocated, there will be 64 small extents pre-allocated in the target pool. If the source large extent is not allocated yet, there is no need to provision space in the target pool either.

A smVST entry should be allocated for the 64 small extent chunks if the source is not allocated yet; that way, once I/O comes in writing to any of the 64 small extent chunks, we can allocate a small extent from the target small extent pool and update the smVST entry to point to the target small extent. The smVST update needs to be synced between storage nodes.

If the source large extent is in an allocated state, we can either still allocate the smVST beforehand, and update its entries to point to the related small chunks in the large extent, or delay the allocation of smVST to when the first 16 MB small chunk of the large extent has been migrated to the target small extent.

Method to Hold Backend I/O

In one embodiment, the backend I/O is held in a 16 MB small extent unit. During the migration of the 16 MB small chunk from the large extent to the related small extent in the target pool, backend I/O is written to both the source and target as migration is being performed from the source to target. Switching to a metadata update phase is performed once the customer data from the source small chunk is mostly in the target. Changing the target RST state to a TGT_CMPLT state indicates the copy is complete, and updating the related smVST entry is performed to point to the target extent so that I/O can be directed to the target afterwards.

Method to Handle Migration Interrupt Due to Planned/Unplanned Reboot

When migration is interrupted by a planned/unplanned reboot, part of the 1 GB data is in the source pool and the others are in the target pool. How do we choose which copy to use? How do we build the VST to map to the correct rank segments? In one embodiment, small always triumphs: The process may include scanning ranks and building a VST for each RST that's either in a TGT_CMPLT or ALLOCATED state. An RST from small ranks always overwrites an RST from large ranks. This is because the I/O has been switched to target a small extent if the small extent is already in a TGT_CMPLT or ALLOCATED state. Therefore, we need to overwrite the related smVST to point to the target small extent.