Abstract:
A storage system has a storage pool for at least one of a logical volume having a plurality of slices, a memory for storing a slice table indicating whether each slices of the logical volume is assigned from the storage pool or not, and a controller for receiving a release command for releasing one of the slices, sending out a response indicating the releasing of one of the slices corresponding to the release command has completed regardless of an execution of processing corresponding to the release command, duplicating a copy target area included in the one of the slices corresponding to the release command into a copy target volume included in the storage pool, and releasing the one of the slices upon completely duplicating the copy target area into the copy target volume.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2009-155929, filed on Jun. 30, 2009, the entire contents of which are incorporated herein by reference. 
       FIELD 
       [0002]    The present art relates to a storage system, a control apparatus and a method of controlling the control apparatus. 
       BACKGROUND 
       [0003]    With a recent increase in storage capacity required for storage devices, mechanisms for virtually allocating physical resources, including disks, have been received attention. In Thin Provisioning, one of such mechanisms, no correlation is made between a logical volume and a physical disk at the time of creation of the logical volume. The physical disk of a storage pool is dynamically allocated only when data is actually written by a host. 
         [0004]    In order to release the allocated physical volume in Thin Provisioning, the entire logical volume may be initialized or a certain area of the logical volume may be released specified by, for example, logical block address (LBA) in accordance with an initialization command issued by a host or other component. 
         [0005]    In Thin Provisioning, it is assumed that a host or other component issues an initialization command for a larger range than a normal I/O range during release of allocated physical volumes. In a copying function in which snapshots of a logical volume are created on an on-demand basis, however, data is written and the logical volume is released typically after areas corresponding to the copy source volume are synchronously copied to a copy destination volume during execution of an I/O or an initialization command for uncopied areas. 
         [0006]    As described above, since the copying process and the releasing process are performed asynchronously in response to the initialization command issued with respect to the logical volume to be copied on an on-demand basis, a response process indicating the releasing process has been completed may be delayed and the response may be degraded. 
         [0007]    Japanese Laid-Open Patent Publication No. 2007-310861 and Japanese Laid-Open Patent Publication No. 2006-48300 are examples of related art. 
       SUMMARY 
       [0008]    According to an aspect of an embodiment, a storage system has a storage pool for at least one of a logical volume having a plurality of slices, a memory for storing a slice table indicating whether each slices of the logical volume is assigned from the storage pool or not, and a controller for receiving a write request from a host, generating at least a slice in the logical volume by assigning a part of the storage pool according to the received write request and updating the slice table in the memory when the slice corresponding to the received write request is not assigned from the storage pool in reference to the slice table, and writing data into at least one of the slices according to the received write request, wherein the controller receives an release command for releasing one of the slices, sends out a response indicating the releasing of one of the slices corresponding to the release command has completed regardless of an execution of processing corresponding to the release command, duplicates a copy target area included in the one of the slices corresponding to the release command into a copy target volume included in the storage pool, and releases the one of the slices upon completely duplicating the copy target area into the copy target volume. 
         [0009]    The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims. 
         [0010]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0011]      FIG. 1  schematically illustrates allocation and releasing in typical Thin Provisioning; 
           [0012]      FIG. 2  is a flowchart illustrating a process in response to an initialization command in typical Thin Provisioning; 
           [0013]      FIG. 3  illustrates an exemplary configuration of a storage system according to an embodiment; 
           [0014]      FIG. 4  illustrates a session management table according to an embodiment; 
           [0015]      FIG. 5  illustrates a LBA translation table according to an embodiment; 
           [0016]      FIG. 6  schematically illustrates a process in response to a received initialization command according to an embodiment; 
           [0017]      FIG. 7  is a flowchart illustrating a process in response to a received initialization command according to an embodiment; 
           [0018]      FIG. 8  schematically illustrates a background copying process related to an initialization command according to an embodiment; 
           [0019]      FIG. 9  is a flowchart illustrating a background copying process related to an initialization command according to an embodiment; 
           [0020]      FIG. 10  schematically illustrates a releasing process related to an initial command according to an embodiment; 
           [0021]      FIG. 11  is flowchart illustrating a releasing process related to an initial command according to an embodiment; 
           [0022]      FIG. 12  schematically illustrates a process in response to a received initialization command in accordance with another embodiment; 
           [0023]      FIG. 13  schematically illustrates a process in response to a received initialization command in accordance with another embodiment; 
           [0024]      FIG. 14  schematically illustrates a process in response to a received initialization command in accordance with another embodiment; 
           [0025]      FIG. 15  schematically illustrates a process in response to a received initialization command in accordance with another embodiment; 
           [0026]      FIG. 16  is a flowchart illustrating a process in response to a received initialization command in accordance with another embodiment; 
           [0027]      FIG. 17  schematically illustrates a process in response to a received initialization command in accordance with another embodiment; and 
           [0028]      FIG. 18  is a flowchart illustrating a process in response to a received initialization command in accordance with another embodiment. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0029]    An upper half of  FIG. 1  schematically illustrates allocation of a physical area in a normal writing process (Write I/O) in typical Thin Provisioning. In  FIG. 1 , hatched areas of the logical volume represent allocated areas. A lower half of  FIG. 1  schematically illustrates a releasing process of the specified area on the basis of the initialization command in typical Thin Provisioning. 
         [0030]      FIG. 2  illustrates a typical process upon reception of an initialization command for the copy source volume in Thin Provisioning. 
         [0031]    Upon reception of an initialization command for a copy source volume from, for example, a host computer (S 100 ), it is determined, on the basis of, for example, a later-described session management table showing correlation between copy source areas and copy destination areas, whether or not an initialization range specified by the initialization command is an area to be copied (S 102 ). If the initialization range is not an area to be copied (S 102 : NO), a physical area allocated to that area is released (S 110 ). If the initialization range is an area to be copied (S 102 : YES), it is determined whether or not the area to be copied has already been copied (S 104 ) on the basis of, for example, a later-described copy bit. The copy bit represents whether or not each area has already been copied. If the area has already been copied (S 104 : YES), the physical area allocated to that area is released (S 110 ). If the area has not been copied (S 104 : NO), the uncopied area is copied to a copy destination volume (S 106 ) and the copy bit related thereto is set to OFF (S 108 ). Then, the physical area allocated to that area is released (S 110 ) and a response is returned to the host computer. 
         [0032]    A storage system according to an embodiment will be described with reference to  FIG. 3 .  FIG. 3  illustrates an exemplary configuration of a storage system according to an embodiment. 
         [0033]    A storage system  100  is connected to one or more host computers  110 . The storage system  100  includes one or more channel adapters (CA)  120 , one or more controller modules (CM)  130 , one or more disks  140  and one or more logical volumes  150 . 
         [0034]    An operator gives various instructions to the storage system  100  via the host computer  110 . Typically, the host computer  110  is implemented by a computer connected to the storage system  100  via, for example, a network. Although only one host computer  110  is illustrated in the present embodiment, any number of host computers  110  may be connected to the storage system  100 . 
         [0035]    The channel adapter (CA)  120  functions as an interface (I/F) between the host computer  110  and the storage system  100  and controls data communication therebetween. Although the channel adapter  120  is used as an interface between the host computer  110  and the storage system  100  in the present embodiment, the present disclosure is not limited to the same. Any interfacing means that provides data communication between the host computer  110  and the storage system  100  may be suitably employed. 
         [0036]    The controller module (CM)  130  controls components of the storage system  100 , such as the channel adapters  120  and the disks  140 . The controller module  130  includes a central processing unit (CPU)  132 , a cache  134  and a fibre channel (FC) interface  136 . 
         [0037]    When the controller module  130  receives an instruction from the host computer  110  via the channel adapter  120 , the CPU  132  executes the received instruction and controls operations of the components of the storage system  100 , including the disk  140 , the channel adapter  120  and the cache  134 , in accordance with the instruction. The CPU  132  may be implemented by any suitable computing device, such as a processor, which is adapted to process information. 
         [0038]    The cache  134  is a storage unit connected to the CPU  132  and stores data and instructions used for various processes in the CPU  132 . Although the cache  134  is used in the present embodiment, any other suitable storage unit may be employed alternatively. 
         [0039]    The fiber channel interface  136  functions as an interface (I/F) between the disk  140  and the controller module  130  and controls data communication therebetween. Although the fiber channel interface  136  is used in the present embodiment, the present disclosure is not limited to the same. Any other suitable interface that provides data communication between the disk  140  and the controller module  130  may be employed alternatively. 
         [0040]    The disk  140  is used as a user disk or a backup disk that provides physical volume for the logical volume  150 . As illustrated in  FIG. 3 , one or more disks  140  constitute a storage pool which provides physical volume in Thin Provisioning. 
         [0041]    The logical volume  150  is a virtually defined volume to which a physical volume is allocated from the storage pool consisting of one or more disks  140  during, for example, writing of data. In the present embodiment, the logical volume  150  is a variably allocated virtual volume to which a physical volume is variably allocated in accordance with a usage condition. Thin Provisioning is an exemplary mechanism for variably allocating a physical volume in accordance with a usage condition. In typical Thin Provisioning, a physical volume required for the storage is not initially provided. Instead, only a physical volume corresponding to an actual storage amount is provided. The requested storage amount is provided as a virtual volume. When the amount of the actual storage used is about to exceed the originally provided physical volume, the physical volume is increased by the exceeding amount and the operation is continued. Thus, Thin Provisioning allows establishing a virtual volume which is larger than the actually provided physical volume. Although the logical volume  150  is implemented by a variably allocated virtual volume in the present embodiment, the present disclosure is not limited to the same. In other embodiments, the logical volume  150  may be implemented by any other suitable virtual volume. 
         [0042]    In the present embodiment, the logical volume  150  functions as both a copy source volume and a copy destination volume and the copying process in the storage system  100  is executed with respect to the logical volume  150 . 
         [0043]    Although two logical volumes  150 , i.e., the copy destination volume and the copy source volume, are illustrated in the present embodiment, the present disclosure is not limited to the same. In other embodiments, three or more logical volumes  150  may be provided alternatively. 
         [0044]    Next, with reference to  FIGS. 4 and 5 , tables for managing various pieces of information used in the embodiments will be described. 
         [0045]    The session management table is configured to manage information including a copy type of each copy session, a range to be copied in the copy source volume and a range to be copied in the copy destination volume each copy session. The copying process is managed on the basis of the copy session. In the embodiment described below, the session management table is used for determination as to whether or not each virtual region of the logical volume  150  is an area to be copied. Typically, the session management table is loaded in, for example, the cache  134  during the copying process. The controller module  130  looks up the session management table to confirm details of each copy session of the copying process. As illustrated in  FIG. 4 , the session management table according to an embodiment includes an identifier, a copy type of the copy session, such as One Point Copy (OPC), a Logical Unit Number (LUN), an initial Logical Block Address (LBA) and a block volume. The identifier specifies each copy session. The LUN is an identifier for identifying a copy source volume and a copy destination volume which are objects for the copy session. The initial LBA specifies leading areas or blocks of the copy source volume and the copy destination volume in a range to be copied of the copy session. The block volume specifies the length from the initial LBA in the range to be copied. In the present embodiment, the area to be copied is defined by the initial LBA which represents the address of the leading area of the logical volume  150  and the block volume which represents the length from the initial LBA to a trailing area of the range to be copied. However, any other suitable index for specifying the range to be copied may be employed alternatively. 
         [0046]    The copy bit map table stores a copy bit which represents whether or not each area to be copied in the logical volume  150  has already been copied. In the embodiment described below, the copy bit map table is used to determine whether or not each area to be copied has already been copied. Typically, the copy bit map table is loaded in, for example, the cache  134  during the copying process. The controller module  130  looks up the copy bit map table to determine whether or not each area to be copied of the logical volume  150  for which the copying process is to be executed has already been copied. In an embodiment, the copy bit map table is configured to manage copied/uncopied status with 1 bit corresponding to an area of 0x10 blocks. If the area has already been copied, the bit may be set to “0.” If the area has not been copied, the bit may be set to “1.” With this configuration, if the block volume of a copy session is 0x100000, the copy bit map table should have at least 0x10000 bits. 
         [0047]    A LBA translation table shows, regarding the logical volume  150  of the variably allocated virtual volume in, for example, Thin Provisioning, correlation between the address on the logical volume  150  and the address on the physical volume constituted by the disks  140 . In the embodiment described below, the LBA translation table is used for determination as to whether or not each virtual region of the logical volume  150  has already been allocated to the physical area. Typically, the LBA translation table is loaded in, for example, the cache  134  during the copying process. The controller module  130  looks up the LBA translation table to determine correlation between each virtual region of the logical volume  150  and the physical area of the disk  140  allocated to the virtual region. When it is necessary to allocate the physical volume in response to, for example, a writing request to the logical volume  150 , the controller module  130  allocates the physical area of the disk  140  for each area of a certain volume of the logical volume  150  and writes the LBA representing address information of the allocated physical area in the LBA translation table. As illustrated in  FIG. 5 , the LBA translation table according to an embodiment includes identification numbers for specifying each area of the volume, virtual volume information regarding the logical volume  150  and physical volume information regarding the disk  140 . In the logical volume  150  specified by the LUN of the virtual volume information, it can be determined to which area of the physical volume the area specified by the LBA has been allocated on the basis of the LUN and the LBA of the physical volume information. In the illustrated LBA translation table, the provided allocation unit of each area is 32 MB (i.e., 0x10000 block counts). 
         [0048]    A release request bit map table stores release request bits which represent whether or not the allocated physical areas should be released for each virtual region to which the physical area of the logical volume  150  has been allocated. In the embodiment described below, the release request bit map table is used for determination as to whether or not the physical area should be released from each virtual region. Typically, the release request bit map table is loaded in, for example, the cache  134  during the copying process. The controller module  130  looks up the release request bit map table to determine whether or not the allocated physical area has already been released for each virtual region of the logical volume  150  to which the copying process is executed. In an embodiment, the release request bit map table shows a release request status of each allocation unit (i.e., a unit to which the physical area is allocated in the LBA translation volume), such as 32 MB (0x10000 block counts) for 1 bit. If the physical area is in a release request status in which allocation should be released, the bit is set to ON (i.e., “1”). If the physical area is not in the release request status, i.e., if the physical area has already been released, the bit is set to OFF (i.e., “0”). In this case, if the size of the logical volume  150  is 0x1000000, the release request bit map table should have at least 0x100 bits. The release request bit may be set before execution of determination in order to avoid delay of process accompanying determination as to whether or not the physical area is currently allocated to the corresponding virtual region current. 
         [0049]    Next, an exemplary process in the storage system  100  upon reception of an initialization command according to an embodiment will be described with reference to  FIGS. 6 and 7 . 
         [0050]    As described above with reference to  FIG. 2 , in the typical storage system in which a copying process is executed from a copy source volume to a copy destination volume, if an instruction for initialization is given to the copy source volume, a releasing process is executed after the uncopied area of the copy source volume is copied to the copy destination volume. Thus, the initialization process may be delayed due to the delay of the copying process. To address this problem, the copying process and the releasing process are executed asynchronously with the instruction for initialization in the present embodiment so as to improve response to the instruction for initialization. 
         [0051]      FIG. 6  schematically illustrates a process in response to a received initialization command according to an embodiment.  FIG. 7  is a flowchart illustrating a process in response to a received initialization command according to an embodiment. In  FIG. 6 , hatched areas in each volume represent allocated physical areas. 
         [0052]    As illustrated in  FIG. 6 , upon reception of the initialization command with respect to the copy source volume, the controller module  130  looks up the session management table and determines whether or not a range to be initialized includes an area to be copied. If the area to be copied is included, the controller module  130  looks up the copy bit map table and determines whether or not the range to be copied has already been copied. If an uncopied area is included, the controller module  130  sets the release request bit of the uncopied area to ON (see the second to fifth release request bits “1” from above in  FIG. 6 ), and returns a response to the initialization command immediately without executing the copying process for the uncopied area. Note that the release request bit of the uncopied area is set to ON (see the third release request bit “1” from above in  FIG. 6 ) without any determination as to whether or not the physical area has already been allocated to the uncopied area. Thus, a quick response can be made to the initialization command by setting the release request bit to ON without executing the copying process for the uncopied area and by executing the copying process and the releasing process for the uncopied asynchronously with the initialization command in a background process which will be described later. 
         [0053]    The foregoing process will be described in more detail with reference to  FIG. 7 . When the storage system  100  receives an initialization command with respect to the copy source volume from, for example, the host computer  110  (S 200 ), the controller module  130  looks up the session management table loaded in the cache  134  and determines whether or not each area of the initialization range specified by the initialization command is an area to be copied (S 202 ). If the area is not an area to be copied, i.e., if there is no copy session in the area (S 202 : NO), the controller module  130  releases the physical area allocated to that area and changes the record related to that area in the LBA translation table loaded in the cache  134 . 
         [0054]    If, on the other hand, the area is an area to be copied, i.e., if there is a copy session in the area (S 202 : YES) the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not the area has already been copied to the copy destination volume (S 206 ). If the area has already been copied (S 206 : YES), the controller module  130  releases the physical area allocated to the area and changes the record related to the area in the LBA translation table loaded in the cache  134 . 
         [0055]    If, on the other hand, the area has not been copied (S 206 : NO), the controller module  130  sets the release request bit related to that area in the release request bit map table loaded in the cache  134  to ON (i.e., “1”) and returns a response to the host computer  110 . In the present embodiment, the controller module  130  does not confirm whether or not the physical area has already been allocated to the initialization range as described above. 
         [0056]    Next, the background copying process executed in response to the initialization command according to an embodiment will be described with reference to  FIGS. 8 and 9 . 
         [0057]      FIG. 8  schematically illustrates a background copying process related to an initialization command according to an embodiment.  FIG. 9  is a flowchart illustrating a background copying process related to an initialization command according to an embodiment. 
         [0058]    As described above, in the process described with reference to  FIGS. 6 and 7 , a response to the initialization command is returned without execution of the copying process and the releasing process regarding the uncopied area with the release request bit set to ON. Regarding such areas, at any time after the response is returned, the copying process is executed with respect to the copy destination volume in the background and the physical area of the uncopied area is released. The background copying process according to the present embodiment is periodically started until the entire area to be copied has been copied such that the uncopied areas are sequentially copied to the copy destination volume. 
         [0059]    When the background copying process is started as illustrated in  FIG. 8 , the controller module  130  looks up the session management table and retrieves an area to be copied. When an area to be copied is detected, the controller module  130  looks up the release request bit of the area to be copied. If the release request bit is set to ON, the controller module  130  copies the area to be copied to the copy destination volume. Then, the controller module  130  executes the releasing process and sets the release request bit to OFF (see the release request bit “0” relating to the fourth virtual region from above of the copy source volume in  FIG. 8 ). 
         [0060]    With reference to  FIG. 9 , the foregoing process will be described in more detail. Upon starting of the background copying process by the controller module  130  (S 300 ), the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not there is a uncopied area in the area to be copied (S 302 ). If there is no uncopied area (S 302 : NO), the controller module  130  ends the background copying process (S 320 ). If, on the other hand, there is a uncopied area (S 302 : YES), the controller module  130  looks up the release request bit map table loaded in the cache  134  and determines whether or not there is an area to be copied with the release request bit being set to ON (S 304 ). If there is no area to be copied with the release request bit being set to ON (S 304 : NO), the controller module  130  copies the uncopied area to the copy destination volume (S 306 ) and sets the copy bit related to the area of copy bit map table to OFF (i.e., “0”) (S 310 ). If, on the other hand, there is an area to be copied with the release request bit being set to ON (S 304 : YES), the controller module  130  copies the uncopied area with the release request bit being set to ON to the copy destination volume (S 308 ) and sets the copy bit related to the area of the copy bit map table to OFF (i.e., “0”) (S 310 ). 
         [0061]    Next, the controller module  130  looks up the release request bit map table and determines whether or not the release request bit is set to ON in the current copy range (S 312 ). If the release request bit is not set to ON (S 312 : NO), the controller module  130  ends the background copying process (S 320 ). If, on the other hand, the release request bit is set to ON (S 312 : YES), the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not the entire area to be copied has already been copied (S 314 ). If the entire area to be copied has not copied (S 314 : NO), the controller module  130  ends the background copying process (S 320 ). If, on the other hand, the entire area to be copied has already been copied (S 314 : YES), the controller module  130  executes the releasing process regarding the area to be copied (S 316 ) and sets the release request bit related to that area in the release request bit map table to OFF (S 318 ). Then, the controller module  130  ends the background copying process (S 320 ). 
         [0062]    Next, a process related to the initialization command upon reception of a normal writing request in an uncopied area with the release request bit being set to ON according to an embodiment will be described with reference to  FIGS. 10 and 11 . 
         [0063]      FIG. 10  schematically illustrates a releasing process related to an initial command according to an embodiment.  FIG. 11  is flowchart illustrating a releasing process related to an initial command according to an embodiment. 
         [0064]    As described above, in the foregoing process described with reference to  FIGS. 6 and 7 , a response to the initialization command is returned without execution of the copying process and the releasing process regarding the uncopied area with the release request bit being set to ON. Upon reception of a normal writing instruction (i.e., Write I/O in  FIG. 10 ) accompanied by an I/O process, the control module  130  looks up the release request bit map table and determines whether or not the release request bit of the area to be written has been set to ON. If the release request bit has been set to ON, the control module  130  looks up the session management table and determines whether or not the area to be written is an area to be copied. If the area to be written is an area to be copied, the control module  130  looks up the copy bit map table and determines whether or not the uncopied area is included in the area to be written. If a uncopied area is included, the control module  130  executes the copying process releasing process and sets the release request bit to OFF (see the release request bit “0” relating to the fifth virtual region from above in the copy source volume in  FIG. 10 ). Then, the received Write instruction is executed. 
         [0065]    With reference to  FIG. 11 , the process described above will be described in more detail. When the storage system  100  receives a normal Write instruction from, for example, the host computer  110  (S 400 ), the controller module  130  looks up the session management table loaded in the cache  134  to determine whether or not the area to be written specified by the Write instruction is an area to be copied, i.e., whether or not there is a copy session in the area to be written (S 402 ). If there is no copy session (S 402 : NO), the controller module  130  executes the Write instruction (S 422 ). 
         [0066]    If, on the other hand, there is a copy session (S 402 : YES), the controller module  130  looks up the copy bit map table loaded in the cache  134  to determine whether or not there is a uncopied area in the area to be copied (S 404 ). If there is no uncopied area (S 404 : NO), the controller module  130  executes the Write instruction (S 422 ). If, on the other hand, there is a uncopied area (S 404 : YES), the controller module  130  copies the uncopied area to the copy destination volume (S 406 ) and sets the copy bit related to the area in the copy bit map table to OFF (i.e., “0”) (S 408 ). 
         [0067]    Next, the controller module  130  looks up release request bit map table loaded in the cache  134  and determines whether or not there is any area with the release request bit being set to ON in the area to be written (S 410 ). If there is no area with the release request bit being set to ON, the controller module  130  executes the Write instruction (S 422 ). If, on the other hand, there is an area with the release request bit being set to ON, the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not the entire area to be written determines has been copied (S 412 ). If the entire area to be written has been copied (S 412 : YES), the controller module  130  releases the area (S 418 ). If, on the other hand, the entire area to be written has not been copied (S 412 : NO), the controller module  130  copies the uncopied area to the copy destination module (S 414 ) and sets the copy bit related to that area in the copy bit map table loaded in the cache  134  to OFF (S 416 ). 
         [0068]    Then, the controller module  130  executes the releasing process (S 418 ) and sets the release request bit related to the area in the release request bit map table to OFF (S 420 ). Then, the controller module  130  executes the Write instruction (S 422 ) and returns the response to the host computer  110  (S 424 ). 
         [0069]    An exemplary process in the storage system  100  upon reception of an initialization command according to another embodiment will be described with reference to  FIGS. 12 to 16 . 
         [0070]    In the copying process from the copy source volume to the copy destination volume as described above, a single copy source volume may copied to a plurality of copy destination volumes. This is called a multi-copying process. The foregoing embodiment may be applied to such a multi-copying process. In a copying process other than the multi-copying process, the copy source volume may be copied to the copy destination volume by rewriting allocation information of the physical area without actually executing the copying process. That is, as illustrated in  FIG. 12 , the copy source volume may be copied to the copy destination volume by reallocating the physical area currently allocated to the area to be copied of the copy source volume to the copy destination volume. 
         [0071]    The copy source volume can be copied to the copy destination volume through reallocation where the copying process is not a multi-copying process and where the copy source volume and the copy destination volume have the same offset amount in the range to be copied (represented by arrows in  FIG. 13 ) with respect to a boundary of the allocation units as illustrated in  FIG. 13 . 
         [0072]    It is impossible, on the other hand, to copy the copy source volume to the copy destination volume through reallocation where the copying process is not a multi-copying process, where the copy source volume and the copy destination volume have different offset amounts in the range to be copied with respect to the boundary of the allocation units as illustrated in  FIG. 14  and where a plurality of copy destination volumes exist as illustrated in  FIG. 15 . 
         [0073]      FIG. 16  is a flowchart illustrating a process upon reception of an I/O in an example in which a copy source volume can be copied to a copy destination volume through reallocation. 
         [0074]    When the storage system  100  receives an I/O instruction, such as a Write instruction, from, for example, the host computer  110  (S 500 ), the controller module  130  looks up the session management table loaded in the cache  134  and determines whether or not a range to be I/O specified by the I/O instruction is an area to be copied, i.e., whether or not there is a copy session in the range to be I/O (S 502 ). If there is no copy session (S 502 : NO), the controller module  130  executes the I/O instruction (S 526 ). 
         [0075]    If, on the other hand, there is a copy session (S 502 : YES), the controller module  130  looks up the copy bit map table loaded in the cache  134  to determine whether or not there is a uncopied area in the area to be copied (S 504 ). If there is no uncopied area (S 504 : NO), the controller module  130  executes the I/O instruction (S 526 ). If, on the other hand, there is an uncopied area (S 504 : YES), the controller module  130  looks up the session management table to determine whether or not copying through reallocation is possible (S 506 ). In particular, as described above, the controller module  130  determines whether the copy session with respect to the range to be copied of the copy source volume is not a multi-copy session and whether or not the copy source volume and the copy destination volume have the same offset amount with respect to a boundary of the allocation units. 
         [0076]    If copying through reallocation is not possible (S 506 : NO), the controller module  130  copies the uncopied area to the copy destination volume (S 510 ) and sets the copy bit related to that area in the copy bit map table loaded in the cache  134  to OFF (i.e., “0”) (S 512 ). If, on the other hand, copying through reallocation is possible (S 506 : YES), the controller module  130  specifies the physical area of the physical volume information allocated to that area in the LBA translation table loaded in the cache  134  and reallocates the physical area to the virtual region of the copy destination volume (S 508 ). The controller module  130  then sets the copy bit related to that area of the copy bit map table loaded in the cache  134  to OFF (i.e., “0”) (S 512 ). 
         [0077]    Next, the controller module  130  looks up the release request bit map table loaded in the cache  134  and determines whether or not there is any area to be copied with the release request bit being set to ON (S 514 ). If there is no area to be copied with the release request bit being set to ON, the controller module  130  executes the I/O instruction (S 526 ). If, on the other hand, there is an area to be copied with the release request bit being set to ON, the controller module  130  copies the area to be copied to the copy destination volume. Then, the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not the entire area to be copied has already been copied (S 516 ). If the entire area to be copied has been copied (S 516 : YES), the controller module  130  releases the area (S 522 ). If, on the other hand, the entire area to be copied has not been copied (S 516 : NO), the controller module  130  copies the uncopied area to the copy destination module (S 518 ) and sets the copy bit related to that area in the copy bit map table loaded in the cache  134  to OFF (S 520 ). 
         [0078]    The controller module  130  then executes the releasing process (S 522 ) and sets the release request bit related to that area in the release request bit map table to OFF (S 524 ). The controller module  130  then executes the I/O instruction (S 526 ) and returns a response to the host computer  110  (S 528 ). 
         [0079]    Next, a process related to the initialization command upon reception of a normal Write instruction in a uncopied area with the release request bit being set to ON according to another embodiment will be described with reference to  FIGS. 17 and 18 . 
         [0080]    According to the present embodiment, when arbitrary data may be stored in a range to be initialized after initialization, i.e. when zero guarantee is not expected, only the area to be written may be copied to the copy destination volume without execution of the releasing process and the release request bit may be set to OFF as illustrated in  FIG. 17 . The Write instruction may thus be executed. 
         [0081]      FIG. 18  is a flowchart illustrating a process related to the initialization command according to the present embodiment. 
         [0082]    When the storage system  100  receives an I/O instruction from, for example, the host computer  110  (S 600 ), the controller module  130  looks up the session management table loaded in the cache  134  and determines whether or not the I/O range specified by the I/O instruction is an area to be copied, or whether or not the I/O range has a copy session (S 602 ). If there is no copy session (S 602 : NO), the controller module  130  executes the I/O instruction (S 614 ). 
         [0083]    If, on the other hand, there is a copy session (S 602 : YES), the controller module  130  looks up the copy bit map table loaded in the cache  134  and determines whether or not there is a uncopied area in the area to be copied (S 604 ). If there is no uncopied area (S 604 : NO), the controller module  130  executes the I/O instruction (S 614 ). If, on the other hand, there is a uncopied area (S 604 : YES), the controller module  130  copies the uncopied area to the copy destination volume (S 606 ) and sets the copy bit related to that area in the copy bit map table to OFF (i.e., “0”) (S 608 ). 
         [0084]    Next, the controller module  130  looks up the release request bit map table loaded in the cache  134  and determines whether there is any area to be copied with the release request bit being set to ON (S 610 ). If there is no area to be copied with the release request bit being set to ON, the controller module  130  executes the I/O instruction (S 614 ). If, on the other hand, there is an area to be copied with the release request bit being set to ON, the controller module  130  sets the release request bit related to that area in the release request bit map table loaded in the cache  134  to OFF (S 612 ). Then, the controller module  130  executes the I/O instruction (S 614 ) and returns a response to the host computer  110  (S 616 ). 
         [0085]    Although an embodiment of the invention has been described in detail, the invention is not limited to the same. Various modifications and changes may be made without departing from the spirit and scope of the invention as described in the claims. 
         [0086]    According to the present disclosure, a copy source volume can be initialized efficiently. 
         [0087]    As mentioned above, the present art has been specifically described for better understanding of the embodiments thereof and the above description does not limit other aspects of the art. Therefore, the present art can be altered and modified in a variety of ways without departing from the gist and scope thereof. 
         [0088]    All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiments of the present inventions have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.