Storage system, and memory control method

Abstract

To provide a storage system capable of changing address mapping in a short time, even when the addresses change for duplicate data across multiple snapshot families that include both the PVOL and its corresponding SVOL (snapshot volume).SOLUTION: The storage system provides a snapshot virtual device (SS-VDEV) for each snapshot family (SS-Family), and furthermore, a separate deduplication virtual device is configured, independent of the SS-VDEV. When the same data exists in multiple VOLs (volumes) within the SS-Family, the multiple VOLs containing the same data is mapped on the multiple addresses of that data to the address of the SS-VDEV within the corresponding SS-Family. When there is duplicate data across two or more SS-VDEVs, two or more SS-VDEVs containing the duplicate data map the addresses of the duplicate data in those SS-VDEVs to the corresponding address in the deduplication virtual device.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention generally relates to storage control in a storage system. [Background technology]

[0002] A snapshot function is known as one of the functions of a storage system. For example, the technology disclosed in Patent Document 1 is known regarding the snapshot function. Patent Document 1 discloses technology related to a snapshot function of the RoW (Redirect on Write) method. The RoW method is a method of writing data after it has been written. After it has been written is a data storage method in which, when data is written to a storage system, the data to be written is stored in a new area without overwriting the data stored before the write, and the meta information is rewritten so that it references the data stored in the new area. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] U.S. Patent No. 9,646,039 Summary of the Invention [Problem to be solved by the invention]

[0004] The following data management can be adopted for snapshots taken using the RoW method. That is, a virtual device is provided as a logical address space for a snapshot family, which is a VOL group including a PVOL (Primary Volume) and an SVOL (Secondary Volume), which is a snapshot of the PVOL. The address of the same data in the virtual device becomes the reference destination for multiple different addresses in multiple different VOLs (Volumes) in the snapshot family.

[0005] In this type of data management, multiple snapshot families can be configured. In this case, a virtual device is shared by multiple snapshot families. For each snapshot family, multiple addresses of multiple VOLs in the snapshot family can refer to the same address in the virtual device.

[0006] If duplicated data between snapshot families is to be stored, the duplicated data is stored in the virtual device for each snapshot family.

[0007] To avoid storing such duplicate data in the virtual device, deduplication techniques can be applied, where multiple addresses in multiple snapshot families may refer to the same address in the virtual device.

[0008] In this type of data management using deduplication technology, when an address in a virtual device for data is changed due to garbage collection or other reasons, if that address is a reference to multiple different addresses in multiple snapshot families, the referenced address must be changed for each of those multiple addresses. This takes a long time to change the address mapping, and as a result, the overall processing time required for changing the address mapping is long. [Means for solving the problem]

[0009] A storage system has one or more snapshot virtual devices for each of a plurality of snapshot families. The storage system also has a deduplication virtual device as a virtual device separate from the snapshot virtual devices. Each snapshot virtual device is a logical address space that serves as a storage destination for data of a VOL in the snapshot family corresponding to the snapshot virtual device.

[0010] When the same data exists in multiple VOLs of a snapshot family, the storage system maps multiple addresses of the same data in the multiple VOLs to addresses of the snapshot virtual device of the snapshot family.When duplicate data exists in two or more snapshot virtual devices of two or more snapshot families, the storage system maps two or more addresses of the duplicate data in the two or more snapshot virtual devices to addresses corresponding to the duplicate data in the deduplication virtual device. [Effects of the Invention]

[0011] According to the present invention, even if the addresses of overlapping data in multiple snapshot families are changed, the address mapping can be changed in a short time. [Brief explanation of the drawings]

[0012] [Figure 1] 1 shows an overview of storage control in a storage system according to a first embodiment. [Figure 2] An example of the range of the owner CPU is shown below. [Figure 3] 1 shows an overview of management of mapping between addresses in the SS-Family and addresses in the SS-VDEV. [Figure 4] This shows an overview of the management of mapping between addresses in an SS-VDEV and addresses in a Dedup-VDEV, the management of mapping between addresses in an SS-VDEV and addresses in a CR-VDEV, and the management of mapping between addresses in a Dedup-VDEV and addresses in a CR-VDEV. [Figure 5] 1 shows an overview of the reverse mapping from addresses in a CR-VDEV to addresses in an SS-VDEV or Dedup-VDEV. [Figure 6] 10 shows an overview of the reverse mapping from addresses in the Dedup-VDEV to addresses in the SS-VDEV. [Figure 7]1 shows an overview of the management of mapping between addresses in a CR-VDEV and addresses in pages of a pool. [Figure 8] 1 shows the hardware configuration of a computer system. [Figure 9] The memory configuration is shown. [Figure 10] This shows the information stored in the control information. [Figure 11] This shows the programs stored in the program section. [Figure 12] 1 shows the configuration of an ownership management table. [Figure 13] 10 shows the configuration of a CR-VDEV management table. [Figure 14] 1 shows the configuration of a snapshot management table. [Figure 15] 10 shows the configuration of a VOL-Dir management table. [Figure 16] The configuration of the latest generation table is shown below. [Figure 17] 10 shows the configuration of a collection management table. [Figure 18] 1 shows the configuration of a generation management tree table. [Figure 19] 10 shows the configuration of a snapshot allocation management table. [Figure 20] The configuration of the Dir management table is shown below. [Figure 21] The configuration of the SS-Mapping management table is shown below. [Figure 22] 10 shows the configuration of a compression allocation management table. [Figure 23] 1 shows the configuration of a CR-Mapping management table. [Figure 24] 1 shows the configuration of a Dedup-Dir management table. [Figure 25] 1 shows the configuration of a Dedup allocation management table. [Figure 26] 1 shows the configuration of a Pool-Mapping management table. [Figure 27] The configuration of the Pool allocation management table is shown below. [Figure 28] 1 shows the flow of a snapshot acquisition process. [Figure 29] 10 shows the flow of snapshot restore processing. [Figure 30] 10 shows the flow of a snapshot deletion process. [Figure 31] The flow of asynchronous collection processing is shown below. [Figure 32] The flow of write processing (front end) is shown below. [Figure 33] The flow of write processing (backend) is shown below. [Figure 34] 10 shows the flow of a snapshot append process. [Figure 35] The flow of the Dedup append process is shown below. [Figure 36] 10 shows the flow of the compression append process. [Figure 37] 1 shows the flow of destage processing. [Figure 38] The flow of GC processing is shown below. [Figure 39] The flow of CPU determination processing is shown below. [Figure 40] 10 shows the flow of ownership transfer processing. [Figure 41] 10 shows an outline of acquisition of WR-SVOL according to the second embodiment. [Figure 42] An overview of writing to WR-SVOL is shown below. [Figure 43] An overview of restoring from WR-SVOL is shown below. DETAILED DESCRIPTION OF THE INVENTION

[0013] In the following description, an "interface apparatus" may refer to one or more interface devices, which may be at least one of the following: One or more I / O (Input / Output) interface devices. The I / O (Input / Output) interface devices are interface devices for at least one of the I / O device and a remote display computer. The I / O interface device for the display computer may be a communications interface device. The at least one I / O device may be a user interface device, for example, either an input device such as a keyboard and a pointing device, or an output device such as a display device. One or more communication interface devices. The one or more communication interface devices may be one or more homogeneous communication interface devices (e.g., one or more NICs (Network Interface Cards)) or two or more heterogeneous communication interface devices (e.g., an NIC and an HBA (Host Bus Adapter)).

[0014] In the following description, "memory" refers to one or more memory devices, which are an example of one or more storage devices, and may typically be a primary storage device. At least one memory device in the memory may be a volatile memory device or a non-volatile memory device.

[0015] In the following description, a "persistent storage device" may refer to one or more persistent storage devices, which are an example of one or more storage devices. A persistent storage device may typically be a non-volatile storage device (e.g., an auxiliary storage device), and specifically may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a non-volatile memory express (NVME) drive, or a storage class memory (SCM).

[0016] In the following description, the term "storage device" may refer to at least one of memory and persistent storage device.

[0017] Furthermore, in the following description, a "processor" may refer to one or more processor devices. The at least one processor device may typically be a microprocessor device such as a CPU (Central Processing Unit), but may also be another type of processor device such as a GPU (Graphics Processing Unit). The at least one processor device may be a single-core or multi-core. The at least one processor device may also be a processor core. The at least one processor device may also be a processor device in a broader sense, such as a circuit that is a collection of gate arrays written in a hardware description language that performs some or all of the processing (for example, an FPGA (Field-Programmable Gate Array), a CPLD (Complex Programmable Logic Device), or an ASIC (Application Specific Integrated Circuit)).

[0018] In the following description, information that provides an output for an input may be described using expressions such as "xxx table." However, this information may be data of any structure (for example, structured data or unstructured data), or may be a neural network that generates an output for an input, or a learning model such as a genetic algorithm or random forest. Therefore, the "xxx table" may be referred to as "xxx information." In the following description, the structure of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0019] In the following description, processing may be described using a "program" as the subject; however, since a program is executed by a processor to perform a predetermined process using a storage device and / or an interface device as appropriate, the subject of the processing may also be the processor (or a device or system having the processor). A program may be installed in a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable recording medium (e.g., a non-transitory recording medium). In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0020] In the following description, "VOL" is an abbreviation for logical volume and may be a logical storage area. A VOL may be a physical VOL (RVOL) or a virtual VOL (VVOL). An "RVOL" may be a VOL based on physical storage resources (e.g., one or more RAID groups) of the storage system that provides the RVOL ("RAID" stands for Redundant Array of Independent (or Inexpensive) Disks). A "VVOL" may be any of an externally connected VOL (EVOL), a capacity-expanded VOL (TPVOL), and a snapshot VOL (SSVOL). An EVOL may be a VOL based on the storage space (e.g., a VOL) ​​of an external storage system and based on storage virtualization technology. A TPVOL may be a VOL composed of multiple virtual areas (virtual storage areas) and based on capacity virtualization technology (typically Thin Provisioning). An SSVOL may be a VOL provided as a snapshot of the original VOL. An SSVOL may be an RVOL. Typically, an SSVOL is positioned as a secondary VOL, with the original VOL being the primary VOL (PVOL). A "pool" is a logical storage area (e.g., a collection of multiple pool VOLs) and may be prepared for each purpose. For example, there may be at least one type of pool: a TP pool or a snapshot pool. A TP pool may be a storage area composed of multiple real areas (substantial storage areas). If a real area is not assigned to the virtual area (the virtual area of ​​the TPVOL) to which the address specified in a write request received from the host system belongs, the storage system allocates a real area from the TP pool to that virtual area (the write destination virtual area). (Even if another real area is already assigned to the write destination virtual area, a new real area may be allocated to the write destination virtual area.) The storage system may write the write target data associated with the write request to the allocated real area. A snapshot pool may be a storage area in which data evacuated from a PVOL is stored. A single pool may be used as both a TP pool and a snapshot pool.A "pool VOL" may be a VOL that is a constituent element of a pool. A pool VOL may be either an RVOL or an EVOL.

[0021] Furthermore, a "storage system" may be a system equipped with a controller that performs data I / O for multiple persistent storage devices (or an apparatus having multiple persistent storage devices), or a system that includes one or more physical computers. The latter system may be constructed as SDx (Software-Defined anything) by each of the one or more physical computers executing predetermined software. As SDx, for example, SDS (Software-Defined Storage) or SDDC (Software-Defined Data Center) can be adopted.

[0022] In the following description, # (identification number) and ID are used as examples of identification information for elements, but the identification information may be any information that can identify an element, such as a name.

[0023] In the following description, common reference symbols are used when describing elements of the same type without distinguishing between them, and reference symbols are used when describing elements of the same type with distinction between them. In the following description, element X with #n (identification number n) may be written as "X#n".

[0024] Furthermore, in the following description, snapshots are created using the RoW method, but the RoW method may be an example of a data copyless method. [Embodiment 1]

