Abstract:
A method for releasing storage space in a space-efficient volume is disclosed. In one embodiment, such a method includes maintaining, for a space-efficient volume, a bitmap comprising a bit for each track in the space-efficient volume. A host system indicates whether a track is one of used and unused by marking the corresponding bit in the bitmap. A storage controller reads the bitmap and frees tracks from the space-efficient volume that the bitmap indicates are unused. In certain embodiments, the bitmap is stored on the space-efficient volume. For example, the bitmap may be appended to a volume table of contents (VTOC) stored on the space-efficient volume. A corresponding system and computer program product are also disclosed.

Description:
BACKGROUND 
     Field of the Invention 
     This invention relates to systems and methods for more effectively reclaiming space in space-efficient FlashCopy volumes. 
     Background of the Invention 
     On storage systems such as the IBM DS8000™ enterprise storage system, FlashCopy is a function used to create nearly instantaneous point-in-time copies of volumes or data sets. These point-in-time copies may be used for backups and other purposes. Once created, the point-in-time copies are immediately available for both read and write access. Space Efficient FlashCopy is a function similar to conventional FlashCopy except that space-efficient volumes created with this function are not allocated all their defined storage space at the time of creation. Rather, storage space is allocated when data is actually written to a space-efficient volume. This allows the space-efficient volumes to be thinly provisioned, which reduces the amount of physical storage space needed to back the space-efficient volumes. Space Efficient FlashCopy achieves the aforementioned space efficiency by pooling physical storage requirements of many space-efficient volumes in a common repository. A mapping structure is used to keep track of where the space-efficient volumes&#39; data is physically located within the repository. 
     While physical storage space may be allocated to space-efficient volumes when needed, the same physical storage space may be reclaimed from the space-efficient volumes when it is no longer needed. Currently, when tracks are deleted by host-system-based software, the DS8000™ storage controller relies on updates to its metadata to release the tracks from a space-efficient volume. More specifically, the DS8000™ storage controller relies on certain metadata associated with the tracks to be overwritten with zeros or marked to indicate that the tracks need to be removed from the space-efficient volume. This metadata is later scanned by the storage controller to identify which tracks should be removed. Once identified, the storage controller may add the tracks to a free storage pool to be used for future allocations. Over time, events such as errors or miscommunications may occur which may result in the required metadata not being zeroed out correctly. For example, if software on a host system deletes a data set or particular tracks of a data set, the software on the host system may notify the storage controller so that the storage controller can release the tracks back into the free storage pool. If the notifications from the software are lost or not properly registered or handled by the storage controller, the tracks may not be released back into the free storage pool. Over time this may result in storage space in the storage system that is not utilized, but nevertheless tied up and unavailable for use. 
     In view of the foregoing, what are needed are systems and methods to more effectively reclaim space in space-efficient point-in-time-copy volumes. Ideally, such systems and methods will prevent situations where tracks, even though deleted or marked as unused by a host system, are not released to a free storage pool by the storage controller. 
     SUMMARY 
     The invention has been developed in response to the present state of the art and, in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available systems and methods. Accordingly, the invention has been developed to provide systems and methods to more effectively reclaim space in space-efficient FlashCopy volumes. The features and advantages of the invention will become more fully apparent from the following description and appended claims, or may be learned by practice of the invention as set forth hereinafter. 
     Consistent with the foregoing, a method for releasing storage space in a space-efficient volume is disclosed. In one embodiment, such a method includes maintaining, for a space-efficient volume, a bitmap comprising a bit for each track in the space-efficient volume. A host system indicates whether a track is one of used and unused by marking the corresponding bit in the bitmap. A storage controller reads the bitmap and frees tracks from the space-efficient volume that the bitmap indicates are unused. In certain embodiments, the bitmap is stored on the space-efficient volume. For example, the bitmap may be appended to a volume table of contents (VTOC) stored on the space-efficient volume. A corresponding system and computer program product are also disclosed and claimed herein. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the embodiments of the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which: 
         FIG. 1  is a high-level block diagram showing one example of a network architecture in which a system and method in accordance with the invention may be implemented; 
         FIG. 2  is a high-level block diagram showing one example of a storage system hosting one or more space efficient volumes; 
         FIG. 3  is a high-level block diagram showing logical volumes exposed by the storage system, and particularly showing a volume table of contents (VTOC) and data sets stored on a logical volume; 
         FIG. 4  is a high-level block diagram showing the use of space-efficient logical volumes for storing point-in-time copies; and 
         FIG. 5  is a high-level block diagram showing use of a free space bitmap by both a host system and storage controller. 
     
    
    
     DETAILED DESCRIPTION 
     It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. 
     The present invention may be embodied as a system, method, and/or computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention. 
     The computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire. 
     Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device. 
     Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on a user&#39;s computer, partly on a user&#39;s computer, as a stand-alone software package, partly on a user&#39;s computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, a remote computer may be connected to a user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention. 
     Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable program instructions. 
     These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks. 
     The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     Referring to  FIG. 1 , one example of a network architecture  100  is illustrated. The network architecture  100  is presented to show one example of an environment where an apparatus and method in accordance with the invention may be implemented. The network architecture  100  is presented only by way of example and not limitation. Indeed, the apparatus and methods disclosed herein may be applicable to a wide variety of network architectures, in addition to the network architecture  100  shown. 
     As shown, the network architecture  100  includes one or more computers  102 ,  106  interconnected by a network  104 . The network  104  may include, for example, a local-area-network (LAN)  104 , a wide-area-network (WAN)  104 , the Internet  104 , an intranet  104 , or the like. In certain embodiments, the computers  102 ,  106  may include both client computers  102  and server computers  106  (also referred to herein as “host systems”  106 ). In general, the client computers  102  initiate communication sessions, whereas the server computers  106  wait for requests from the client computers  102 . In certain embodiments, the computers  102  and/or servers  106  may connect to one or more internal or external direct-attached storage systems  112  (e.g., arrays of hard-disk drives, solid-state drives, tape drives, etc.). These computers  102 ,  106  and direct-attached storage systems  112  may communicate using protocols such as ATA, SATA, SCSI, SAS, Fibre Channel, or the like. 
     The network architecture  100  may, in certain embodiments, include a storage network  108  behind the servers  106 , such as a storage-area-network (SAN)  108  or a LAN  108  (e.g., when using network-attached storage). This network  108  may connect the servers  106  to one or more storage systems  110 , such as arrays  110   a  of hard-disk drives or solid-state drives, tape libraries  110   b , individual hard-disk drives  110   c  or solid-state drives  110   c , tape drives  110   d , CD-ROM libraries, or the like. To access a storage system  110 , a host system  106  may communicate over physical connections from one or more ports on the host  106  to one or more ports on the storage system  110 . A connection may be through a switch, fabric, direct connection, or the like. In certain embodiments, the servers  106  and storage systems  110  may communicate using a networking standard such as Fibre Channel (FC). 
     Referring to  FIG. 2 , one embodiment of a storage system  110   a  containing an array of hard-disk drives  204  and/or solid-state drives  204  is illustrated. As shown, the storage system  110   a  includes a storage controller  200 , one or more switches  202 , and one or more storage devices  204 , such as hard disk drives  204  or solid-state drives  204  (such as flash-memory-based drives  204 ). The storage controller  200  may enable one or more hosts  106  (e.g., open system and/or mainframe servers  106  running operating systems such as MVS, z/OS, or the like) to access data in the one or more storage devices  204 . 
     In selected embodiments, the storage controller  200  includes one or more servers  206 . The storage controller  200  may also include host adapters  208  and device adapters  210  to connect the storage controller  200  to host devices  106  and storage devices  204 , respectively. Multiple servers  206   a ,  206   b  may provide redundancy to ensure that data is always available to connected hosts  106 . Thus, when one server  206   a  fails, the other server  206   b  may pick up the I/O load of the failed server  206   a  to ensure that I/O is able to continue between the hosts  106  and the storage devices  204 . This process may be referred to as a “failover.” 
     One example of a storage system  110   a  having an architecture similar to that illustrated in  FIG. 2  is the IBM DS8000™ enterprise storage system. The DS8000™ is a high-performance, high-capacity storage controller providing disk storage that is designed to support continuous operations. Nevertheless, the apparatus and methods disclosed herein are not limited to operation with the IBM DS8000™ enterprise storage system  110   a , but may operate with any comparable or analogous storage system  110 , regardless of the manufacturer, product name, or components or component names associated with the system  110 . Furthermore, any storage system that could benefit from one or more embodiments of the invention is deemed to fall within the scope of the invention. Thus, the IBM DS8000™ is presented only by way of example and is not intended to be limiting. 
     In selected embodiments, each server  206  may include one or more processors  212  and memory  214 . The memory  214  may include volatile memory (e.g., RAM) as well as non-volatile memory (e.g., ROM, EPROM, EEPROM, hard disks, flash memory, etc.). The volatile and non-volatile memory may, in certain embodiments, store software modules that run on the processor(s)  212  and are used to access data in the storage devices  204 . The servers  206  may host at least one instance of these software modules. These software modules may manage all read and write requests to logical volumes in the storage devices  204 . 
     Referring to  FIG. 3 , in certain embodiments, a storage system  110  such as that illustrated in  FIG. 2  may be configured to present or expose one or more volumes  300   a - j  to a host system  106 . The volumes  300  may be logical volumes  300 , meaning that the volumes  300  may appear to be physical drives  204  (e.g., hard drives, solid state drives, etc.) to a host system  106  but do not necessarily directly correlate to physical drives  204  on the storage system  110 . For example, in certain embodiments, a physical drive  204  may be used by more than one logical volume  300  or a logical volume  300  may span all or part of multiple physical drives  204 . A storage virtualization layer  302  within the storage system  110  or may expose the logical volumes  300  and handle the mapping between the logical volumes  300  and the physical drives  204 . 
     As further shown in  FIG. 3 , in certain embodiments, each logical volume  300  may store a volume table of contents (VTOC)  304  and one or more data sets  306 . A VTOC  304  may contain information for locating data sets  306  on the associated logical volume  300 . In certain embodiments, the VTOC  304  is located at the beginning of the logical volume  300  and may list the names of each data set  306  on the logical volume  300  as well as the data set&#39;s size, location, and permissions. The VTOC  304  may also store information describing each area of contiguous free space in the logical volume  300 . The VTOC  304  is typically created at the time the logical volume  300  is initialized. 
     To access a particular data set  306  on a storage system  110 , a host  106  may query a host-based catalog to determine the logical volume  300  on which the data set  306  resides. Once the correct logical volume  300  is determined, the host  106  locates the VTOC  304  on the logical volume  300  and searches the VTOC  304  to determine where the data set  306  is stored. The host  106  may then access the data set  306  at the determined location. 
     In general, a host  106  and host-system-based software is able to recognize, understand, and utilize the VTOC  304  to access data sets  306  on the logical volume  300 . However, the storage controller  200  hosting the logical volume  300  typically will not recognize or understand the VTOC  304 . Instead, the storage controller  200  may store and maintain internal metadata  216  (See  FIG. 2 ) in its memory  214  to understand the configuration of a logical volume  300 . 
     Referring to  FIG. 4 , as previously mentioned, on storage systems such as the IBM DS8000™ enterprise storage system, FlashCopy is a function used to create nearly instantaneous point-in-time copies of volumes  300  or data sets  306  on a storage system  110 . These point-in-time copies may be used for backups or other purposes. Once created, the point-in-time copies are immediately available for both read and write access to host systems  106 . Space Efficient FlashCopy is a function similar to conventional FlashCopy except that space-efficient volumes  300   b  created with this function are not allocated all their defined storage space at the time of creation. Rather, storage space is allocated when data is actually written to a space-efficient volume  300   b.    
       FIG. 4  shows a scenario where space-efficient logical volumes  300   b  are created to store point-in-time copies of data in corresponding source logical volumes  300   a . When the space-efficient logical volumes  300   b  are created, no physical space may be allocated to the space-efficient logical volumes  300   b . Rather, space may be allocated to the space-efficient logical volumes  300   b  on an as-need basis. For example, when new data is written to a track  400   a  of a source logical volume  300   a , the old data in the track  400   a  may be copied over to the associated space-efficient logical volume  300   b  in order to preserve the point-in-time copy of the data. 
     When the data is copied over, a track  400   b  may be allocated to the space-efficient logical volume  300   b  from a repository  402  of free tracks in order to store the old data. In this way, tracks may be allocated to space-efficient logical volumes  300   b  if and when they are needed, providing more efficient utilization of storage space. This also allows the space-efficient logical volumes  300   b  to be over-provisioned, meaning that the space-efficient logical volumes  300   b  may be logically larger than the amount of physical storage space backing them. 
     When a track is no longer being used in a space-efficient logical volume  300   b , such as when a track of data or an entire data set  306  has been deleted from the space-efficient logical volume  300   b , the track may be released to the repository  402  so that it can be used again either in the same or different space-efficient logical volume  300   b . In conventional implementations, if a host system  106  or host-system-based software deletes data, a volume space manager  508  (See  FIG. 5 ) on the host system  106  updates the VTOC  304  to indicate that the storage space used to store the data is no longer in use. The volume space manager  508  then notifies the storage controller  200  that the storage space is no longer being used. A space reclamation module  510  (See  FIG. 5 ) on the storage controller  200  may, in turn, update the track or tracks formerly used to store the data (such as by writing all zeros to the track or tracks) or update the internal metadata  216  of the storage controller  200  to indicate that the tracks are no longer in use. The space reclamation module  510  may then periodically scan the tracks and/or the metadata  216  to determine which tracks have been zeroed out or marked, and then release the tracks to the repository  402  so that they can be used again. 
     Unfortunately, scenarios may occur where storage space that is freed by a volume space manager  508  on the host system  106  is not released to the repository  402  by the storage controller  200 . Because the space reclamation module  510  on the storage controller  200  relies on notifications from the volume space manager  508  on the host system  106  to identify tracks to release to the repository  402 , these tracks may not be released if the notifications are not received or logged correctly by the storage controller  200 . Lost or incorrectly logged notifications may be the result of errors, miscommunications, code glitches, or the like. Over time, tracks that are not properly released may result in storage space in the storage system  110  that is not utilized, but nevertheless tied up and unavailable for use. 
     Referring to  FIG. 5 , in certain embodiments in accordance with the invention, a new data structure may be created that allows a host system  106  and storage controller  200  to coordinate the release of storage space back to the repository  402 . In certain embodiments, this new data structure may be stored in the VTOC  304  previously discussed. Since a storage controller  200  may not normally recognize and/or understand a VTOC  304 , various mechanisms may be put in place to enable a space reclamation module  510  on the storage controller  200  to identify and utilize the new data structure in the VTOC  304 . In other embodiments, the new data structure is located on a space efficient logical volume  300  outside of a VTOC  304 , such as in a data set  306  or other location external to the VTOC  304 . 
     In certain embodiments, the new data structure is a bitmap  506 , where each bit in the bitmap  506  represents a storage area in a space-efficient logical volume  300   b . For example, each bit in the bitmap  506  may represent a track in the space-efficient logical volume  300   b . When a host system  106  or host-system-based software uses or releases a track, the volume space manager  508  on the host system  106  may mark the corresponding bit in the bitmap  506  to indicate that the track is either used or unused. The space reclamation module  510  on the storage controller  200  may, in turn, periodically scan the bitmap  506  to determine which tracks to release to the repository  402 . If a bit for a track is marked as unused, the space reclamation module  510  may release the corresponding track to the repository  402 . In certain embodiments, the bitmap  506  is embodied as a new type of data set control block (DSCB)  500  in the VTOC  304 . However, unlike other data set control blocks  500  (e.g., data set descriptor DSCBs  502 , free space descriptor DSCBs  504 , etc.), the new bitmap  506  may be recognized and utilized not only by a host system  106 , but also by a storage controller  200 . 
     When a volume space manager  508  on a host system  106  changes the status of a track in a logical volume  300 , such as by changing the track status from used to unused, or unused to used, the volume space manager  508  may update the bitmap  506  to reflect the new status. To accomplish this, the volume space manager  508  may acquire a lock on the track storing the bitmap  506  to ensure that the storage controller  200  or other processes can&#39;t access the bitmap  506  while updates are being made. The volume space manager  508  may then update the bitmap  506  to reflect the new status and release the lock when the operation is complete. The space reclamation module  510  in the storage controller  200  may likewise acquire a lock on the bitmap  506  when the bitmap  506  is analyzed or updated. This will ensure that neither the host system  106  nor storage controller  200  overwrites a pending operation. If the storage controller  200  attempts to access the bitmap  506  while the host system  106  has a lock, the storage controller  200  may need to wait until the lock is released to access the bitmap  506 , and vice versa. 
     As mentioned above, various mechanisms may be put in place to enable a storage controller  200  to find and utilize the bitmap  506  on a space-efficient logical volume  300   b . In one embodiment, the bitmap  506  is created and registered with the storage controller  200  at the time a space-efficient logical volume  300   b  is initialized. This will allow the storage controller  200  to store the location of the bitmap  506  in its internal metadata  216  so that unused tracks can be determined and released. If a logical volume  300  is reinitialized in a way that changes the location of the bitmap  506 , the bitmap  506  may be reregistered with the storage controller  200 . 
     In another embodiment, a unique identifier is stored on the space-efficient logical volume  300   b  with the bitmap. This may enable a storage controller  200  to locate the bitmap by scanning the logical volume  300  for the unique identifier. In yet another embodiment, the storage controller  200  may be updated to have knowledge of the VTOC  304 , there enabling the storage controller  200  to scan the VTOC  304  and locate the bitmap  506 . Other techniques for enabling the storage controller  200  to locate and identify the bitmap  506  are possible and within the scope of the invention. 
     The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other implementations may not require all of the disclosed steps to achieve the desired functionality. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.