[0025] FIG. 1 shows an overview of storage control of a storage system according to a first embodiment. In FIG. 1, data written in uppercase letters (data A, B, C, ...) is block data, and data written in lowercase letters (data a, b, c, ...) is sub-block data. Block data may be data in units of blocks. A block may be a fixed-length logical storage area (logical address range). Sub-block data is compressed data of block data, and a group of sub-blocks (one or more sub-blocks) is the data storage destination. A sub-block may be a logical storage area smaller in size than a block. For example, a block may be an integer multiple of a sub-block.

[0026] A storage system having a storage device and a processor has an SS-Family (snapshot family) 9, an SS-VDEV (snapshot virtual device) 11S, a Dedup-VDEV (deduplicated virtual device) 11V, a CR-VDEV (compressed append virtual device) 11C, and a pool 13.

[0027] SS-Family9 is a VOL group that includes PVOL10P and SVOL10S, which is a snapshot of PVOL10P.

[0028] SS-VDEV11S is a virtual device serving as a logical address space, and serves as a storage destination for data whose storage destination is one of VOL10 in SS-Family9.

[0029] A Dedup-VDEV11D is a virtual device that serves as a logical address space separate from that of an SS-VDEV11S, and serves as a storage destination for duplicate data of two or more SS-VDEV11S.

[0030] The CR-VDEV 11C is a virtual device that serves as a logical address space separate from the SS-VDEV 11S and Dedup-VDEV 11D, and is used as a storage destination for compressed data.

[0031] Each of the multiple CR-VDEV11C is associated with either an SS-VDEV11S or a Dedup-VDEV11D, but is not associated with both VDEV11S and 11D. In other words, each CR-VDEV11C serves as the storage destination for data whose storage destination is a VDEV (virtual device) corresponding to that CR-VDEV11C, and is not the storage destination for data whose storage destination is a VDEV that does not correspond to that CR-VDEV11C. Compressed data whose storage destination is a CR-VDEV11C is stored in pool 13.

[0032] The pool 13 is a logical address space based on at least a portion of a storage device (e.g., a persistent storage device) that the storage system has. The pool 13 may be based on at least a portion of an external storage device (e.g., a persistent storage device) of the storage system instead of or in addition to at least a portion of the storage device that the storage system has. The pool 13 has a plurality of pages 14 that are a plurality of logical areas. Compressed data stored in the CR-VDEV 11C is stored in the pages 14 in the pool 13. There is a 1:1 mapping between addresses in the CR-VDEV 11C and addresses in the pool 13. The pool 13 is composed of one or more pool VOLs.

[0033] According to the example shown in FIG. 1, the following storage control is performed.

[0034] The processor creates SVOL10S0 as a snapshot of PVOL10P0, which creates SS-Family 9-0 with PVOL10P0 as the root VOL. The processor also creates SVOL10S1 as a snapshot of PVOL10P1, which creates SS-Family 9-1 with PVOL10P1 as the root VOL. According to Figure 1, examples of multiple SS-Families include SS-Family 9-0 and 9-1.

[0035] The storage system has one or more SS-VDEV11S for each of multiple SS-Family 9. For each SS-Family 9, for data that is stored in one of the VOL10 in that SS-Family 9, the SS-VDEV11S corresponding to that SS-Family 9 is used as the storage destination among the multiple SS-VDEV11S. Taking SS-Family 9-0 as an example, specific examples are as follows. The processor specifies SS-VDEV11S0 as the storage destination for data A, whose storage destination is SVOL10S0 of SS-Family9-0. The processor maps the address in SVOL10S0 corresponding to data A to the address in SS-VDEV11S corresponding to SS-Family9-0 corresponding to data A. ·If the same data B exists in multiple VOLs (PVOL10P0 and SVOL10S0) of SS-Family9-0, the processor maps the multiple addresses of the same data B among the multiple VOLs (address in PVOL10P0 and address in SVOL10S0) to the address of SS-VDEV11S0 of SS-Family9-0 (address corresponding to data B).

[0036] For each of SS-Family 9-0 and 9-1 (an example of two or more SS-Family 9), the storage destination for non-duplicate data is the CR-VDEV11C corresponding to that SS-Family 9, and the storage destination for duplicate data is the Dedup-VDEV11D.

[0037] That is, since data C is duplicated in SS-VDEV11S0 and 11S1 (an example of two or more SS-VDEV11S) of SS-Family 9-0 and 9-1, the processor maps the two addresses of duplicate data C in SS-VDEV11S0 and 11S1 to an address in Dedup-VDEV11D corresponding to duplicate data C. Then, the processor compresses duplicate data C and specifies CR-VDEV11CC corresponding to Dedup-VDEV11D as the storage destination for compressed data c. That is, the processor maps the address (block address) of duplicate data C in Dedup-VDEV11D to the address (sub-block address) of compressed data c in CR-VDEV11CC. Furthermore, the processor allocates page 14B to CR-VDEV11CC and stores compressed data c in page 14B. The address of the compressed data c in the CR-VDEV 11 CC is mapped to an address in page 14 B of the pool 13 .

[0038] On the other hand, since data A in SS-VDEV11S0 does not overlap with data in other SS-VDEV11S1, the processor compresses the non-duplicate data A and stores the compressed data a in CR-VDEV11C0 corresponding to SS-VDEV11S0. That is, the processor maps the address (block address) of the non-duplicate data A in SS-VDEV11S0 to the address (sub-block address) of the compressed data a in CR-VDEV11CC. The processor also allocates page 14A to CR-VDEV11C0 and stores the compressed data a in page 14a. The address of the compressed data a in CR-VDEV11C0 is mapped to an address in page 14A of pool 13.

[0039] The CR-VDEV11C is a write-once VDEV. Therefore, the processor updates the address mapping both when the CR-VDEV11C corresponding to the SS-VDEV11S is the storage destination for updated data and when the CR-VDEV11C corresponding to the Dedup-VDEV11D is the storage destination for updated data. Specifically, the processor performs the following storage control, for example. When the storage target in CR-VDEV11C0 is update data a' of compressed data a, the processor sets the storage destination of the update data a' to an empty address in CR-VDEV11C0 and invalidates the address of the compressed data a before the update. The processor maps the address in SS-VDEV11S0 that was mapped to the address of compressed data a to the storage destination address of the update data a' in CR-VDEV11C0, instead of the address of compressed data a in CR-VDEV11C0. The processor also maps the address in page 14A that was mapped to the address of compressed data a to the storage destination address of the update data a' in CR-VDEV11C0, instead of the address of compressed data a in CR-VDEV11C0. When the storage target in the CR-VDEV11CC is update data c' of compressed data c, the processor sets the storage destination of the update data c' to an empty address in the CR-VDEV11CC and invalidates the address of the compressed data c before the update. The processor maps the address in the Dedup-VDEV11D that was mapped to the address of the compressed data c to the storage destination address of the update data c' in the CR-VDEV11CC instead of the address of the compressed data c in the CR-VDEV11CC. The processor also maps the address in page 14B that was mapped to the address of the compressed data c to the storage destination address of the update data c' in the CR-VDEV11CC instead of the address of the compressed data a in the CR-VDEV11CC.

[0040] The CR-VDEV 11C is a write-once VDEV as described above, and is subject to garbage collection. In other words, by performing garbage collection on the CR-VDEV 11C, the processor can ensure that valid addresses (addresses of the latest data) are contiguous, and that the addresses of free areas are also contiguous.

[0041] 1, in addition to SS-VDEV11S, which is the storage destination of data in SS-Family9, Dedup-VDEV11D, which is the storage destination of duplicate data in two or more SS-Family9, is prepared. Therefore, even if the address of duplicate data C in Dedup-VDEV11D is changed, only two mappings (mappings for each of the two addresses in SS-VDEV11S0 and 11S1) are required to be changed. On the other hand, in one comparative example, the storage destination of data in SS-Family9 and the storage destination of duplicate data in two or more SS-Family9 are the same VDEV, and in this case, four mappings (mappings for each of the four addresses in VOL10P0, 10S0, 10P1, and 10S1) are required to be changed for duplicate data C. In this embodiment, it is expected that the address mapping can be changed in a shorter time than in the comparative example.

[0042] A CR-VDEV11CC is prepared for the Dedup-VDEV11D separately from the Dedup-VDEV11D. Therefore, even if the address of compressed data c in the CR-VDEV11CC changes, only one mapping (mapping for one address in the Dedup-VDEV11D) is required to change the address mapping. On the other hand, in one comparative example, the storage destination of compressed data of data in SS-Family9 and the storage destination of compressed data of duplicate data in two or more SS-Family9 are the same VDEV, and in this case, the address mapping to be changed for compressed data c of duplicate data C is four mappings (mapping for each of the four addresses in VOL10P0, 10S0, 10P1, and 10S1). In this embodiment, it is expected that the address mapping can be changed in a shorter time than in the comparative example.

[0043] The address of compressed data c is changed during garbage collection of the CR-VDEV11CC corresponding to the Dedup-VDEV11D. For example, during garbage collection of the CR-VDEV11CC, the processor changes the address of update data c' (update data of compressed data c) in the CR-VDEV11CC, and maps the address in the Dedup-VDEV11D that was mapped to the address before the change to the address after the change in the CR-VDEV11CC. Since it is expected that the address mapping for compressed data of duplicate data can be changed in a short time, it is expected that garbage collection can be performed in a short time. Note that garbage collection of the CR-VDEV11C corresponding to the SS-VDEV11S includes, for example, the following processes: That is, the processor changes the address of the updated data a' (updated data of compressed data a) in the CR-VDEV11C0, and maps the address in the SS-VDEV11S0 that was mapped to the address before the change to the changed address in the CR-VDEV11C0.

[0044] For at least one CR-VDEV11C, a write-once type VDEV in which uncompressed data is stored may be used instead of the CR-VDEV11C, but in this embodiment, a CR-VDEV11C is used as the write-once type VDEV. As a result, the data that is ultimately stored in the storage device is compressed data, and therefore the storage capacity consumed can be reduced.

[0045] FIG. 2 shows an example of the range of the owner CPU.

[0046] The processors are multiple CPUs, which are an example of multiple processor devices. By limiting exclusive ownership (access rights (I / O rights)) of data and control information related to VOL10 to specific CPUs, the processing time required for exclusive processing in I / O processing and the communication time between CPUs are reduced, and therefore performance improvement is expected.

[0047] If an owner CPU (the identification number of the CPU with authority) is associated with VOL10 or VDEV11, and if that CPU is the owner CPU, it performs I / O for that VOL10 or VDEV11 and updates address mapping information for that VOL10 or VDEV11. In other words, if the CPU is not the owner CPU, communication between CPUs is required to update I / O and address mapping information.

[0048] In this embodiment, the owner CPU of SS-Family 9 (specifically, each of all VOLs 10 in SS-Family 9), the owner CPU of the SS-VDEV 11S for that SS-Family 9, and the owner CPU of the CR-VDEV 11C corresponding to that SS-VDEV 11S are the same CPU. This eliminates the need for inter-CPU communication to transfer processing to the CPU with ownership for I / O and address mapping changes for non-duplicate data, thereby improving processing performance, including rapid address mapping changes. For example, for non-duplicate data A in SS-Family 9-0 (see FIG. 1), only CPU #0 of the multiple CPUs performs I / O and address mapping changes. Similarly, for non-duplicate data F in SS-Family 9-1 (see FIG. 1), only CPU #1 of the multiple CPUs performs I / O and address mapping changes.

[0049] Furthermore, in this embodiment, the owner CPU of a Dedup-VDEV 11D and the owner CPU of the CR-VDEV 11C corresponding to that Dedup-VDEV 11D are the same CPU. This eliminates the need for inter-CPU communication to transfer processing to the CPU with ownership for I / O and address mapping changes for duplicate data in the Dedup-VDEV 11D and its corresponding CR-VDEV 11C. For example, assume that the owner CPU of a Dedup-VDEV #10x (x is an integer from 0 to 7) and its CR-VDEV #110x is CPU #x. If the storage destination for duplicate data C and D (see Figure 1) is Dedup-VDEV#100, no inter-CPU communication is required for I / O or address mapping changes for duplicate data C, but communication from CPU#0 to CPU#1 is required for duplicate data D regarding Dedup-VDEV#100 and its CR-VDEV#1100.

[0050] This embodiment will be described in detail below.

[0051] Figure 3 shows an overview of mapping management between addresses in SS-Family9 and addresses in SS-VDEV11S. In the figure, "GX" (X is an integer equal to or greater than 0) means generation X. Figure 3 also takes SS-Family9-0 and SS-VDEV11S0 as examples.

[0052] The processor can use meta-information to manage the mapping between addresses in VOL10 in SS-Family9-0 and addresses in SS-VDEV11S0. The meta-information includes Dir-Info (directory information) and SS-Mapping-Info (snapshot mapping information). The processor manages data in PVOL10P0 and SVOL10S0 by associating Dir-Info with SS-Mapping-Info. For data stored in VOL10, Dir-Info has information indicating the address of the reference source (address in VOL10), and SS-Mapping-Info corresponding to the data has information indicating the address of the reference destination (address in SS-VDEV11S0).

[0053] Furthermore, the processor manages the time series of PVOL10P0 and SVOL10S0 using generation information associated with Dir-Info, and for each piece of data stored in SS-VDEV11S0, manages generation information indicating the generation in which the data was created by associating it with SS-Mapping-Info. In addition, the processor manages the latest generation information at that time as the latest generation.

[0054] Before a snapshot is taken, there are data A0, B0, and C0 stored in PVOL10P0. The latest generation is "0."

[0055] Dir-Info associated with PVOL10P0 is associated with "0" as the generation # (a number indicating the generation), and includes reference information indicating the reference destination of all data A0, B0, and C0 of PVOL10P0. Hereinafter, when the generation # associated with Dir-Info is "X", it can be expressed as Dir-Info being generation X.

[0056] SS-VDEV11S0 is the storage destination for data A0, B0, and C0, and SS-Mapping-Info is associated with each of data A0, B0, and C0. Furthermore, each SS-Mapping-Info is associated with a generation # of "0." If the generation # associated with SS-Mapping-Info is "X," it can be expressed as the data corresponding to SS-Mapping-Info being generation X data.

[0057] Before the snapshot was taken, the information in Dir-Info for each of data A0, B0, and C0 references the SS-Mapping-Info corresponding to that data. By associating Dir-Info with SS-Mapping-Info in this way, PVOL10P0 and SS-VDEV11S0 are associated, and data processing for PVOL10P0 can be realized.

[0058] To acquire a snapshot, the processor copies the Dir-Info to the read-only Dir-Info of SVOL10S0. Then, the processor increments the generation of Dir-Info of PVOL10P0 and also increments the latest generation. As a result, for each of data A0, B0, and C0, SS-Mapping-Info is referenced from both Dir-Info of generation 0 and Dir-Info of generation 1.

[0059] In this way, a snapshot can be created by replicating Dir-Info, and a snapshot can be created without increasing the amount of data or SS-Mapping-Info on SS-VDEV11S0.

[0060] Here, when a snapshot is taken, the snapshot (SVOL10S0) in which writing is prohibited at the time of taking and the data is fixed becomes generation 0, and PVOL10P0, to which data can still be written after taking the snapshot, becomes generation 1. Generation 0 is the "generation one generation older in the direct line" of generation 1, and is conveniently referred to as the "parent." Similarly, generation 1 is the "generation one generation newer in the direct line" of generation 0, and is conveniently referred to as the "child." The storage system manages the parent-child relationship of generations as a Dir-Info generation management tree 70. Furthermore, the generation # of Dir-Info is the same as the generation # of the VOL10 corresponding to that Dir-Info. Furthermore, the generation # of SS-Mapping-Info is the oldest generation # of the generation # of one or more Dir-Info that reference that SS-Mapping-Info.

[0061] Fig. 4 shows an overview of the management of mapping between addresses in the SS-VDEV11S and addresses in the Dedup-VDEV11D, the management of mapping between addresses in the SS-VDEV11S and addresses in the CR-VDEV11C, and the management of mapping between addresses in the Dedup-VDEV11D and addresses in the CR-VDEV11C. Fig. 4 takes SS-VDEV11S0, CR-VDEV11C0, and 11CC as examples.

[0062] The processor can use the meta-information to manage the mapping between addresses in SS-VDEV11S0 and addresses in Dedup-VDEV11D, the mapping between addresses in SS-VDEV11S0 and addresses in CR-VDEV11C0, and the mapping between addresses in Dedup-VDEV11D and addresses in CR-VDEV11CC. As described above, the meta-information includes Dir-Info and CR-Mapping-Info. The processor manages the data in SS-VDEV11S0 and Dedup-VDEV11D by associating Dir-Info with CR-Mapping-Info. For data stored in SS-VDEV11S0, Dir-Info has information indicating the address of the reference source (address in SS-VDEV11S0), and CR-Mapping-Info corresponding to the data has information indicating the address of the reference destination (address in CR-VDEV11C0 or address in Dedup-VDEV11D). For data stored in Dedup-VDEV11D, Dir-Info has information indicating the address of the reference source (address in Dedup-VDEV11D), and CR-Mapping-Info corresponding to the data has information indicating the address of the reference destination (address in CR-VDEV11CC). By referring to the compression allocation information, the processor can identify the address in SS-VDEV11S or Dedup-VDEV11D from the address in CR-VDEV11C.

[0063] FIG. 5 shows an overview of the reverse mapping from an address in the CR-VDEV 11C to an address in the SS-VDEV 11S or Dedup-VDEV 11D.

[0064] The storage system stores compression allocation information for each piece of data whose storage destination is an SS-VDEV11S or Dedup-VDEV11D. The compression allocation information indicates a mapping between a reference address (an address in a CR-VDEV11C) and a reference address (an address in an SS-VDEV11S or Dedup-VDEV11D). By referencing the compression allocation information, the processor can identify an address in an SS-VDEV11S or Dedup-VDEV11D from an address in a CR-VDEV11C.

[0065] FIG. 6 shows an overview of the reverse mapping from addresses in the Dedup-VDEV 11D to addresses in the SS-VDEV 11S.

[0066] The storage system has Dedup-Dir-Info, which is Dir-Info for reverse mapping, for each Dedup-VDEV 11D. For each piece of data stored in the Dedup-VDEV 11D, the information in the Dedup-Dir-Info references the Dedup allocation information corresponding to that data. The Dedup allocation information indicates the address of the duplicate data for each SS-VDEV 11S where the duplicate data is stored. By referencing the Dedup-Dir-Info and the Dedup allocation information, the processor can identify the address in each of SS-VDEVs 11S0 and 11S1 from the address in the Dedup-VDEV 11D.

[0067] FIG. 7 shows an overview of the management of mapping between addresses in the CR-VDEV 11C and addresses in the page 14 of the pool 13.

[0068] Page 14 is allocated as a continuous area to CR-VDEV11C. The storage system stores Pool-Mapping-Info for each page 14. Pool-Mapping-Info indicates the reference source address (address in CR-VDEV11C) and the reference destination address (address in page 14). By referring to Pool-Mapping-Info, the processor can identify the address in page 14 from the address in CR-VDEV11C.

[0069] FIG. 8 shows the hardware configuration of the computer system.

[0070] The computer system 100 comprises a storage system 201, a server system 202, and a management system 203. The storage system 201 and the server system 202 are connected via a storage network 204 using FC (Fiber Channel) or the like. The storage system 201 and the management system 203 are connected via a management network 205 using IP (Internet Protocol) or the like. The storage network 204 and the management network 205 may be the same communication network.

[0071] The storage system 201 includes a plurality of storage controllers 210 and a plurality of SSDs 220. The storage controller 210 is connected to a plurality of SSDs 220. The plurality of SSDs 220 are an example of persistent storage devices. A pool 13 is configured based on the plurality of SSDs 220. Data stored in pages 14 of the pool 13 is stored in one or more SSDs 220.

[0072] The storage controller 210 comprises a CPU 211 , a memory 212 , a back-end interface 213 , a front-end interface 214 , and a management interface 215 .

[0073] The CPU 211 executes a program stored in the memory 212 .

[0074] The memory 212 stores programs executed by the CPU 211 and data used by the CPU 211. The memory 212 and the CPU 211 may be duplicated.

[0075] The back-end interface 213, the front-end interface 214, and the management interface 215 are examples of interface devices.

[0076] The back-end interface 213 is a communication interface device that mediates the exchange of data between the SSD 220 and the storage controller 210. A plurality of SSDs 220 are connected to the back-end interface 213.

[0077] The front-end interface 214 is a communication interface device that mediates data exchange between the server system 202 and the storage controller 210. The server system 202 is connected to the front-end interface 214 via the storage network 204.

[0078] The management interface 215 is a communication interface device that mediates the exchange of data between the management system 203 and the storage controller 210. The management system 203 is connected to the management interface 215 via a management network 205.

[0079] The server system 202 is configured to include one or more host devices. The server system 202 transmits an I / O request (write request or read request) specifying an I / O destination to the storage controller 210. The I / O destination is, for example, a logical volume number such as a LUN (Logical Unit Number), a logical address such as a LBA (Logical Block Address), or the like.

[0080] The management system 203 includes one or more management devices and manages the storage system 201.

[0081] FIG. 9 shows the configuration of the memory 212.

[0082] The memory 212 has a control information section 901 in which control information (which may also be called management information) is stored, a program section 902 in which programs are stored, and a cache section 903 in which data is temporarily stored.

[0083] FIG. 10 shows information stored in the control information section 901.

[0084] The control information unit 901 stores an ownership management table 1001, a CR-VDEV management table 1002, a snapshot management table 1003, a VOL-Dir management table 1004, a latest generation table 1005, a recovery management table 1006, a generation management tree table 1007, a snapshot allocation management table 1008, a Dir management table 1009, an SS-Mapping management table 1010, a compression allocation management table 1011, a CR-Mapping management table 1012, a Dedup-Dir management table 1013, a Dedup allocation management table 1014, a Pool-Mapping management table 1015, and a Pool allocation management table 1016.

[0085] FIG. 11 shows the programs stored in the program section 902.

[0086] The program section 902 stores a snapshot acquisition program 1101, a snapshot restore program 1102, a snapshot deletion program 1103, an asynchronous recovery program 1104, a read / write program 1105, a snapshot append program 1106, a Dedup append program 1107, a compressed append program 1108, a destaging program 1109, a GC (garbage collection) program 1110, a CPU determination program 1111, and an ownership transfer program 1112.

[0087] FIG. 12 shows the configuration of the ownership management table 1001 .

[0088] The ownership management table 1001 manages the ownership of a VOL 10 or a VDEV 11. For example, the ownership management table 1001 has an entry for each VOL 10 and each VDEV 11. The entry has information such as a VOL# / VDEV# 1201 and an owner CPU# 1202.

[0089] VOL# / VDEV# 1201 represents the identification number of VOL10 or VDEV11. Owner CPU# 1202 represents the identification number of the CPU serving as the owner CPU of VOL10 or VDEV11 (the CPU that has ownership of VOL10 or VDEV11).

[0090] Furthermore, instead of allocation in units of CPU 211, the owner CPU may be allocated in units of CPU group, or may be allocated in units of storage controller 210.

[0091] FIG. 13 shows the configuration of the CR-VDEV management table 1002.

[0092] The CR-VDEV management table 1002 indicates a CR-VDEV 11C associated with an SS-VDEV 11S or a Dedup-VDEV 11D. For example, the CR-VDEV management table 1002 has an entry for each SS-VDEV 11S and each Dedup-VDEV 11D. The entry has information such as VDEV#1301 and CR-VDEV#1302.

[0093] VDEV# 1301 represents the identification number of the SS-VDEV 11S or Dedup-VDEV 11D. CR-VDEV# 1302 represents the identification number of the CR-VDEV 11C.

[0094] FIG. 14 shows the configuration of the snapshot management table 1003 .

[0095] A snapshot management table 1003 exists for each PVOL10P (for each SS-Family9). The snapshot management table 1003 indicates the acquisition time of each snapshot (SVOL10S). For example, the snapshot management table 1003 has an entry for each SVOL10S. The entry has information such as PVOL#1401, SVOL#1402, and acquisition time 1403.

[0096] PVOL# 1401 indicates the identification number of PVOL10P. SVOL# 1402 indicates the identification number of SVOL10S. Acquisition time 1403 indicates the acquisition time of SVOL10S.

[0097] FIG. 15 shows the configuration of the VOL-Dir management table 1004.

[0098] The VOL-Dir management table 1004 shows the correspondence between VOLs and Dir-Info. For example, the VOL-Dir management table 1004 has an entry for each VOL 10. The entry has information such as VOL#1501, Root-VOL#1502, and Dir-Info#1503.

[0099] VOL#1501 represents the identification number of PVOL10P or SVOL10S. Root-VOL#1502 represents the identification number of the Root-VOL. If VOL10 is PVOL10P, the Root-VOL is the PVOL10P, and if VOL10 is SVOL10S, the Root-VOL is the PVOL10P corresponding to the SVOL10S. Dir-Info#1503 represents the identification number of Dir-Info corresponding to VOL10.

[0100] FIG. 16 shows the configuration of the latest generation table 1005 .

[0101] The latest generation table 1005 exists for each PVOL 10P (for each SS-Family 9) and indicates the generation (generation #) of the PVOL 10P.

[0102] FIG. 17 shows the configuration of the collection management table 1006 .

[0103] The collection management table 1006 may be, for example, a bitmap, and exists for each PVOL 10P (each SS-Family 9), in other words, for each Dir-Info generation management tree 70. The collection management table 1006 has an entry for each Dir-Info. The entry has information such as Dir-Info# 1701 and collection request 1702.

[0104] Dir-Info# 1701 indicates the identification number of Dir-Info. Collection request 1702 indicates whether or not collection of Dir-Info is requested. "1" means that collection is requested, and "0" means that collection is not requested.

[0105] FIG. 18 shows the configuration of the generation management tree table 1007.

[0106] A generation management tree table 1007 exists for each PVOL 10P (each SS-Family 9), in other words, for each Dir-Info generation management tree 70. The generation management tree table 1007 has an entry for each Dir-Info. The entry has information such as Dir-Info #1801, Generation #1802, Prev 1803, and Next 1804.

[0107] Dir-Info# represents the identification number of Dir-Info. Generation# 1802 represents the generation of VOL10 corresponding to Dir-Info. Prev 1803 represents the parent Dir-Info of Dir-Info (one level above). Next 1804 represents the child Dir-Info of Dir-Info (one level below). The number of Next 1804s can be the same as the number of child Dir-Infos. In Figure 18, there are two child Dir-Infos, so there are two Next 1804s (Next-A 1804A and Next-B 1804B).

[0108] FIG. 19 shows the configuration of the snapshot allocation management table 1008 .

[0109] A snapshot allocation management table 1008 exists for each SS-VDEV11S and shows the mapping from addresses in the SS-VDEV11S to addresses in the VOL10. The snapshot allocation management table 1008 has an entry for each address in the SS-VDEV11S. The entry has information such as a block address 1901, a status 1902, an allocation destination VOL# 1903, and an allocation destination address 1904.

[0110] The block address 1901 indicates the address of the block in the SS-VDEV11S. The status 1902 indicates whether the block is allocated to an address of any VOL ("1" means allocated, and "0" means free). The allocated VOL# 1903 indicates the identification number of the VOL10 (PVOL10P or SVOL10S) that has the address to which the block is allocated ("n / a" means unallocated). The allocated address 1904 indicates the address (block address) to which the block is allocated ("n / a" means unallocated).

[0111] FIG. 20 shows the configuration of the Dir management table 1009 .

[0112] A Dir management table 1009 exists for each Dir-Info and indicates the Mapping-Info of the reference destination for each data (each block data). For example, the Dir management table 1009 has an entry for each address (block address). The entry has information such as a VOL / VDEV address 2001 and a reference destination Mapping-Info # 2002.

[0113] The VOL / VDEV address 2001 indicates an address (block address) in VOL10 (PVOL10P or SVOL10S) or an address in VDEV11 (SS-VDEV11S or Dedup-VDEV11D). Referenced Mapping-Info# 2002 indicates the identification number of the referenced Mapping-Info.

[0114] FIG. 21 shows the configuration of the SS-Mapping management table 1010.

[0115] An SS-Mapping management table 1010 exists for each Dir-Info of VOL 10. The SS-Mapping management table 1010 has an entry for each SS-Mapping-Info corresponding to the Dir-Info of VOL 10. The entry has information such as Mapping-Info #2101, referenced address 2102, referenced SS-VDEV #2103, and generation #2104.

[0116] Mapping-Info #2101 indicates the identification number of SS-Mapping-Info. Reference address 2102 indicates the address referenced by SS-Mapping-Info (address in SS-VDEV11S). Reference SS-VDEV #2103 indicates the identification number of the SS-VDEV11S that has the address referenced by SS-Mapping-Info. Generation #2104 indicates the generation of the data corresponding to SS-Mapping-Info.

[0117] FIG. 22 shows the configuration of the compression allocation management table 1011.

[0118] A compression allocation management table 1011 exists for each CR-VDEV 11C and contains compression allocation information for each sub-block in the CR-VDEV 11C. The compression allocation management table 1011 contains an entry corresponding to the compression allocation information for each sub-block in the CR-VDEV 11C. The entry contains information such as a sub-block address 2201, a data length 2202, a status 2203, a first sub-block address 2204, an allocation destination VDEV# 2205, and an allocation destination address 2206.

[0119] The subblock address 2201 indicates the address of the subblock. The data length 2202 indicates the number of subblocks that make up the subblock group (one or more subblocks) in which compressed data is stored (for example, "2" means that the compressed data exists in two subblocks). The status 2203 indicates the status of the subblock ("0" means free, "1" means allocated, and "2" means that it is a target for GC (garbage collection)). The first subblock address 2204 indicates the address of the first subblock of one or more subblocks that include the subblock (one or more subblocks in which compressed data is stored). The assigned VDEV# 2205 indicates the identification number of the VDEV11 (SS-VDEV11S or Dedup-VDEV11D) that has the block to which the subblock is assigned. The assigned address 2206 indicates the address of the block to which the subblock is assigned (block address in the SS-VDEV11S or Dedup-VDEV11D).

[0120] FIG. 23 shows the configuration of the CR-Mapping management table 1012.

[0121] A CR-Mapping management table 1012 exists for each Dir-Info of a Dedup-VDEV 11 D. The CR-Mapping management table 1012 has an entry for each CR-Mapping-Info corresponding to the Dir-Info of the Dedup-VDEV 11 D. The entry has information such as Mapping-Info #2301, reference address 2302, reference CR-VDEV #2303, and data length 2304.

[0122] Mapping-Info#2301 indicates the identification number of CR-Mapping-Info. Reference address 2302 indicates the address referenced by CR-Mapping-Info (the address of the first sub-block in the sub-block group). Reference CR-VDEV#2303 indicates the identification number of the CR-VDEV 11C having the sub-block address referenced by CR-Mapping-Info. Data length 2304 indicates the number of blocks referenced by CR-Mapping-Info (blocks in Dedup-VDEV 11D) or the number of sub-blocks that make up the sub-block group referenced by CR-Mapping-Info.

[0123] FIG. 24 shows the configuration of the Dedup-Dir management table 1013.

[0124] The Dedup-Dir management table 1013 exists for each Dedup-VDEV 11D and corresponds to Dedup-Dir-Info. The Dedup-Dir management table 1013 has an entry for each address in the Dedup-VDEV 11D. The entry has information such as a Dedup-VDEV address 2401 and reference destination allocation information #2402.

[0125] The Dedup-VDEV address 2401 indicates an address (block address) in the Dedup-VDEV 11 D. The reference destination allocation information #2402 indicates the identification number of the reference destination Dedup allocation information.

[0126] FIG. 25 shows the configuration of the Dedup allocation management table 1014.

[0127] The Dedup allocation management table 1014 exists for each Dedup-VDEV 11D (for each Dedup-Dir-Info) and shows the mapping from Dedup allocation information corresponding to an address in the Dedup-VDEV 11D to an address in the SS-VDEV 11S. The Dedup allocation management table 1014 has an entry for each Dedup allocation information. The entry has information such as allocation information #2501, allocation destination SS-VDEV #2502, allocation destination address 2503, and linked allocation information #2504.

[0128] Allocation information #2501 represents the identification number of the Dedup allocation information. Allocation destination SS-VDEV #2502 represents the identification number of the SS-VDEV11S having the address referenced by the Dedup allocation information. Allocation destination address 2503 represents the address referenced by the Dedup allocation information (block address in the SS-VDEV11S). Linked allocation information #2504 represents the identification number of the Dedup allocation information linked to the Dedup allocation information.

[0129] According to Fig. 25, Dedup allocation information #3 is linked to Dedup allocation information #1, but there is no Dedup allocation information linked to Dedup allocation information #3. Therefore, it can be seen that the duplicated data in the Dedup-VDEV address corresponding to Dedup allocation information #1 is duplicated data in the SS-VDEV11S referenced by Dedup allocation information #1 and the SS-VDEV11S referenced by Dedup allocation information #3. Since the number of duplicated data is indefinite, Dedup allocation information is linked according to the number of duplicated data. If duplicated data exists in N SS-VDEV11S, N sequential Dedup allocation information is prepared.

[0130] FIG. 26 shows the configuration of the Pool-Mapping management table 1015.

[0131] A Pool-Mapping management table 1015 exists for each CR-VDEV 11C. The Pool-Mapping management table 1015 has an entry for each area in page size units in the CR-VDEV 11C. The entry has information such as a VDEV address 2601 and a page #2602.

[0132] The VDEV address 2601 indicates the starting address of an area in page size units (for example, multiple blocks). The page #2602 indicates the identification number of the allocated page 14 (for example, the address of the page 14 in the pool 13). Note that if there are multiple pools 13, the page #2602 may include the identification number of the pool 13 that has the page 14.

[0133] FIG. 27 shows the configuration of the Pool allocation management table 1016.

[0134] For example, if there are multiple pools 13, a pool allocation management table 1016 exists for each pool 13. The pool allocation management table 1016 shows the correspondence between pages 14 and areas in the CR-VDEV 11C. The pool allocation management table 1016 has an entry for each page 14. The entry has information such as a page #2701, RG #2702, a starting address 2703, a status 2704, an assigned VDEV #2705, and an assigned address 2706.

[0135] Page #2701 indicates the identification number of page 14. RG #2702 indicates the identification number of the RAID group that is the basis of page 14 (in this embodiment, a RAID group made up of two or more SSDs 220). Start address 2703 indicates the start address of page 14. Status 2704 indicates the status of page 14 ("1" means allocated, and "0" means free). Allocated VDEV #2705 indicates the identification number of the CR-VDEV11C to which page 14 is allocated ("n / a" means unallocated). Allocated address 2706 indicates the allocated address of page 14 (an address in the CR-VDEV11C) ("n / a" means unallocated).

[0136] An example of the processing performed in this embodiment will be described below.

[0137] 28 shows the flow of snapshot acquisition processing. The snapshot acquisition processing is executed by the snapshot acquisition program 1101 in response to a snapshot acquisition instruction from the management system 203 (or another system such as the server system 202). In the snapshot acquisition instruction, for example, the target PVOL10P is specified.

[0138] First, the snapshot acquisition program 1101 allocates the Dir management table 1009 that will be the copy destination, and updates the VOL-Dir management table 1004 (S2801).

[0139] The snapshot acquisition program 1101 increments the latest generation # (S2802) and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2803). At this time, the snapshot acquisition program 1101 sets the latest generation # as the copy source and the generation # before the increment as the copy destination.

[0140] The snapshot acquisition program 1101 determines whether or not there is cache dirty data for the target PVOL 10P (S2804). "Cache dirty data" may be data stored in the cache unit 903 that has not yet been written to the pool 13.

[0141] If the determination result of S2804 is true (S2804: Yes), the snapshot acquisition program 1101 causes the snapshot addition program 1106 to execute snapshot addition processing (S2805).

[0142] If the determination result of S2804 is false (S2804: No), or after S2805, the snapshot acquisition program 1101 copies the Dir management table 10009 of the target PVOL 10P to the Dir management table 1009 of the copy destination (S2806).

[0143] Thereafter, the snapshot acquisition program 1101 updates the snapshot management table 1003 (S2807) and terminates processing. In S2807, an entry is added having PVOL#1401 indicating the identification number of the target PVOL10P, SVOL#1402 indicating the identification number of the acquired snapshot (SVOL10S), and acquisition time 1403 indicating the acquisition time.

[0144] 29 shows the flow of snapshot restore processing. Snapshot restore processing is executed by the snapshot restore program 1102 in response to a restore instruction from the management system 203 (or another system such as the server system 202). The restore instruction specifies, for example, a restore source SVOL and a restore destination PVOL.

[0145] First, the snapshot restore program 1102 allocates the Dir management table 1009 as the restore destination, and updates the VOL-Dir management table 1004 (S2901).

[0146] The snapshot restore program 1102 increments the latest generation # (S2902) and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2903). At this time, the snapshot restore program 1102 sets the generation # before the increment as the copy source and sets the latest generation # as the copy destination.

[0147] The snapshot restore program 1102 purges the cache area (area in the cache unit 903) of the restore destination PVOL (S2904).

[0148] The snapshot restore program 1102 copies the Dir management table 1009 of the restore source SVOL to the Dir management table 1009 of the restore destination PVOL (S2905).

[0149] Thereafter, the snapshot restore program 1102 registers the Dir-Info# of the old Dir-Info of the restore destination in the collection management table 1006 (S2906), and ends the processing. In S2906, the collection request 1702 corresponding to the Dir-Info# is set to "1".

[0150] 30 shows the flow of snapshot deletion processing. The snapshot deletion processing is executed by the snapshot deletion program 1103 in response to a snapshot deletion instruction from the management system 203 (or another system such as the server system 202). In the restore instruction, for example, the target SVOL is specified.

[0151] First, the snapshot deletion program 1103 references the VOL-Dir management table 1004 and invalidates the Dir-Info (Dir-Info #1503) of the target SVOL (S3001).

[0152] Then, the snapshot deletion program 1103 updates the snapshot management table 1003 (S3002), registers the old Dir-Info# of the target SVOL in the recovery management table 1006 (S3003), and ends the processing. In S3003, the recovery request 1702 corresponding to the Dir-Info# is set to "1".

[0153] 31 shows the flow of asynchronous collection processing. The asynchronous collection processing is executed by the asynchronous collection program 414, for example, periodically.

[0154] First, the asynchronous collection program 1104 identifies the Dir-Info# to be collected from the collection management table 1006 (S3101). The "Dir-Info# to be collected" is the Dir-Info# for which the collection request 1702 is "1". The asynchronous collection program 1104 references the generation management tree table 1007, checks the entries for the Dir-Info# to be collected, and does not select a Dir-Info with two or more children.

[0155] Thereafter, the asynchronous collection program 1104 determines whether or not there is an unprocessed entry (S3102). The "unprocessed entry" here refers to one piece of Mapping-Info referenced by the Dir-Info identified in S3101.

[0156] If the judgment result of S3102 is true (S3102: Yes), the asynchronous collection program 1104 determines the entry to be processed (an entry containing collection request 1702 “1”) from one or more unprocessed entries (S3103), and identifies the referenced Mapping-Info#2002 from the Dir management table 1009 corresponding to the target Dir-Info (Dir-Info identified from Dir-Info#1701 in the entry to be processed) (S3104).

[0157] The asynchronous collection program 1104 refers to the generation management tree table 1007 and determines whether or not there is a child generation Dir-Info of the target Dir-Info (S3105).

[0158] If the determination result in S3105 is true (S3105: Yes), the asynchronous collection program 1104 identifies the referenced Mapping-Info #2002 from the Dir management table 1009 corresponding to the child-generation Dir-Info, and determines whether the referenced Mapping-Info #2002 of the target Dir-Info matches the referenced Mapping-Info #2002 of the child-generation Dir-Info (S3106). If the determination result in S3106 is true (S3106: Yes), the processing returns to S3102. The entry acquired in S3103 is one entry in Dir-Info. In contrast, the entry determined to match in S3106 is an entry corresponding to an address in the same SVOL in the child Dir-Info.

[0159] If the determination result in S3106 is false (S3106: No) or if the determination result in S3105 is false (S3105: No), the asynchronous collection program 1104 determines whether the generation # of the Dir-Info of the parent generation of the target Dir-Info is older than the generation # 2104 of the Mapping-Info referenced by the target Dir-Info (see FIG. 21) (S3107). If the determination result in S3107 is false (S3107: No), the process returns to S3102. The determination in S3107 is made for Mapping-Info, among the entries in the target Dir-Info, that corresponds to the same address in the VOL managed by the entry identified in S3103.

[0160] If the determination result in S3107 is true (S3107: Yes), the asynchronous collection program 1104 initializes the target entry in the SS-Mapping management table 1010, and releases the target entry in the snapshot allocation management table 1008 (S3108). Thereafter, processing returns to S3102. The release in S3108 corresponds to the release of a block in an SS-VDEV. S3108 corresponds to invalidation of a Mapping-Info unit. Furthermore, in S3108, the "target entry" is the entry corresponding to the block address referenced by the SS-Mapping-Info for which the determination result in S3107 was Yes.

[0161] If the determination result in S3102 is false (S3102: No), the asynchronous collection program 1104 updates the collection management table 1006 (S3109) and also updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S3110), and terminates processing. S3109 is the collection of Dir-Info, and the collection request 1702 is updated from "1" to "0". If the Mapping-Info referenced by the Dir-Info to be collected is also referenced by other Dir-Info, the target Dir-Info is collected with the Mapping-Info remaining. In S3110, the invalidated (collected) Dir-Info is pulled out of the tree, and the tree connection relationships are updated.

[0162] 32 shows the flow of the write process (front end). The write process (front end) is executed by the read / write program 1105 when a write request is received from the server system 202.

[0163] First, the read / write program 1105 determines whether the target data of the write request is a cache hit (S3201). A "cache hit" means that a cache area corresponding to the write destination VOL address of the target data (the VOL address specified in the write request) has been secured. If the determination result in S3201 is false (S3201: No), the read / write program 1105 secures a cache area corresponding to the write destination VOL address of the target data from the cache unit 903 (S3202). Then, processing proceeds to S3206.

[0164] If the determination result of S3201 is true (S3201: Yes), the read / write program 1105 determines whether the cache hit data (data in the allocated cache area) is dirty data (data not reflected (not written) in the pool 13) (S3203). If the determination result of S3203 is false (S3203: No), the process proceeds to S3206.

[0165] If the determination result of S3203 is true (S3203: Yes), the read / write program 1105 determines whether the WR (Write) generation # of the dirty data matches the generation # of the target data of the write request (S3204). The "WR generation #" is the latest generation # of the snapshot when the data was written to the cache, and is held, for example, in cache data management information (not shown). The generation # of the target data of the write request is acquired from the latest generation # 403. S3204 is a process to prevent the target data (dirty data) of the most recently acquired snapshot from being updated with the target data of the write request before the append process for that target data has been completed, thereby overwriting the snapshot data. If data written before the host write (write in accordance with a write request from the server system 202) is already in the cache and a snapshot is taken before the host write, the data in the cache becomes snapshot data. If a host write request is accepted in this state, the WR generation # and the latest generation # will not match.

[0166] If the determination result in S3204 is false (S3204: No), the read / write program 1105 causes the snapshot append program 1106 to execute snapshot append processing (S3205).

[0167] After S3202, or if the determination result of S3204 is true (S3204: Yes), the read / write program 1105 writes the target data of the write request to the cache area secured in S3202 or to the cache area obtained through S3205 (S3206). Thereafter, the read / write program 1105 sets the WR generation # of the data written in S3206 to the latest generation # compared in S3204 (S3207), and returns a normal response (Good response) to the server system 202 (S3208).

[0168] Fig. 33 shows the flow of write processing (backend). Write processing (backend) is a process in which, when unreflected data (dirty data) exists in the cache unit 903, the unreflected data is written to the pool 13. Write processing (backend) is performed synchronously or asynchronously with write processing (frontend). Write processing (backend) is executed by the read / write program 1105.

[0169] The read / write program 1105 determines whether or not there is dirty data in the cache unit 903 (S3301). If the determination result of S3301 is true (S3301: Yes), the read / write program 1105 causes the snapshot append program 1106 to execute snapshot append processing (S3302).

[0170] 34 shows the flow of snapshot addition processing, which is executed by the snapshot addition program 1106 called by the snapshot acquisition program 1101 or the read / write program 1105.

[0171] The snapshot append program 1106 updates the snapshot allocation management table 1008 to reserve a new area (block address where status 1902 is "0") in the target SS-VDEV11S (SS-VDEV11S corresponding to SS-Family 9 including the target VOL (for example, the SVOL to be acquired or the VOL to which data is written)) (S3401). Then, the snapshot append program 1106 causes the Dedup append program 1107 to execute the Dedup append process (S3402).

[0172] Thereafter, the snapshot append program 1106 updates the SS-Mapping management table 1010 (S3403). In S3403, for example, the snapshot append program 1106 sets the latest generation # (the generation # indicated by the latest generation table 1005) to the generation # 2104 corresponding to the Mapping-Info # of the target SS-Mapping-Info. The "target SS-Mapping-Info" here refers to the SS-Mapping-Info corresponding to the data in the target VOL.

[0173] The snapshot append program 1106 updates the Dir management table 1009 corresponding to the Dir-Info of the target SS-VDEV 11S (S3404). In S3404, the SS-Mapping-Info (information indicating the reference address in the SS-VDEV) for the data to be written is associated with the address of the data in VOL 10.

[0174] The snapshot append program 1106 references the generation management tree table 1007 (Dir-Info generation management tree 70) (S3405) and determines whether the generation # of the Dir-Info of the target VOL (the VOL to which data is written) matches the generation # of the SS-Mapping-Info before appending (S3406). "SS-Mapping-Info before appending" refers to the Mapping-info that manages the data before the update (in other words, of the Mapping-info referenced by Dir-Info, the SS-Mapping-Info that corresponds to the data before the update is the subject of determination in S3406). "Before appending" means before the snapshot append process is performed.

[0175] If the determination result of S3406 is true (S3406: Yes), the snapshot appending program 1106 initializes the target entry in the SS-Mapping management table 1010 before appending (for example, sets an invalid value to the target entry), releases the target entry in the snapshot allocation management table 1008 (specifically, the entry corresponding to the block address indicated by the referenced address 2102 in the SS-Mapping management table 1010 before appending) (S3407), and terminates processing. By performing S3407 if S3406: Yes, the area that is no longer referenced can be garbage collected and made reusable.

[0176] 35 shows the flow of the Dedup append process, which is executed by the Dedup append program 1107 called from the snapshot append program 1106.

[0177] The Dedup append program 1107 determines whether or not duplicate data exists (S3501). If the determination result of S3501 is false (S3501: No), the Dedup append program 1107 causes the compression append program 1108 to execute compression append processing (S3508). As a result, the compressed data of the data whose storage destination is the SS-VDEV 11S is stored in the CR-VDEV 11C without passing through the Dedup-VDEV 11D and without changing the CPU 211 that is the processing subject. Note that if S3501: No, as indicated by the dashed-dotted arrow, the Dedup append processing ends after S3508. Furthermore, the Dedup append program 1107 may manage a directory of hash values ​​of data stored in each block in the Dedup-VDEV 11D, and may determine in S3501 whether or not a hash value matching the hash value of the written data is in the directory.

[0178] If the determination result of S3501 is true (S3501: Yes), the Dedup append program 1107 causes the CPU determination program 1111 to execute CPU determination processing (S3502). S3502 is executed because there is a possibility that the CPU 211 executing the Dedup append program 1107 in question does not match the owner CPU of the target Dedup-VDEV 11D (the Dedup-VDEV 11D that will store duplicate data). If the CPU 211 executing the Dedup append program 1107 in question does not match the owner CPU of the target Dedup-VDEV 11D, processing is handed over from the CPU 211 in question to the CPU 211 that serves as the owner CPU. That is, S3503 to S3507 are performed by the Dedup append program 1107, but the CPU 211 executing the Dedup append program 1107 may be the same CPU 211 as the CPU 211 that performed S3501, or a different CPU 211. In other words, the CPU 211 that performs S3503 to S3507 is the owner CPU of the Dedup-VDEV 11D where the data is stored.

[0179] After S3502, the Dedup append program 1107 updates (S3503) the Dedup allocation management table 1014. In S3503, an entry for Dedup allocation information corresponding to data whose storage destination is the target Dedup-VDEV 11D is added to the Dedup allocation management table 1014.

[0180] After S3503, S3508 is performed. Thereafter, the Dedup appending program 1107 updates the CR-Mapping management table 1012 (S3504). In S3504, an entry for CR-Mapping-Info corresponding to data whose storage destination is the Dedup-VDEV 11D is added to the CR-Mapping management table 1012.

[0181] The Dedup appending program 1107 updates the Dir management table 1009 corresponding to the target Dedup-VDEV 11D (S3505). In S3505, the CR-Mapping-Info (information indicating the reference address in the CR-VDEV 11CC) for the duplicate data is associated with the address of the data in the target Dedup-VDEV 11D.

[0182] The Dedup append program 1107 initializes the CR-Mapping management table 1012 before appending (S3506). Note that the tables to be updated in S3504 and S3506 are different. Specifically, in S3504, the entry to be updated is the entry indicating the address where data will be written, and in S3506, the entry to be updated is the entry indicating the address where the data before the update is stored. Until S3506 is performed, two CR-Mapping-Info exist, and in S3505, the connection destination of Dir-Info is switched from CR-Mapping-Info pointing to the old address to CR-Mapping-Info pointing to the new address. Thereafter, in S3506, the CR-Mapping-Info pointing to the old address is released, and the released CR-Mapping-Info becomes available for reuse as CR-Mapping-Info in a different area.

[0183] The Dedup append program 1107 invalidates the pre-update allocation information (S3507). The invalidation at S3507 is a process for freeing up the VDEV area (area in the VDEV) to which the pre-update data was allocated. At S3507, the Dedup append program 1107 updates the Dedup allocation management table 1014 and the compression allocation management table 1011. If the allocation destination of the pre-update data is the Dedup-VDEV 11D, the entry in the Dedup allocation management table 1014 (the entry for the allocation destination of the pre-update data) is freed. If the allocation destination of the pre-update data is the CR-VDEV 11C, the entry in the pre-update data in the compression allocation management table 1011 (the entry for the allocation destination of the pre-update data) is freed and garbage collected. In addition, in S3507, for areas in the Dedup allocation management table 1014 where the number of allocation destinations has reached 0 (a state in which the value of reference destination allocation information #2402 corresponding to the Dedup-VDEV address 2401 is not registered (invalid value)), the target entries of the compression allocation information are garbage collected (status 2203 of the compression allocation management table 1011 is updated to "2").

[0184] 36 shows the flow of the compression and append process, which is executed by the compression and append program 1108 called from the Dedup append program 1107.

[0185] The compression append program 1108 compresses the data to be written (S3601). The compression append program 1108 updates the compression allocation management table 1011 (S3602). In S3602, for each of one or more sub-blocks that are to store the compressed data in S3601, the entry corresponding to that sub-block is updated.

[0186] The compression append program 1108 causes the destage program 1109 to execute the destage process (S3603).

[0187] The compression append program 1108 updates the CR-Mapping management table 1012 (S3604). The CR-Mapping management table 1012 has an entry indicating the reference destination of the data before the update and an entry indicating the reference destination after the update, and the entries are switched by the Dir management table 1009. The reference destination address where the updated data is stored is registered in an empty entry of the CR-Mapping management table 1012.

[0188] The compression and append program 1108 updates the Dir management table 1009 (S3605). If S3501: No, the Dir management table 1009 corresponding to the SS-VDEV is updated. If S3501: Yes, the Dir management table 1009 corresponding to the Dedup-VDEV is updated.

[0189] The compression append program 1108 invalidates the pre-update allocation information (S3607). In S3607, the Dedup append program 1107 updates the Dedup allocation management table 1014 and the compression allocation management table 1011. The invalidation in S3607 is a process for freeing up the area in which the pre-update data is stored, and making the freed up area available for allocation when other data is stored. If the pre-update data is mapped to the Dedup-VDEV 11D, the release destination is the Dedup allocation management table 1014. If the pre-update data is mapped to the CR-VDEV 11C, the release destination is the compression allocation management table 1011. In addition, in S3607, for areas in the Dedup allocation management table 1014 where the number of allocation destinations has reached 0 (a state in which the value of reference destination allocation information #2402 corresponding to the Dedup-VDEV address 2401 is not registered (invalid value)), the target entries of the compression allocation information are garbage-collected (status 2203 of the compression allocation management table 1011 is updated to "2").

[0190] 37 shows the flow of destage processing, which is executed by the destage program 1109 called from the compressed append program 1108.

[0191] The destaging program 1109 determines whether or not there is additional data (one or more compressed data) for a RAID stripe in the cache unit 903 (S3701). A "RAID stripe" is a stripe in a RAID group (a storage area spanning multiple SSDs 220 that make up the RAID group). If the RAID level of the RAID group requires parity, the size of the "additional data for a RAID stripe" may be the size of the stripe minus the size of the parity. If the determination result of S3701 is false (S3701: No), processing ends.

[0192] If the determination result of S3701 is true (S3701: Yes), the destaging program 1109 references the Pool-Mapping management table 1015 and determines whether page 14 has been allocated to the storage destination (address in CR-VDEV 11C) for the additional data for the RAID stripe (S3702). If the determination result of S3702 is false (S3702: No), the process proceeds to S3705.

[0193] If the determination result of S3702 is true (S3702: Yes), the destaging program 1109 updates the Pool allocation management table 1016 (S3703). Specifically, the destaging program 1109 allocates page 14. In S3703, entries (for example, status 2704, allocated VDEV# 2705, and allocated address 2706) corresponding to the allocated page 14 in the Pool allocation management table 1016 are updated.

[0194] The destaging program 1109 registers the allocated page, page #2602, in the entry corresponding to the storage destination of the additional data for the RAID stripe in the Pool allocation management table 1016 (S3704).

[0195] The destaging program 1109 writes the additional data for the RAID stripe to the stripe that is the basis of the page (S3705). If the RAID level requires parity, the destaging program 1109 generates parity based on the additional data for the RAID stripe and writes the parity to the stripe as well.

[0196] 38 shows the flow of GC (garbage collection) processing. GC processing is executed by the GC program 1110, for example, periodically (or in response to an instruction from the management system 203).

[0197] The GC program 1110 references the Pool-Mapping management table 1015 and the compression allocation management table 1011, and identifies pages that have sub-blocks in a garbage state (status 2203 "2") (S3801). If there are no pages that have sub-blocks in a garbage state, the GC processing may end. Also, in S3801, the GC program 1110 may preferentially select, from among multiple CR-VDEVs 11C, the CR-VDEV 11C that has the least free space. Also, in S3801, the GC program 1110 may preferentially identify, from among the CR-VDEVs 11C, pages that have the most sub-blocks in a garbage state. Also, GC may be performed in area units other than pages 14.

[0198] The GC program 1110 determines whether or not there is an unprocessed sub-block (not yet determined in S3803) in the page identified in S3801 (S3802).

[0199] If the determination result of S3802 is true (S3802: Yes), the GC program 1110 references the compression allocation management table 1011 and determines the subblock to be processed (S3803). The GC program 1110 determines whether the status 2203 corresponding to the subblock to be processed is "1" (allocated) (S3804). If the determination result of S3804 is false (S3804: No), the processing returns to S3802. If the determination result of S3804 is true (S3804: Yes), the GC program 1110 adds the subblock to be processed to a separate area (S3805). This "separate area" may be a free subblock (a subblock whose status 2203 is "0") in a CR-VDEV 11C other than the CR-VDEV 11C to be subjected to GC processing (the CR-VDEV 11C having the subblock to which the page identified in S3801 is allocated). This "another CR-VDEV11C" may be a CR-VDEV11C in which all sub-blocks are sub-blocks of a flow. A page 14 may be allocated to this "another area," and compressed data in the sub-block to be processed may be written to the page 14 (in other words, compressed data may be moved from a page allocated to the sub-block to be processed to a page allocated to the other area).

[0200] If the determination result of S3802 is false (S3802: No), the GC program 1110 updates all entries in the compression allocation management table 1011 corresponding to the CR-VDEV 11C that is the target of GC processing (S3806). In S3806, for example, the status 2203 of all entries becomes "0".

[0201] Furthermore, the GC program 1110 updates the Pool-Mapping management table 1015 and the Pool allocation management table 1016 (S3807). In S3806, for example, the page #2602 of all entries in the Pool-Mapping management table 1015 that correspond to the CR-VDEV 11C that is the target of GC processing may be initialized, and the status 2704 corresponding to all pages that were allocated to the CR-VDEV 11C that is the target of GC processing may be set to "0" (free).

[0202] In this way, the GC processing according to this embodiment merely transfers valid compressed data (compressed data in allocated sub-blocks) between CR-VDEVs 11C in order to make multiple allocated sub-blocks that are non-contiguous contiguously contiguous. Note that making multiple allocated sub-blocks that are non-contiguous contiguously contiguous may be performed without transferring data between CR-VDEVs 11C.

[0203] 39 shows the flow of the CPU determination process, which is executed by the CPU determination program 1111 called from the Dedup append program 1107.

[0204] The CPU determination program 1111 refers to the ownership management table 1001 and determines whether the owner CPU of the Dedup-VDEV 11D to be processed is its own CPU 211 (the CPU 211 that performed the determination in S3501) (S3901).

[0205] If the determination result of S3901 is false (S3901: No), the CPU determination program 1111 passes the processing of its own CPU to the owner CPU (S3902). As a result, the owner CPU takes over the processing, and as a result, the CPU that performs the processing from S3503 onwards in Figure 35 becomes the owner CPU of the Dedup-VDEV11D (the CPU that takes over the processing).

[0206] The CPU determination process may also be performed in processes other than the Dedup append process shown in Fig. 35, but in this embodiment, in processing from VOL10 to CR-VDEV11C, the CPU determination process may be performed only when the owner CPU may be different, specifically, only when the Dedup-VDEV11D is the write destination. In other words, when the write destination is VOL10, SS-VDEV11S, or CR-VDEV11C, the owner CPU for these is the same, so the CPU determination process does not need to be performed. This is expected to improve the performance of the write process.

[0207] 40 shows the flow of ownership transfer processing. The ownership transfer processing is performed by the ownership transfer program 1112, for example, in response to an instruction from the management system 203, or when a failure occurs in the CPU 211. The CPU 211 that executes the ownership transfer program 1112 may be any normal CPU 211, or may be the CPU 211 with the lowest load.

[0208] The ownership transfer program 1112 obtains all SVOL#1402 in the target SS-Family9 from the snapshot management table 1003 (S4001). The "target SS-Family9" is the SS-Family9 that has the target PVOL10P. The "target PVOL10P" may be the PVOL10P specified in an instruction from the management system 203, or may be the PVOL10P for which the CPU 211 in which the failure occurred is the owner CPU.

[0209] The ownership transfer program 1112 also references the Dir management table 1009, the CR-VDEV management table 1002, and the CR-Mapping management table 1012, and acquires the CR-VDEV#1302 of all CR-VDEVs 11C related to the target PVOL 10P (S4002). "CR-VDEVs 11C related to the target PVOL 10P" are CR-VDEVs 11C that are assigned to SS-VDEVs 11S of the target SS-Family 9.

[0210] The ownership transfer program 1112 updates the owner CPU# 1202 of SVOL10S, the SVOL# obtained in S4001, CR-VDEV11C, the CR-VDEV# obtained in S4002, the target PVOL10P, and SS-VDEV11S of the target SS-Family9 (S4003). The owner CPU# 1202 after the update has the same identification number. In other words, the same CPU holds the ownership of SVOL10S, the SVOL# obtained in S4001, CR-VDEV11C, the CR-VDEV# obtained in S4002, the target PVOL10P, and SS-VDEV11S of the target SS-Family9. [Embodiment 2]

[0211] The second embodiment will be described below, focusing mainly on the differences from the first embodiment, and explanations of the commonalities with the first embodiment will be omitted or simplified.

[0212] In the second embodiment, SVOL10S may be a snapshot for which writing is permitted. Hereinafter, a write-enabled SVOL (snapshot) will be referred to as a "WR-SVOL," which is an abbreviation for a writable SVOL, and a read-only SVOL (snapshot) will be referred to as a "RO-SVOL."

[0213] FIG. 41 shows an overview of obtaining WR-SVOL.

[0214] When creating a WR-SVOL, the processor prepares RO-Dir-Info and R / W-Dir-Info for the WR-SVOL. RO-Dir-Info is write-protected (Read Only) Dir-Info. R / W-Dir-Info is write-enabled (for Read / Write).

[0215] The processor sets the latest generation # before the snapshot was created (the generation # indicated by the latest generation table 1005) as the generation # of RO-Dir-Info, and sets the incremented generation # of RO-Dir-Info as the generation # of R / W-Dir-Info. The processor sets the incremented generation # of R / W-Dir-Info as the latest generation # and the generation # of Dir-Info of PVOL.

[0216] 41, the latest generation # before the snapshot was created is "0." Therefore, the generation # of RO-Dir-Info is "0," the generation # of R / W-Dir-Info is "1," and the latest generation # after the snapshot was created and the generation # of PVOL's Dir-Info are each "2."

[0217] In the Dir-Info generation management tree 70, the RO-SVOL (Read Only SVOL) corresponding to generation 0 is the parent, and the RW-SVOL corresponding to generation 1 and the PVOL of generation 2 are the children.

[0218] FIG. 42 shows an outline of writing to WR-SVOL.

[0219] When data A0 in WR-SVOL is rewritten with data A1, the processor secures a new area in the SS-VDEV and designates that area as the storage destination for data A1. For the new data A1 in the SS-VDEV, the processor generates new SS-Mapping-Info and associates the SS-Mapping-Info of data A1 with generation information indicating the generation # of the WR-SVOL. Therefore, the generation # of the SS-Mapping-Info of data A1 becomes "1".

[0220] The processor associates the write destination address in the PVOL with the data A1 to be written by switching the reference relationship (correspondence) between Dir-Info and SS-Mapping-Info of generation 1.

[0221] This change in reference destination eliminates the reference from generation 1 to the SS-Mapping-Info of data A0. However, the SS-Mapping-Info of data A0 remains referenced by the RO-Dir-Info (generation 0) of WR-SVOL. For this reason, the SS-Mapping-Info of data A0 should not be invalidated.

[0222] The processor determines whether or not this invalidation is possible. This determination involves comparing the generation # of the Mapping-Info being determined to be invalid with the generation # of the R / W-Dir-Info of the write destination VOL (here, WR-SVOL). If these generation #s match, the processor determines that invalidation is possible. On the other hand, if the generation # of the Mapping-Info is older, the processor determines that invalidation is not possible.

[0223] FIG. 43 shows an overview of restoring from WR-SVOL.

[0224] When restoring from WR-SVOL to PVOL (for example, PVOL of generation 2), the processor creates new RO-Dir-Info and R / W-Dir-Info for the PVOL to which the data is to be restored. Both RO-Dir-Info and R / W-Dir-Info are copies of the R / W-Dir-Info of WR-SVOL.

[0225] The generation # of the new RO-Dir-Info is the same as the generation # of R / W-Dir-Info of WR-SVOL, the restore source. On the other hand, the generation # of the new R / W-Dir-Info is the generation # of PVOL, the restore destination, incremented by two. The generation # of R / W-Dir-Info of WR-SVOL, the restore source, is the generation # of the original generation # incremented by two.

[0226] As a result, as shown in the example of FIG. 43, the latest generation # becomes "4" as a result of the generation # of the restore destination PVOL being incremented by two.

[0227] The generation # of the RO-Dir-Info of the restore source is "0". The generation # of the RO-Dir-Info of the restore destination is "1", and the generation # of the old Dir-Info of the restore destination is "2", and both are children of generation # "0".

[0228] The generation # of the R / W-Dir-Info of the restore source will be "3", and the generation # of the R / W-Dir-Info of the restore destination will be "4", both of which will be children of generation # "1".

[0229] As a result of the restore, the old Dir-Info of generation 2 is released from its correspondence with the PVOL, and becomes the target of asynchronous collection, no longer referenced by the PVOL or SVOL (snapshot). In other words, the processor invalidates this Dir-Info of generation 2. The processor also identifies generation # "2" as the generation to be invalidated.

[0230] Although several embodiments have been described above, these are merely examples for explaining the present invention, and the scope of the present invention is not limited to these embodiments. The present invention can be implemented in various other forms.

[0231] The above description can be summarized, for example, as follows: The following summary may include supplementary explanations and explanations of modifications of the above description.

[0232] In a storage system 201 including a storage device and a processor, the storage device stores first mapping information and second mapping information.

[0233] The first mapping information includes, for each SS-Family 9, information indicating mapping between the address of a VOL 10 in the SS-Family 9 and an address in the SS-VDEV 11S. For example, the first mapping information includes Dir-Info (an example of first control information) for each VOL 10 and SS-Mapping-Info (an example of second control information) for each data item in the SS-VDEV 11S. The Dir-Info for each VOL is associated with the generation # of the VOL and indicates which SS-Mapping-Info is to be referenced for an address in the VOL. The SS-Mapping-Info for each data item is associated with the oldest generation # of the Dir-Info that references the SS-Mapping-Info and indicates the address where the data is located in the SS-VDEV 11S.

[0234] The second mapping information includes information indicating mapping between addresses in SS-VDEV11S and addresses in Dedup-VDEV10D. For example, the second mapping information includes Dir-Info (an example of third control information) prepared for each of SS-VDEV11S0 and Dedup-VDEV11D, and CR-Mapping-Info (an example of fourth control information) that is associated one-to-one with data whose storage destination is SS-VDEV11S or Dedup-VDEV10D.

[0235] There are one or more SS-VDEV11S for each of the multiple SS-Family 9. Each SS-VDEV11S is a logical address space (virtual device) that is the storage destination for data of VOL10 in the SS-Family 9 corresponding to that SS-VDEV11S. A Dedup-VDEV10D is a logical address space (virtual device) separate from the SS-VDEV11S.

[0236] If the same data exists in multiple VOLs 10 of an SS-Family 9, the processor updates the first mapping information so that multiple addresses of the same data in the multiple VOLs 10 are mapped to addresses of SS-VDEVs 11S of the SS-Family 9. If duplicate data exists in two or more SS-VDEVs 11S of two or more SS-Family 9, the processor updates the second mapping information so that two or more addresses of the duplicate data in the two or more SS-VDEVs 11S are mapped to addresses in the Dedup-VDEV 10D that correspond to the duplicate data.

[0237] This allows the address mapping to be changed in a short time even if the address of the duplicated data is changed.

[0238] The second mapping information may further include the following information: A set of Dir-Info of SS-VDEV11S and CR-Mapping-Info that is referenced from the Dir-Info and references an address in CR-VDEV11C (an example of an append virtual device). This set is an example of information that indicates the mapping between an address in SS-VDEV11S and an address in CR-VDEV11C. A set of Dir-Info of the Dedup-VDEV 10D and CR-Mapping-Info that is referenced from the Dir-Info and references an address in the CR-VDEV 11C. This set is an example of information that indicates the mapping between an address in the Dedup-VDEV 10D and an address in the CR-VDEV 11C.

[0239] Each CR-VDEV 11C may be a logical address space (virtual device) corresponding to either an SS-VDEV 11S or a Dedup-VDEV 10D. Each CR-VDEV 11C may be a storage destination for data that is stored in a virtual device corresponding to the CR-VDEV 11C, but may not be a storage destination for data that is stored in a virtual device that does not correspond to the CR-VDEV 11C.

[0240] The processor may be configured to store data whose storage destination is the CR-VDEV11C in the pool 13. The pool 13 may be a logical address space based on at least one of at least a portion of the storage device of the storage system 201 and at least a portion of the external storage device of the storage system 201. When the data to be stored in the CR-VDEV11C is update data, the processor may set the storage destination of the update data to an empty address in the CR-VDEV11C, invalidate the address of the data before the update, and update the second mapping information so that an address in the SS-VDEV11S or Dedup-VDEV10D that was mapped to the address of the data before the update is mapped to the storage destination address of the update data in the CR-VDEV11C.

[0241] The mapping between the address in the CR-VDEV 11C and the address in the pool 13 may be 1:1.

[0242] This allows the address mapping to be changed in a short time even if the address of the compressed data of the duplicated data in the CR-VDEV 11C is changed (for example, even if the address is changed due to GC processing).

[0243] The processor may be a plurality of CPUs 211 (an example of a plurality of processor devices). When the CPU 211 corresponds to the owner CPU of a VOL or VDEV, each CPU 211 may be configured to perform I / O for the VOL or VDEV and update the address mapping information for the VOL or VDEV in the first mapping information and second mapping information. The owner CPU of SS-Family 9, the owner CPU of SS-VDEV 11S for the SS-Family 9, and the owner CPU of CR-VDEV 11C corresponding to the SS-VDEV 11S may be the same CPU 211. As a result, in write processing of non-duplicate data, the owner CPU is consistently the same CPU, so there is no need to transfer ownership between CPUs 211 (communication for taking over processing between CPUs 211).

[0244] The owner CPU of the Dedup-VDEV 10D and the owner CPU of the CR-VDEV 11CC corresponding to that Dedup-VDEV 10D may be the same CPU 211. This eliminates the need to transfer ownership between CPUs 211 when writing to the Dedup-VDEV 10D and the corresponding CR-VDEV 11CC.

[0245] When a Dedup-VDEV 10D is the write destination, each CPU 211 may perform CPU determination as to whether or not the CPU 211 is the owner CPU of the Dedup-VDEV 10D. In other words, when the Dedup-VDEV 10D is not the write destination, the CPU 211 does not need to perform CPU determination. This is expected to improve processing performance.

[0246] When processing a write request specifying any PVOL10P, the processor may perform processing in the snapshot append process (for example, writing to a CR-VDEV11C associated with an SS-VDEV11S of SS-Family9 that includes the PVOL10P, or writing to a Dedup-VDEV10D) if the following conditions (a) and (b) are met. (a) The cache area corresponding to the address specified in the write request is in the cache unit 903, and the data in the cache area is dirty data that has not been reflected in the pool 13. (b) The generation of the dirty data is different from the latest generation of the PVOL10P.

[0247] The processor may determine whether or not to invalidate Dir-Info and / or SS-Mapping-Info for each SS-Family 9 based on the generation of Dir-Info and the generation of SS-Mapping-Info, asynchronously with the processing of an I / O request for a VOL in the SS-Family 9, and invalidate Dir-Info and / or SS-Mapping-Info that is determined to be invalid. Whether or not to invalidate can be determined efficiently even without reverse reference meta information (for example, reference information from pool 13 to VOL 10).

[0248] The processor may invalidate the SS-Mapping-Info referenced by the target Dir-Info when the following conditions (x) and (y) are met: (x) The generation of SS-Mapping-Info referenced by Dir-Info that is one generation newer than the target Dir-Info does not match the generation of SS-Mapping-Info referenced by the target Dir-Info. (y) The generation of the Dir-Info that is one generation older than the target Dir-Info is older than the generation of the SS-Mapping-Info referenced by the target Dir-Info.

[0249] When creating a WR-SVOL, the processor may create RO-Dir-Info and R / W-Dir-Info for the SVOL, and may set the latest generation before the creation of the SVOL as the generation of RO-Dir-Info, and the generation obtained by incrementing the generation of the RO-Dir-Info as the generation of R / W-Dir-Info.

[0250] The processor may compare the generation of the SS-Mapping-Info with the generation of the R / W-Dir-Info of the WR-SVOL. If the generation of the SS-Mapping-Info and the generation of the R / W-Dir-Info match, the processor may invalidate the SS-Mapping-Info. If the generation of the SS-Mapping-Info is older than the generation of the R / W-Dir-Info, the processor may not invalidate the SS-Mapping-Info.

[0251] When restoring data from WR-SVOL to a PVOL, the processor may create RO-Dir-Info and R / W-Dir-Info for the PVOL at the restore destination as copies of the R / W-Dir-Info of WR-SVOL. In this case, the processor may set the generation of the RO-Dir-Info for the PVOL at the restore destination to the generation of the R / W-Dir-Info of WR-SVOL, set the generation of the R / W-Dir-Info for the PVOL at the restore destination to two generations newer than the generation of the PVOL at the restore destination, and set the generation of the R / W-Dir-Info for the WR-SVOL to two generations newer than the original generation of the R / W-Dir-Info. If the original Dir-Info of the PVOL at the restore destination is not referenced by any of the PVOLs or SVOLs, the processor may invalidate the Dir-Info.

[0252] When the generation of Dir-Info to be invalidated is identified as the target generation, the processor may determine whether or not to invalidate the target generation based on the reference state of the immediately older generation in the direct lineage of the target generation and the reference state of the immediately newer generation in the direct lineage of the target generation. This allows the determination of whether or not to invalidate the target generation to be made without having to look at all generations.

[0253] When creating SVOL10S, the processor may increment the latest generation by one, using the latest generation before creation as the generation of the SVOL10S, and may also increment the latest generation when restoring from SVOL10S to one of the PVOL10Ps.

[0254] When writing to PVOL10P, the processor may designate a new area in SS-VDEV11S as the storage destination for the data to be written, and may switch the correspondence between Dir-Info and SS-Mapping-Info to associate the write destination address in PVOL10P with the data to be written, associate the generation of PVOL10P with SS-Mapping-Info, and designate SS-Mapping-Info whose correspondence with Dir-Info has been canceled by switching the correspondence as the target for invalidation. If the generation of the SS-Mapping-Info to be invalidated matches the generation associated with Dir-Info in PVOL10P, the processor may determine that invalidation is possible. This makes it possible to determine whether already stored data should be invalidated when a write process is triggered, and to efficiently determine whether invalidation is possible. When the processor invalidates SS-Mapping-Info, it may invalidate the data referenced by that SS-Mapping-Info.

[0255] When restoring from SVOL10S to PVOL10P, the processor may associate a copy of Dir-Info of SVOL10S, the restore source, with PVOL10P, increment the latest generation, and identify the generation of Dir-Info that was associated with PVOL10P before the restore as the generation to be invalidated.For SS-Mapping-Info associated with Dir-Info of the target generation, if the generation associated with SS-Mapping-Info is newer than the generation one step older in the direct line of the target generation and is not referenced by the generation one step newer in the direct line of the target generation, the processor may determine that invalidation is possible.

[0256] Furthermore, when deleting SVOL10S, the processor may identify the generation associated with the Dir-Info of the deleted SVOL10S as the generation to be invalidated. For SS-Mapping-Info associated with the Dir-Info of the target generation, if the generation associated with the SS-Mapping-Info is newer than the immediately older generation in the direct line of the target generation and is not referenced by the immediately newer generation in the direct line of the target generation, the processor may determine that invalidation is possible. [Explanation of symbols]

[0257] 201: Storage system

Claims

1. A storage system including a storage device and a processor, the storage device stores first mapping information and second mapping information; the first mapping information includes, for each of a plurality of snapshot families each made up of a PVOL (Primary Volume) and an SVOL (Secondary Volume) which is a snapshot of the PVOL, information indicating a mapping between an address of the PVOL or SVOL which is a VOL (Volume) in the snapshot family and an address in a snapshot virtual device; the second mapping information includes information representing a mapping between an address in a snapshot virtual device and an address in a deduplication virtual device; The processor: updating the first mapping information and the second mapping information, respectively; garbage-collecting an address in the snapshot virtual device that is no longer mapped to an address of the VOL in the snapshot family due to the update of the first mapping information; garbage-collecting addresses in the deduplication virtual device that are no longer mapped to addresses in the snapshot virtual device due to the update of the second mapping information; Storage system.

2. a write-once virtual device having an address mapped to an address in the snapshot virtual device or an address in the deduplication virtual device; In the garbage collection, the areas of the write-once virtual device that are mapped to the garbage-collected addresses in the snapshot virtual device and the deduplication virtual device are released. The storage system according to claim 1 .

3. for each of a plurality of snapshot families, there are one or more snapshot virtual devices; Each snapshot virtual device is a virtual device serving as a logical address space that is a storage destination for data of a VOL in a snapshot family corresponding to the snapshot virtual device, the deduplication virtual device is a virtual device that serves as a logical address space separate from that of the snapshot virtual device, If the same data exists in a plurality of VOLs of a snapshot family, the processor updates the first mapping information so as to map a plurality of addresses of the same data in the plurality of VOLs to addresses of a snapshot virtual device of the snapshot family; If there is duplicate data in two or more snapshot virtual devices of two or more snapshot families, the processor updates the second mapping information so as to map two or more addresses of the duplicate data in the two or more snapshot virtual devices to addresses corresponding to the duplicate data in the deduplication virtual device. The storage system according to claim 1 .

4. The second mapping information further includes the following information: Information representing a mapping between addresses in the snapshot virtual device and addresses in the write-once virtual device; and information representing a mapping between addresses in the deduplication virtual device and addresses in the append virtual device; each of the plurality of write-once virtual devices is a virtual device serving as a logical address space corresponding to either a snapshot virtual device or a deduplication virtual device; Each added virtual device becomes a storage destination for data that is intended to be stored in a virtual device corresponding to the added virtual device, and does not become a storage destination for data that is intended to be stored in a virtual device that does not correspond to the added virtual device, The processor is configured to store data in a pool, the data being stored in a write-once virtual device; the pool is a logical address space based on at least one of at least a portion of the storage device and at least a portion of an external storage device of the storage system, when the storage target for the append virtual device is update data, the processor sets a storage destination for the update data to an empty address in the append virtual device, invalidates an address of the data before the update of the update data, and updates the second mapping information so that an address in the snapshot virtual device or the deduplication virtual device that was mapped to the address of the data before the update is mapped to a storage destination address of the update data in the append virtual device; The mapping between addresses in the write-once virtual device and addresses in the pool is 1:

1. The storage system according to claim 1 .

5. A storage system including a storage device and a processor, the storage device stores first mapping information and second mapping information; the first mapping information includes, for each of a plurality of snapshot families each made up of a PVOL (Primary Volume) and an SVOL (Secondary Volume) which is a snapshot of the PVOL, information indicating a mapping between an address of the PVOL or SVOL which is a VOL (Volume) in the snapshot family and an address in a snapshot virtual device; the second mapping information includes information representing a mapping between an address in a snapshot virtual device and an address in a deduplication virtual device; a write-once virtual device having an address mapped to an address in the snapshot virtual device or an address in the deduplication virtual device; the processor is a plurality of processor devices; each of the plurality of processor devices is configured to perform processing related to a VOL or a virtual device that is an owner processor device; the owner processor device of a snapshot family, the owner processor device of a snapshot virtual device for the snapshot family, and the owner processor device of a write-once virtual device corresponding to the snapshot virtual device are the same processor device; an owner processor device of the deduplication virtual device and an owner processor device of an append virtual device corresponding to the deduplication virtual device are the same processor device; Storage system.

6. There are a plurality of the snapshot families and snapshot virtual devices, and each of the plurality of processor devices serves as an owner processor device; a plurality of deduplication virtual devices, and a plurality of owner processor devices of the snapshot family and snapshot virtual devices become owner processor devices of the plurality of processor devices, respectively; The storage system according to claim 5 .

7. the storage device includes a cache unit in which data is temporarily stored; When processing a write request specifying any PVOL, if the following conditions (a) and (b) are satisfied, the processor writes to an append virtual device associated with a snapshot virtual device of a snapshot family that includes the PVOL, or writes to the deduplication virtual device: (a) a cache area corresponding to the address specified in the write request is in the cache unit, and the data in the cache area is dirty data that has not been reflected in the pool; (b) The generation of the dirty data is different from the latest generation of the PVOL. The storage system according to claim 1 .

8. the first mapping information includes first control information for each VOL in the plurality of snapshot families, and second control information associated with data in a snapshot virtual device for each of the plurality of snapshot families, The first control information for each VOL is associated with the generation of the VOL, and indicates which second control information is to be referenced for an address in the VOL, the second control information for each data item is associated with the oldest generation of the first control information that references the second control information, and indicates an address of the data item in the snapshot virtual device; the processor determines, for each snapshot family, whether or not the first control information and / or the second control information can be invalidated based on the generation of the first control information and the generation of the second control information, asynchronously with the processing of an I / O request for a VOL in the snapshot family, and invalidates the control information that is determined to be invalidable; The storage system according to claim 1 .

9. A storage control method for a storage system, comprising: storing the first mapping information and the second mapping information in a storage device of the storage system by a processor of the storage system; the first mapping information includes, for each of a plurality of snapshot families each made up of a PVOL (Primary Volume) and an SVOL (Secondary Volume) which is a snapshot of the PVOL, information indicating a mapping between an address of the PVOL or SVOL which is a VOL (Volume) in the snapshot family and an address in a snapshot virtual device; the second mapping information includes information representing a mapping between an address in a snapshot virtual device and an address in a deduplication virtual device; The processor of the storage system updating the first mapping information and the second mapping information, respectively; garbage-collecting an address in the snapshot virtual device that is no longer mapped to an address of the VOL in the snapshot family due to the update of the first mapping information; garbage-collecting addresses in the deduplication virtual device that are no longer mapped to addresses in the snapshot virtual device due to the update of the second mapping information; Storage control method.

10. A storage control method for a storage system, comprising: storing the first mapping information and the second mapping information in a storage device of the storage system by a processor of the storage system; the first mapping information includes, for each of a plurality of snapshot families each made up of a PVOL (Primary Volume) and an SVOL (Secondary Volume) which is a snapshot of the PVOL, information indicating a mapping between an address of the PVOL or SVOL which is a VOL (Volume) in the snapshot family and an address in a snapshot virtual device; the second mapping information includes information representing a mapping between an address in a snapshot virtual device and an address in a deduplication virtual device; Each of the plurality of processor devices constituting the processor of the storage processor performs processing related to the VOL or virtual device that is the owner processor device, the owner processor device of a snapshot family, the owner processor device of a snapshot virtual device for the snapshot family, and the owner processor device of a write-once virtual device corresponding to the snapshot virtual device are the same processor device; the write-once virtual device has an address that is mapped to an address in the snapshot virtual device or an address in the deduplication virtual device; an owner processor device of the deduplication virtual device and an owner processor device of an append virtual device corresponding to the deduplication virtual device are the same processor device; Storage control method.

Images