Storage system and data processing method

Abstract

The invention relates to a storage system and a data processing method, and aims to effectively utilize resources of virtual equipment to realize high throughput, the storage system is provided with a storage device and a processor; the processor manages a master volume and a snapshot volume as a snapshot family, uses a snapshot virtual device as a storage destination of data of the master volume and the snapshot volume, and when the processor receives a write request from a host, stores the data of the master volume and the snapshot volume. Switching between an overlay process and a new allocation process, the overlay process covering a region on the allocated snapshot virtual device, on the basis of a reference state from the snapshot volume to the address range of the write destination and a degree of distribution in the snapshot virtual device of the address range of the write destination; the new allocation process allocates a new region on the snapshot virtual device for the address range of the write destination.

Description

Technical Field

[0001] The invention relates to a storage system and a data processing method. Background Art

[0002] In recent years, the demand for data utilization has increased, and the opportunities for data replication have increased. As a result, the snapshot function has become increasingly important in storage systems. In the past, the representative means of implementing snapshots was the redirect on write (RoW) method. In the RoW method, since there is no copy of data and meta-information, there is an advantage that the impact on I / O performance when the snapshot is created is small. The RoW method is mostly used in AFA (AllFlash Array) devices. The RoW method is a method of appending data. Append writing is a data storage method in which, when writing data to the storage system, the data saved before writing is not overwritten, but the write object data is saved in a new area, and the meta-information is rewritten by referring to the data saved in the new area.

[0003] In the case of a data storage method based on appending writing, if the writing from the host computer is repeatedly processed, the free area tends to be fragmented. If the fragmentation progresses, the data of the required size cannot be allocated to the continuous area, and the performance of reading and writing will decrease over time. Fragmentation can be reduced by implementing garbage collection processing that moves the data configuration, but this processing has a particularly large impact on performance.

[0004] Patent document 1 proposes a method of reducing the number of references to duplicate data and improving the efficiency of garbage collection processing by allocating data shared by multiple VOLs to a virtual space different from the storage destination of individual data referenced only from one VOL using deduplication or snapshots.

[0005] Prior art literature

[0006] Patent Literature

[0007] Patent Document 1: U.S. Patent No. 10817209 Summary of the invention

[0008] Problems to be solved by the invention

[0009] However, when virtual device space is added as in Patent Document 1, the load on the storage controller increases due to the increase in mapping information referenced / updated during read / write IO processing, resulting in a problem of reduced throughput. In addition, by allocating virtual device space, the amount of metadata increases relative to the amount of data stored, which deteriorates the reduction effect, or the number of virtual device resources itself is insufficient, and there is also a problem that the number of VOLs that can be created is limited, but no solution to these problems is provided.

[0010] Therefore, in the present invention, an object is to effectively utilize the resources of the virtual devices to achieve high throughput.

[0011] Means used to solve problems

[0012] In order to achieve the above-mentioned object, a technical solution of a representative storage system of the present invention is characterized in that it comprises: a storage device; and a processor that accesses the above-mentioned storage device; the above-mentioned processor manages a primary volume (Primary volume) that is an object to be read and written by a host and a snapshot volume (Snapshot volume) generated based on the above-mentioned primary volume as a snapshot family; the above-mentioned processor uses a snapshot virtual device, which is a logical address space corresponding to the above-mentioned snapshot family, as a storage destination for data of the above-mentioned primary volume and the above-mentioned snapshot volume; when the above-mentioned processor receives a write request from the above-mentioned host, based on the reference status of the address range of the write destination from the above-mentioned snapshot volume and the distribution degree of the address range of the above-mentioned write destination in the above-mentioned snapshot virtual device, it switches to overwrite processing of overwriting an area on the above-mentioned snapshot virtual device that has been allocated and new allocation processing of allocating a new area on the above-mentioned snapshot virtual device to the address range of the above-mentioned write destination.

[0013] In addition, a technical solution of a representative data processing method of the present invention is a data processing method for a storage system having a storage device and a processor for accessing the above storage device, characterized in that the above processor manages a main volume that is an object to be read and written by a host and a snapshot volume generated based on the above main volume as a snapshot family; the above processor uses a logical address space corresponding to the above snapshot family, namely a snapshot virtual device, as a storage destination for data of the above main volume and the above snapshot volume; when the above processor receives a write request from the above host, based on a reference status of the address range of the write destination from the above snapshot volume and a distribution degree of the address range of the write destination in the above snapshot virtual device, switches between overwriting processing of overwriting an already allocated area on the above snapshot virtual device and new allocation processing of allocating a new area on the above snapshot virtual device to the address range of the write destination.

[0014] Effects of the Invention

[0015] According to the present invention, it is possible to effectively utilize the resources of the virtual device and realize high throughput. Other problems, configurations, and effects than those described above will become apparent from the following description of the embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a block diagram showing the hardware configuration of the storage system of the present invention.

[0017] Figure 2 This is a schematic diagram of storage control of the storage system of the present invention.

[0018] Figure 3 This is a schematic diagram of the management of the mapping between the SS-Family address and the SS-VDEV address.

[0019] Figure 4 This is a schematic diagram of the management of mapping between the address of SS-VDEV and the address of Dedup-VDEV, the management of mapping between the address of SS-VDEV and the address of CR-VDEV, and the management of mapping between the address of Dedup-VDEV and the address of CR-VDEV.

[0020] Figure 5 It is an explanatory diagram showing the structure of the memory included in the storage controller of the present invention.

[0021] Figure 6 It is an explanatory diagram showing the structure of a control information area in the memory of the storage controller of the present invention.

[0022] Figure 7 It is an explanatory diagram showing the structure of a program area in the memory of the storage controller of the present invention.

[0023] Figure 8 This is a diagram showing the structure of the ownership management table.

[0024] Fig. 9 This is a diagram showing the structure of the CR-VDEV management table.

[0025] Fig.10 This is a diagram showing the structure of the snapshot management table.

[0026] Fig.11 This is a diagram showing the structure of the VOL-Dir management table.

[0027] Fig.12 This is a diagram showing the composition of the representatives of the Latest Age.

[0028] Fig.13 This is a diagram showing the structure of the collection management table.

[0029] Fig.14This is a diagram showing the structure of the generation management tree table.

[0030] Fig.15 This is a diagram showing the structure of the snapshot allocation management table.

[0031] Fig.16 This is a diagram showing the structure of the Dir management table.

[0032] Fig.17 This is a diagram showing the structure of the SS-Mapping management table.

[0033] Fig.18 This is a diagram showing the structure of the compression allocation management table.

[0034] Fig.19 This is a diagram showing the structure of the CR-Mapping management table.

[0035] Fig. 20 This is a diagram showing the structure of the Dedup-Dir management table.

[0036] Fig.21 This is a diagram showing the structure of the Dedup allocation management table.

[0037] Fig. 22 This is a diagram showing the structure of the Pool-Mapping management table.

[0038] Fig.23 This is a diagram showing the structure of the pool allocation management table.

[0039] Fig.24 This is a diagram showing the flow of snapshot acquisition processing.

[0040] Fig.25 This is a diagram showing the flow of snapshot restoration processing.

[0041] Fig.26 This is a diagram showing the flow of snapshot deletion processing.

[0042] Fig. 27 This is a diagram showing the flow of asynchronous recovery processing.

[0043] Fig.28 This is a diagram showing the flow of the write process (front end).

[0044] Fig.29 This is a diagram showing the flow of the write process (back end).

[0045] Fig.30 This is a diagram showing the flow of snapshot allocation determination processing.

[0046] Fig.31 This is a diagram showing the flow of snapshot addition processing.

[0047] Fig.32 This is a diagram showing the flow of the Dedup addition process.

[0048] Fig.33 This is a diagram showing the flow of compression and addition processing.

[0049] Fig.34 This is a diagram showing the flow of the dump (destage) process.

[0050] Fig.35 This is a diagram showing the flow of the read process.

[0051] Description of Figure Numbers

[0052] 9: snapshot family; 10P: primary volume; 10S: snapshot volume; 11C: compression append virtual device; 11D: duplicate exclusion virtual device, 11S: snapshot virtual device; 13: pool; 70: Dir-Info generation management tree; 100: computer system; 201: storage system; 202: server system; 203: management system; 204: storage network; 205: management network; 210: storage controller; 211: CPU; 212: memory; 213: back-end interface; 214: front-end interface; 215: management interface; 901: control information unit; 902: program unit; 903: cache unit. DETAILED DESCRIPTION

[0053] Hereinafter, embodiments will be described using the drawings.

[0054] [Example 1]

[0055] Figure 1 Represents the hardware composition of a computer system.

[0056] The computer system 100 includes 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. In addition, the storage network 204 and the management network 205 may be the same communication network.

[0057] The storage system 201 includes a plurality of storage controllers 210 and a plurality of SSDs (solid state drives) 220. The plurality of SSDs 220 are connected to the storage controller 210. The plurality of SSDs 220 are an example of a permanent storage device. A pool 13 is formed based on the plurality of SSDs 220. Data stored in a page 14 of the pool 13 is stored in one or more SSDs 220.

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

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

[0060] 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 combined to form a duplicate memory.

[0061] The backend interface 213 , the frontend interface 214 , and the management interface 215 are examples of interface devices.

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

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

[0064] 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 interface 215 is connected to the management system 203 via the management network 205.

[0065] The server system 202 is configured to include one or more host devices. The server system 202 sends an I / O request (write request or read request) that specifies 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 an LBA (Logical Block Address), or the like.

[0066] The management system 203 is configured to include one or more management devices. The management system 203 manages the storage system 201 .

[0067] Figure 2 Indicates the overview of storage control in the storage system. Figure 2In the data represented by uppercase Latin letters (data A, B, C, ...) are block data, and data represented by lowercase Latin letters (data a, b, c, ...) are sub-block data. Block data can be data in block units. A block can be a logical storage area (logical address range) of fixed length. Sub-block data is compressed data of block data, and a sub-block group (one or more sub-blocks) is data of a storage destination. A sub-block can be a logical storage area of ​​a size smaller than a block. For example, a block can be an integer multiple of a sub-block.

[0068] The storage system having storage devices and processors has SS-Family (snapshot family) 9 , SS-VDEV (snapshot virtual device) 11S, Dedup-VDEV (duplicate elimination virtual device) 11D, CR-VDEV (compression addition virtual device) 11C, and pool 13 .

[0069] SS-Family9 is a VOL (volume) group including PVOL10P and SVOL10S which is a snapshot of PVOL10P.

[0070] SS-VDEV11S is a virtual device as a logical address space, and a certain VOL10 in SS-Family9 is set as a storage destination of data to be stored.

[0071] The dedup-VDEV 11D is a virtual device in a logical address space different from that of the SS-VDEV 11S, and is used as a storage destination for duplicate data of two or more SS-VDEVs 11S.

[0072] CR-VDEV11C is a virtual device in a logical address space different from SS-VDEV11S and Dedup-VDEV11D, and is used as a storage destination for compressed data.

[0073] Each of the plurality of CR-VDEV11Cs is associated with one of the SS-VDEV11S and the Dedup-VDEV11D, but is not associated with the VDEV11S and 11D of both. That is, for each CR-VDEV11C, the VDEV (virtual device) associated with the CR-VDEV11C is the storage destination of the data to be stored, and the VDEV not associated with the CR-VDEV11C is not the storage destination of the data to be stored. The pool 13 is the storage destination of the compressed data to be stored in the CR-VDEV11C.

[0074] The pool 13 is a logical address space based on at least a part of a storage device (e.g., a permanent storage device) possessed by the storage system. The pool 13 may be based on at least a part of an external storage device (e.g., a permanent storage device) of the storage system instead of or in addition to at least a part of the storage device possessed by the storage system. The pool 13 has a plurality of pages 14 as a plurality of logical areas. The compressed data to which the CR-VDEV11C is a storage destination is stored in the pages 14 of the pool 13. The mapping between the address of the CR-VDEV11C and the address of the pool 13 is 1:1. The pool 13 is composed of one or more pool VOLs.

[0075] according to Figure 2 In the example shown, the following storage control is performed.

[0076] The processor creates SVOL10S0 as a snapshot of PVOL10P0, thereby forming SS-Family9-0 with PVOL10P0 as the root VOL. In addition, the processor creates SVOL10S1 as a snapshot of PVOL10P1, thereby forming SS-Family9-1 with PVOL10P1 as the root VOL. Figure 2 , as examples of multiple SS-Families, there are SS-Family 9-0 and 9-1.

[0077] The storage system has one or more SS-VDEV11S for each of the plurality of SS-Families 9. For each SS-Family 9, for data to be stored in a certain VOL10 in the SS-Family 9, the SS-VDEV11S corresponding to the SS-Family 9 among the plurality of SS-VDEV11S is set as the storage destination. Taking SS-Family 9-0 as an example, the specific details are as follows.

[0078] The processor sets SS-VDEV11S0 as the storage destination for data A whose storage destination is SVOL10S0 of SS-Family9-0. The processor maps the address corresponding to data A in SVOL10S0 to the address corresponding to data A in SS-VDEV11S0 corresponding to SS-Family9-0.

[0079] When the same data B exists in multiple VOLs (PVOL10P0 and SVOL10S0) of SS-Family9-0, the processor maps multiple addresses of the same data B in the multiple VOLs 10 (the address of PVOL10P0 and the address of SVOL10S0) to the address of SS-VDEV11S0 of SS-Family9-0 (the address corresponding to data B).

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

[0081] That is, since data C is duplicated in SS-VDEV11S0 and 11S (an example of two or more SS-VDEV11S) of SS-Family 9-0 and 9-1, the processor maps two addresses of duplicate data C in SS-VDEV11S0 and 11S1 to addresses corresponding to duplicate data C in Dedup-VDEV11D. Next, the processor compresses duplicate data C and sets the storage destination of compressed data c to CR-VDEV11CC corresponding to Dedup-VDEV11D. 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. In addition, the processor allocates page 14B to CR-VDEV11CC and stores compressed data c in page 14B. The address of compressed data c in CR-VDEV11CC is mapped to the address of page 14B of pool 13.

[0082] On the other hand, regarding SS-VDEV11S0, since data A does not overlap with data in other SS-VDEV11S1, the processor compresses the non-duplicate data A and sets the compressed data a to 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. In addition, the processor 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 the address of page 14A of pool 13.

[0083] CR-VDEV11C is an additional VDEV. Therefore, the processor updates the address mapping when CR-VDEV11C corresponding to SS-VDEV11S is set as the storage destination of the updated data, and when CR-VDEV11C corresponding to Dedup-VDEV11D is set as the storage destination of the updated data. Specifically, the processor performs the following storage control, for example.

[0084] When the storage object for CR-VDEV11C0 is update data a′ of compressed data a, the processor sets the storage destination of update data a′ to a free address in CR-VDEV11C0 and sets the address of compressed data a before update to invalid. The processor maps the address of compressed data a and the address of SS-VDEV11S0 mapped to the storage destination address of update data a′ in CR-VDEV11C0 instead of the address of compressed data a in CR-VDEV11C0. In addition, the processor maps the address of compressed data a and the address of page 14A mapped to the storage destination address of update data a′ in CR-VDEV11C0 instead of the address of compressed data a in CR-VDEV11C0.

[0085] When the storage object for CR-VDEV11CC is update data c′ of compressed data c, the processor sets the storage destination of update data c′ to a free address in CR-VDEV11CC and sets the address of compressed data c before update to invalid. The processor maps the address of compressed data c and Dedup-VDEV11D to the storage destination address of update data c′ in CR-VDEV11CC instead of the address of compressed data c in CR-VDEV11CC. In addition, the processor maps the address of compressed data c and page 14B to the storage destination address of update data c′ in CR-VDEV11CC instead of the address of compressed data a in CR-VDEV11CC.

[0086] CR-VDEV11C is an append-type VDEV as described above, and performs garbage collection. That is, the processor makes valid addresses (addresses of the latest data) continuous and can make addresses of free areas continuous by performing garbage collection on CR-VDEV11C.

[0087] according to Figure 2In the example shown, two or more Dedup-VDEV11Ds as storage destinations for duplicate data in SS-Family9 are prepared separately from SS-VDEV11S as the storage destination of data in SS-Family9. Therefore, even if the address of duplicate data C in Dedup-VDEV11D is changed, it is sufficient that the address mapping of the changed object is two mappings (the mappings for each of the two addresses in SS-VDEV11S0 and 11S1). On the other hand, in a 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. In this case, the address mapping of the changed object for duplicate data C is four mappings (the mappings for each of the four addresses in VOL10P0, 10S0, 10P1, and 10S1). In this embodiment, it is expected that the address mapping will be changed in a shorter time than in a comparative example.

[0088] Unlike Dedup-VDEV11D, CR-VDEV11CC is prepared for Dedup-VDEV11D. Therefore, even if the address of the compressed data c in CR-VDEV11CC is changed, it is sufficient to have one mapping (a mapping for one address in Dedup-VDEV11D) for the address mapping of the changed object. On the other hand, in a comparative example, the storage destination of the compressed data of the data in SS-Family9 and the storage destination of the compressed data of the duplicate data in two or more SS-Families9 are the same VDEV. In this case, the address mapping of the changed object for the compressed data c of the duplicate data C is four mappings (respective mappings for four addresses in VOL10P0, 10S0, 10P1, and 10S1). In the present embodiment, it is expected that the address mapping is changed in a shorter time than in a comparative example.

[0089] The change of the address of the compressed data c is performed in the garbage collection of CR-VDEV11CC corresponding to Dedup-VDEV11D. For example, in the garbage collection of CR-VDEV11CC, the processor changes the address of the updated data c′ (the updated data of the compressed data c) in CR-VDEV11CC, and it is mapped to the address before the change, and the address of Dedup-VDEV11D is mapped to the changed address in CR-VDEV11CC. Since it is expected that the address mapping of the compressed data for the repeated data is changed in a short time, it is expected that the garbage collection can be performed in a short time. In addition, the garbage collection of CR-VDEV11C corresponding to SS-VDEV11S includes, for example, the following processing. That is, the processor changes the address of the updated data a′ (the updated data of the compressed data a) in CR-VDEV11C0, and it is mapped to the address before the change, and the address of SS-VDEV11S0 is mapped to the changed address in CR-VDEV11C0.

[0090] For at least one CR-VDEV11C, an additional VDEV storing non-compressed data may be used instead of CR-VDEV11C, but in this embodiment, CR-VDEV11C is used as the additional VDEV. Therefore, the data finally stored in the storage device is compressed data, so the consumed storage capacity can be reduced.

[0091] Figure 3 This shows an overview of the management of the mapping between the address of SS-Family9 and the address of SS-VDEV11S. In addition, in the figure, "GX" (X is an integer greater than 0) refers to generation X. In addition, Figure 3 Take SS-Family9-0 and SS-VDEV11S0 as examples.

[0092] The processor can manage the mapping between the address of VOL10 in SS-Family9-0 and the address of SS-VDEV11S0 using meta-information. The meta-information includes Dir-Info (directory information) and SS-Mapping-Info (snapshot mapping information). The processor establishes a correspondence between Dir-Info and SS-Mapping-Info to manage the data of PVOL10P0 and SVOL10S0. For data that is set as the storage destination of VOL10, Dir-Info has information indicating the address of the reference source (the address of VOL10), and SS-Mapping-Info corresponding to the data has information indicating the address of the reference destination (the address of SS-VDEV11S0).

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

[0094] It is assumed that before the snapshot is acquired, there are data A0, B0, and C0 whose storage destination is PVOL10P0. Also, it is assumed that the latest generation is "0".

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

[0096] SS-VDEV11S0 is set as the storage destination of data A0, B0, and C0, and SS-Mapping-Info is associated with each of data A0, B0, and C0. In addition, each SS-Mapping-Info is associated with "0" as a generation #. When the generation # associated with the SS-Mapping-Info indicates "X", it can be expressed that the data corresponding to the SS-Mapping-Info is data of generation X.

[0097] In the state before the snapshot is taken, for each of the data A0, B0, and C0, the information in Dir-Info refers to the SS-Mapping-Info corresponding to the data. By establishing correspondence between Dir-Info and SS-Mapping-Info in this way, PVOL10P0 and SS-VDEV11S0 can be corresponded, and data processing for PVOL10P0 can be realized.

[0098] To obtain a snapshot, the processor sets the copy of Dir-Info to the Dir-Info of SVOL10S0, which is set to read-only. Next, 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.

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

[0100] Here, in the case of obtaining a snapshot, writing is prohibited at the time of acquisition, and the snapshot (SVOL10S0) with fixed data becomes generation 0, and PVOL10P0 to which data can be written even after acquisition becomes generation 1. Generation 0 is "a generation that is one generation earlier in the direct line" relative to generation 1, and is referred to as the "father" for convenience. Similarly, generation 1 is "a generation that is one generation newer in the direct line" relative to generation 0, and is referred to as the "child" for convenience. The storage system manages the parent-child relationship of generations as a Dir-Info generation management tree 70. In addition, the generation # of a Dir-Info is the same as the generation # of VOL10 corresponding to the Dir-Info. In addition, the generation # of an SS-Mapping-Info is the earliest generation # among the generation #s of one or more Dir-Infos that reference the SS-Mapping-Info.

[0101] Figure 4 The following diagram summarizes the management of mapping between the address of the SS-VDEV11S and the address of the Dedup-VDEV11D, the management of mapping between the address of the SS-VDEV11S and the address of the CR-VDEV11C, and the management of mapping between the address of the Dedup-VDEV11D and the address of the CR-VDEV11C. Figure 4 Take SS-VDEV11S0, CR-VDEV11C0 and 11CC as examples.

[0102] The processor uses meta-information to manage the mapping between the address of SS-VDEV11S0 and the address of Dedup-VDEV11D, the mapping between the address of SS-VDEV11S0 and the address of CR-VDEV11C0, and the mapping between the address of Dedup-VDEV11D and the address of CR-VDEV11CC. As described above, the meta-information includes Dir-Info (directory information) and CR-Mapping-Info (compression mapping information). The processor manages the data of SS-VDEV11S0 and Dedup-VDEV11D by establishing a correspondence between Dir-Info and CR-Mapping-Info. For data set as a storage destination of SS-VDEV11S0, Dir-Info has information indicating the address of the reference source (the address of SS-VDEV11S0), and CR-Mapping-Info corresponding to the data has information indicating the address of the reference destination (the address of CR-VDEV11C0 or the address of Dedup-VDEV11D). For data for which Dedup-VDEV11D is set as the storage destination, Dir-Info has information indicating the address of the reference source (the address of Dedup-VDEV11D), and CR-Mapping-Info corresponding to the data has information indicating the address of the reference destination (the address of CR-VDEV11CC). The processor refers to the compression allocation information, and can determine the address of SS-VDEV11S or Dedup-VDEV11D based on the address of CR-VDEV11C.

[0103] Although omitted in the figure, in order to move valid data on CR-VDEV to ensure continuous free areas, the storage system 201 maintains the compression allocation management table 1011 in the memory 212 as information mapping in the reverse direction from the address of CR-VDEV to the address of SS-VDEV or Dedup-VDEV.

[0104] Figure 5 The structure of the memory 212 is shown.

[0105] The memory 212 includes a control information unit 901 for storing control information (may also be referred to as management information), a program unit 902 for storing programs, and a cache unit 903 for temporarily storing data.

[0106] Figure 6 Indicates the information stored in the control information unit 901.

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

[0108] Figure 7 Indicates the program stored in the program unit 902.

[0109] The program unit 902 stores a snapshot acquisition program 1101, a snapshot recovery program 1102, a snapshot deletion program 1103, an asynchronous recovery program 1104, a read / write program 1105, a snapshot appending program 1106, a dedup appending program 1107, a compression appending program 1108, a dump (destage) program 1109, a GC (garbage collection) program 1110, a CPU determination program 1111, an ownership transfer program 1112, and a snapshot allocation determination program 1113.

[0110] Figure 8 The structure of the ownership management table 1001 is shown.

[0111] The ownership management table 1001 manages the ownership of the VOL 10 or the 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 VOL# / VDEV#1201 and owner CPU#1202.

[0112] VOL# / VDEV#1 201 indicates the identification number of VOL10 or VDEV11. Owner CPU#1 202 indicates the identification number of the CPU that is the owner CPU of VOL10 or VDEV11 (the CPU that has ownership of VOL10 or VDEV11).

[0113] In addition, instead of allocating the owner CPU in units of the CPU 211 , the owner CPU may be allocated in units of a CPU group or in units of a storage controller 210 .

[0114] Fig. 9 The structure of the CR-VDEV management table 1002 is shown.

[0115] The CR-VDEV management table 1002 indicates the CR-VDEV 11C associated with the SS-VDEV 11S or the 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.

[0116] VDEV#1301 indicates the identification number of SS-VDEV11S or Dedup-VDEV11D. CR-VDEV#1302 indicates the identification number of CR-VDEV11C.

[0117] Fig.10 The structure of the snapshot management table 1003 is shown.

[0118] A snapshot management table 1003 exists for each PVOL 10P (for each SS-Family 9). The snapshot management table 1003 indicates the acquisition time of each snapshot (SVOL 10S). For example, the snapshot management table 1003 has an entry for each SVOL 10S. The entry has information such as PVOL#1401, SVOL#1402, and acquisition time 1403.

[0119] PVOL# 1401 indicates the identification number of PVOL 10P. SVOL# 1402 indicates the identification number of SVOL 10S. Acquisition time 1403 indicates the acquisition time of SVOL 10S.

[0120] Fig.11 The structure of the VOL-Dir management table 1004 is shown.

[0121] The VOL-Dir management table 1004 shows the correspondence between VOL 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.

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

[0123] Fig.12Indicates the composition of the latest generation representative 1005.

[0124] For each PVOL10P (for each SS-Family9), there is a latest generation table 1005, which indicates the generation (generation #) of the PVOL10P.

[0125] Fig.13 The structure of the collection management table 1006 is shown.

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

[0127] Dir-Info#1701 indicates the identification number of Dir-Info. Collection request 1702 indicates whether collection of Dir-Info is requested. "1" indicates collection is requested, and "0" indicates no collection is requested.

[0128] Fig.14 The structure of the generation management tree table 1007 is shown.

[0129] A generation management tree table 1007 exists for each PVOL 10P (for 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, Prev1803, and Next1804.

[0130] Dir-Info#1801 indicates the identification number of Dir-Info. Generation#1802 indicates the generation of VOL10 corresponding to Dir-Info. Prev1803 indicates the parent (1 upper) Dir-Info of Dir-Info. Next1804 indicates the child (1 lower) Dir-Info of Dir-Info. The number of Next1804 can be the same as the number of child Dir-Info. Fig.14 Since there are two sub-Dir-Infos, there are two Next1804s (Next-A1804A and Next-B1804B).

[0131] Fig.15 The structure of the snapshot allocation management table 1008 is shown.

[0132] The snapshot allocation management table 1008 exists for each SS-VDEV11S and indicates the mapping from the address of the SS-VDEV11S to the address of the VOL10. The snapshot allocation management table 1008 has an entry for each address of the SS-VDEV11S. The entry has information such as the block address 1901, the state 1902, the allocation destination VOL#1903, and the allocation destination address 1904.

[0133] Block address 1901 indicates the address of a block in SS-VDEV11S. Status 1902 indicates whether the block is allocated to an address of a certain VOL ("1" means allocated, "0" means free). Allocation destination VOL#1903 indicates the identification number of VOL10 (PVOL10P or SVOL10S) having the address of the allocation destination of the block ("n / a" means unallocated). Allocation destination address 1904 indicates the address (block address) of the allocation destination of the block ("n / a" means unallocated).

[0134] Fig.16 The structure of the Dir management table 1009 is shown.

[0135] The Dir management table 1009 exists for each Dir-Info, and the Dir management table 1009 indicates the Mapping-Info (mapping information) 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 the VOL / VDEV address 2001 and the reference destination Mapping-Info#2002.

[0136] The VOL / VDEV address 2001 indicates the address (block address) of VOL10 (PVOL10P or SVOL10S) or the address of VDEV11 (SS-VDEV11S or Dedup-VDEV11D). The reference destination Mapping-Info #2002 indicates the identification number of the reference destination Mapping-Info.

[0137] Fig.17 The structure of the SS-Mapping management table 1010 is shown.

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

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

[0140] Fig.18 The structure of the compression allocation management table 1011 is shown.

[0141] The compression allocation management table 1011 exists for each CR-VDEV11C and has compression allocation information for each sub-block in the CR-VDEV11C. The compression allocation management table 1011 has an entry corresponding to the compression allocation information for each sub-block of the CR-VDEV11C. The entry has information such as a sub-block address 2201, a data length 2202, a status 2203, a start sub-block address 2204, an allocation destination VDEV#2205, and an allocation destination address 2206.

[0142] Subblock address 2201 indicates the address of a subblock. Data length 2202 indicates the number of subblocks constituting a subblock group (one or more subblocks) storing compressed data (for example, "2" means that compressed data exists in two subblocks). Status 2203 indicates the status of the subblock ("0" means free, "1" means allocated, and "2" means the object of GC (garbage collection)). The starting subblock address 2204 indicates the address of the starting subblock of one or more subblocks (one or more subblocks storing compressed data) including the subblock. Allocation destination VDEV#2205 indicates the identification number of VDEV11 (SS-VDEV11S or Dedup-VDEV11D) of the block having the allocation destination of the subblock. Allocation destination address 2206 indicates the address of the block of the allocation destination of the subblock (block address in SS-VDEV11S or Dedup-VDEV11D).

[0143] Fig.19 The structure of the CR-Mapping management table 1012 is shown.

[0144] The CR-Mapping management table 1012 exists for each Dir-Info of the Dedup-VDEV11D and each Dir-Info of the SS-VDEV11S. The CR-Mapping management table 1012 has an entry for each CR-Mapping-Info corresponding to the Dir-Info of the Dedup-VDEV11D and each CR-Mapping-Info corresponding to the Dir-Info of the SS-VDEV11S. The entry has information such as Mapping-Info#2301, reference destination address 2302, reference destination CR-VDEV#2303, and data length 2304.

[0145] Mapping-Info#2301 indicates the identification number of CR-Mapping-Info. Reference destination address 2302 indicates the address referenced by CR-Mapping-Info (the address of the first subblock in the subblock group). Reference destination CR-VDEV#2303 indicates the identification number of CR-VDEV11C having the subblock address referenced by CR-Mapping-Info. Data length 2304 indicates the number of blocks referenced by CR-Mapping-Info (blocks in Dedup-VDEV11D) or the number of subblocks constituting the subblock group referenced by CR-Mapping-Info.

[0146] Fig. 20 The structure of the Dedup-Dir management table 1013 is shown.

[0147] 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 of the Dedup-VDEV 11D. The entry has information such as the Dedup-VDEV address 2401 and the reference destination allocation information #2402.

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

[0149] Fig.21 The structure of the Dedup allocation management table 1014 is shown.

[0150] The Dedup allocation management table 1014 exists for each Dedup-VDEV11D (for each Dedup-Dir-Info), and indicates a reverse reference mapping from the Dedup allocation information corresponding to the address of the Dedup-VDEV11D to the address of the SS-VDEV11S. 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 connection allocation information #2504.

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

[0152] according to Fig.21 , Dedup allocation information #“3” is linked to Dedup allocation information #“1”, and there is no Dedup allocation information linked to Dedup allocation information #“3”. Therefore, it can be known that the duplicate data at the Dedup-VDEV address corresponding to Dedup allocation information #“1” is duplicate data in SS-VDEV11S referenced by Dedup allocation information #“1” and SS-VDEV11S referenced by Dedup allocation information #“3”. Since the number of duplicate data is indefinite, Dedup allocation information is linked according to the number of duplicate data. When duplicate data exists in N SS-VDEV11S, N sequential Dedup allocation information are prepared.

[0153] Fig. 22 The structure of the Pool-Mapping management table 1015 is shown.

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

[0155] The VDEV address 2601 indicates the start address of an area (e.g., a plurality of blocks) in page size units. The page # 2602 indicates the identification number of the allocated page 14 (e.g., the address of the pool 13 of the page 14). In addition, when there are a plurality of pools 13, the page # 2602 may also include the identification number of the pool 13 having the page 14.

[0156] Fig.23 The structure of the Pool allocation management table 1016 is shown.

[0157] For example, when there are a plurality of pools 13, a Pool allocation management table 1016 exists for each pool 13. The Pool allocation management table 1016 indicates the correspondence between the page 14 and the area in the CR-VDEV 11C. The Pool allocation management table 1016 has an entry for each page. The entry has information such as page #2701, RG #2702, start address 2703, status 2704, allocation destination VDEV #2705, and allocation destination address 2706.

[0158] Page #2701 indicates the identification number of page 14. RG #2702 indicates the identification number of the RAID group (in this embodiment, a RAID group composed of more than two SSD220) that is the basis of page 14. Starting address 2703 indicates the starting address of page 14. Status 2704 indicates the status of page 14 ("1" means allocated, "0" means free). Allocation destination VDEV #2705 indicates the identification number of CR-VDEV11C to which page 14 is allocated ("n / a" means unallocated). Allocation destination address 2706 indicates the allocation destination address of page 14 (the address of CR-VDEV11C) ("n / a" means unallocated).

[0159] Fig.24 2 shows the flow of the snapshot acquisition process. The snapshot acquisition process 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.

[0160] First, the snapshot acquisition program 1101 allocates the Dir management table 1009 as the copy destination, and updates the VOL-Dir management table 1004 (S2401).

[0161] The snapshot acquisition program 1101 increments the latest generation # (S2402) and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2403). At this time, the snapshot acquisition program 1101 sets the latest generation # for the copy source and the previous generation # for the copy destination.

[0162] The snapshot acquisition program 1101 determines whether there is cache dirty data for the target PVOL10P ( S2404 ). “Cache dirty data” may be data stored in the cache unit 903 that has not been written to the pool 13 .

[0163] When the result of determination in S2404 is true ( S2404 : Yes), the snapshot acquisition program 1101 causes the snapshot adding program 1106 to execute the snapshot adding process ( S2405 ).

[0164] When the determination result of S2404 is false (S2404: No), or after S2405, the snapshot acquisition program 1101 copies the Dir management table 1009 of the target PVOL10P to the Dir management table 1009 of the copy destination (S2406).

[0165] Then, the snapshot acquisition program 1101 updates the snapshot management table 1003 (S2407) and ends the process. In S2407, an entry 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 is added.

[0166] Fig.25 The snapshot restore process is shown in FIG. 11. The snapshot restore process is executed by the snapshot restore program 1102 according 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.

[0167] First, the snapshot restoration program 1102 allocates the Dir management table 1009 as the restoration destination and updates the VOL-Dir management table 1004 (S2501).

[0168] The snapshot recovery program 1102 increments the latest generation # (S2502) and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2503). At this time, the snapshot recovery program 1102 sets the generation # before incrementing for the copy source and the latest generation # for the copy destination.

[0169] The snapshot restoration program 1102 clears the cache area (the area in the cache unit 903) of the restoration destination PVOL (S2504).

[0170] The snapshot restoration program 1102 copies the Dir management table 1009 of the restoration source SVOL to the Dir management table 1009 of the restoration destination PVOL (S2505).

[0171] Then, the snapshot restoration program 1102 registers the Dir-Info# of the old Dir-Info of the restoration destination in the recycling management table 1006 (S2506), and ends the process. In S2506, the recycling request 1702 corresponding to the Dir-Info# is set to "1".

[0172] Fig.26 The snapshot deletion process is shown in FIG. 11. The snapshot deletion process is executed by the snapshot deletion program 1103 according to a snapshot deletion instruction from the management system 203 (or another system such as the server system 202). In the restoration instruction, for example, the target SVOL is specified.

[0173] First, the snapshot deletion program 1103 refers to the VOL-Dir management table 1004 and invalidates the Dir-Info (Dir-Info#1503) of the target SVOL (S2601).

[0174] Next, the snapshot deletion program 1103 updates the snapshot management table 1003 (S2602), registers the old Dir-Info# of the target SVOL in the reclaim management table 1006 (S2603), and terminates the process. In S2603, the reclaim request 1702 corresponding to the Dir-Info# is set to "1".

[0175] Fig. 27 2 shows the flow of the asynchronous collection process. The asynchronous collection process is executed by the asynchronous collection program 1104, for example, periodically.

[0176] First, the asynchronous recycling program 1104 determines the recycling target Dir-Info# from the recycling management table 1006 (S2701). The "recycling target Dir-Info#" is the Dir-Info# for which the recycling request 1702 is "1". The asynchronous recycling program 1104 refers to the generation management tree table 1007, confirms the entry of the recycling target Dir-Info#, and does not select a Dir-Info with more than two children.

[0177] Then, the asynchronous collection program 1104 determines whether there is an unprocessed entry (S2702). The "unprocessed entry" here refers to an entry in the collection management table 1006 where the collection request 1702 is "1" and the asynchronous collection process is not yet processed.

[0178] When the judgment result of S2702 is true (S2702: Yes), the asynchronous recovery program 1104 determines the processing object entry (including the entry with the recovery request 1702 as "1") from one or more unprocessed entries (S2703), and determines the reference destination Mapping-Info#2002 from the Dir management table 1009 corresponding to the object Dir-Info (Dir-Info identified based on Dir-Info#1701 in the processing object entry) (S2704).

[0179] The asynchronous collection program 1104 refers to the generation management tree table 1007 to determine whether there is Dir-Info of a child generation of the target Dir-Info ( S2705 ).

[0180] If the result of S2705 is true (S2705: Yes), the asynchronous recovery program 1104 determines the reference destination Mapping-Info#2002 from the Dir management table 1009 corresponding to the Dir-Info of the child generation, and determines whether the reference destination Mapping-Info#2002 of the object Dir-Info is consistent with the reference destination Mapping-Info#2002 of the Dir-Info of the child generation (S2706). If the result of S2706 is true (S2706: Yes), the process returns to S2702.

[0181] If the result of S2706 is false (S2706: No), or if the result of S2705 is false (S2705: No), the asynchronous recovery program 1104 determines whether the generation # of the Dir-Info of the parent generation of the object Dir-Info is greater than the generation #2104 (referenced to the generation #2105) of the reference destination Mapping-Info of the object Dir-Info. Fig.21 ) is too early (S2707). When the determination result of S2707 is false (S2707: No), the process returns to S2702.

[0182] If the result of S2707 is true (S2707: Yes), the asynchronous reclaim program 1104 initializes the object entry of the SS-Mapping management table 1010 and releases the object entry of the snapshot allocation management table 1008 (S2708). Then, the process returns to S2702. The release in S2708 is equivalent to the release of the block in the SS-VDEV.

[0183] If the result of the determination in S2702 is false (S2702: No), the asynchronous collection program 1104 updates the collection management table 1006 (S2709), and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2710), and ends the processing.

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

[0185] First, the read / write program 1105 determines whether the target data of the write request is cache hit (Cache hit) (S2801). "Cache hit" means whether the cache area corresponding to the write destination VOL address of the target data (the VOL address specified in the write request) has been secured. In the case where the determination result of S2801 is false (S2801: No), the read / write program 1105 secures the cache area corresponding to the write destination VOL address of the target data from the cache unit 903 (S2802). Then, the process proceeds to S2806.

[0186] If the result of the determination in S2801 is true (S2801: Yes), the read / write program 1105 determines whether the cache hit data (data in the secured cache area) is dirty data (data not reflected (not written) in the pool 13) (S2802). If the result of the determination in S2803 is false (S2803: No), the process proceeds to S2806.

[0187] If the result of the determination in S2803 is true (S2803: Yes), the read / write program 1105 determines whether the WR (Write) generation # of the dirty data is consistent with the generation # of the target data of the write request (S2804). "WR generation #" is stored in the management information of the cache data (not shown), for example. In addition, the generation # of the target data of the write request is obtained from the latest generation #403. S2804 is a process for preventing the dirty data from being updated by the target data of the write request and the data of the snapshot from being corrupted during the period when the appending process of the target data (dirty data) of the snapshot obtained immediately before is not performed.

[0188] When the determination result of S2804 is false ( S2804 : No), the read / write program 1105 causes the snapshot adding program 1106 to execute the snapshot adding process ( S2805 ).

[0189] After S2802 or when the result of the determination in S2804 is true (S2804: Yes), the read / write program 1105 writes the target data of the write request to the cache area secured in S2802 or the cache area obtained via S2805 (S2806). Then, the read / write program 1105 sets the WR generation # of the data written in S2806 to the latest generation # compared in S2804 (S2807), and returns a normal response (Good response) to the server system 202 (S2808).

[0190] Fig.29 The flow of the write process (back end) is shown. The write process (back end) is a process of writing the unreflected data (dirty data) to the pool 13 when the unreflected data is on the cache unit 903. The write process (back end) is performed synchronously or asynchronously with the write process (front end). The write process (back end) is executed by the read / write program 1105.

[0191] The read / write program 1105 determines whether there is dirty data in the cache unit 903 (S2901). If the determination result of S2901 is true (S2901: Yes), the read / write program 1105 causes the snapshot adding program 1106 to execute snapshot allocation determination processing (S2902).

[0192] Fig.30 The flow of the snapshot allocation determination process is shown. In the snapshot allocation determination process, it is determined whether the area of ​​the PVOL10P to which the write request from the host is to be newly allocated is an area on the SS-VDEV11S, or the area already allocated is overwritten. The snapshot allocation determination process is executed by the snapshot allocation determination program 1113 called from the read / write program 1105.

[0193] First, the snapshot allocation determination program 1113 determines whether the generation # of the Dir-Info of the target VOL (the data writing destination VOL) ​​is consistent with the generation # of the SS-Mapping-Info before the addition (S3001). If the determination result of S3001 is false (S3001: No), the snapshot allocation determination program 1113 executes the snapshot addition process (S3009).

[0194] If the result of S3001 is true (S3001: Yes), the process proceeds to S3002. If the result of S3001 is true, since the data in the range of the write request received from the host is in a state not referenced by other snapshots (hereinafter referred to as a separate state), the update of the snapshot allocation management table and the SS-Mapping management table can be eliminated by overwriting the same address on the SS-VDEV.

[0195] Next, the snapshot allocation determination program 1113 refers to SS-Mapping-Info to obtain how the data in the write object range is dispersed (distributed) and stored on the SS-VDEV (S3002). This number is hereinafter referred to as the dispersion number. For example, when 256KB of data is written from the host, if the SS-Mapping is stored in different addresses on the SS-VDEV in three blocks of 32KB, 128KB, and 96KB before the update, the dispersion number count is 3. Such a situation may occur when only a part is updated after the snapshot is made. In the case of a large dispersion number, since it is necessary to separately implement the mapping update process from the SS-VDEV to the CR-VDEV or the Dedup-VDEV, the processing overhead of the write increases and the throughput decreases. Therefore, when a write of a size larger than the management unit of the mapping information is required and it is dispersed on the SS-VDEV, it can be expected that in a single state, the effect of reducing the processing can be achieved by implementing the snapshot appending process and allocating the continuous area on the SS-VDEV together.

[0196] Next, the snapshot allocation determination program 1113 determines whether the dispersion number obtained in S3002 is above the threshold (S3003). When the dispersion number is above the threshold (S3003: Yes), proceed to S3004. When the dispersion number is below the threshold (S3003: No), proceed to S3007. The setting of the threshold here is to switch between the case where the mapping information is updated multiple times in a dispersed state and the case where the mapping information is updated together with the allocation of a new area, which is more advantageous in terms of performance. The specific threshold is set according to the actual installation or performance characteristics of the program. For example, if the dispersion number is within 2, then the overwriting performance is better than allocating a new area on the snapshot space, and the threshold can be set to 3.

[0197] Next, the snapshot allocation determination program 1113 determines whether the area of ​​the write target volume can be allocated to a new area on the SS-VDEV with a number less than the current distribution number (S3004). Specifically, the snapshot allocation management table 1008 is referred to to determine whether a continuous area in an unallocated state can be ensured. If it is determined that it can be allocated (S3004: Yes), the snapshot allocation determination program 1113 performs snapshot append processing (S3008). If it is determined that it cannot be allocated (S3004: No), the process proceeds to S3005.

[0198] Next, the snapshot allocation determination program 1113 determines whether a new VDEV can be allocated on the SS-VDEV (S3005). If it is determined that it can be allocated (S3005: Yes), the process proceeds to S3006 to allocate the new VDEV to the SS-VDEV. Next, the snapshot allocation determination program 1113 performs snapshot append processing (S3008) to allocate a new area on the SS-VDEV. If it is determined that a new VDEV cannot be allocated (S3005: No), the process proceeds to S3007 to overwrite the SS-VDEV.

[0199] When the process proceeds to S3007, the snapshot allocation determination program 1113 performs a Dedup addition process. In this case, unlike the case of proceeding to S3008, the snapshot addition process is skipped and the same address on the SS-VDEV is overwritten. This eliminates the need to update the snapshot allocation management table and the SS-Mapping management table.

[0200] Fig.31 1 shows the flow of the snapshot addition process. The snapshot addition process is a process of newly allocating an area on the SS-VDEV 11S to the area of ​​the PVOL 10P that is the target of a write request from the host. The snapshot addition process is executed by a snapshot addition program 1106 called from the snapshot acquisition program 1101 or the read / write program 1105 .

[0201] The snapshot adding program 1106 secures a new area (block address with status 1902 being "0") in the target SS-VDEV11S (SS-VDEV11S corresponding to SS-Family9 including the target VOL (e.g., the SVOL of the target or the VOL to which data is written)) by updating the snapshot allocation management table 1008 (S3101). Next, the snapshot adding program 1106 causes the Dedup adding program 1107 to execute the Dedup adding process (S3102).

[0202] Then, the snapshot adding program 1106 updates the SS-Mapping management table 1010 (S3103). In S3103, for example, the snapshot adding 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" mentioned here is the SS-Mapping-Info corresponding to the data in the target VOL.

[0203] The snapshot adding program 1106 updates the Dir management table 1009 corresponding to the Dir-Info of the target SS-VDEV11S (S3104). In S3104, SS-Mapping-Info (information indicating the reference address in SS-VDEV) about the write target data is associated with the address of the VOL10 of the data.

[0204] The snapshot adding program 1106 refers to the generation management tree table 1007 (Dir-Info generation management tree 70) (S3105) and determines whether the generation # of the Dir-Info of the target VOL (data writing destination VOL) ​​is consistent with the generation # of the SS-Mapping-Info before adding (S3106).

[0205] If the result of the determination in S3106 is true (S3106: Yes), it means that after the data is saved in the area on the SS-VDEV indicated by the SS-Mapping-Info before the addition, no snapshot sharing the area has been created. In other words, it can be determined that the area on the SS-VDEV indicated by the SS-Mapping-Info before the addition is a garbage cell. Therefore, the snapshot addition program 1106 initializes the object entry of the SS-Mapping management table 1010 before the addition, releases the object entry of the snapshot allocation management table 1008 (S3107), and ends the processing.

[0206] If the result of S3106 is false (S3106: No), it means that after the data is stored in the area on the SS-VDEV indicated by the SS-Mapping-Info before the addition, a snapshot sharing the area is created and the generation # of Dir-Info is incremented. In this case, since the area on the SS-VDEV before the addition does not become a garbage unit, the SS-Mapping management table 1010 before the addition is in the original state, and the processing is terminated.

[0207] Fig.322 shows the flow of the dedup addition process. The dedup addition process is executed by the dedup addition program 1107 called from the snapshot addition program 1106 .

[0208] The Dedup appender 1107 determines whether there is duplicate data in the data stored in the Pool (S3201). Although the details are not described in the figure, if all the data are checked to see if there is data with the same content, the amount of calculation will become huge, so a method is adopted in which a representative value of data such as a hash value is calculated by performing operations using a hash function on each data, and only the data with the same representative value is compared. When the result of S3201 is false (S3201: No), the Dedup appender 1107 causes the compression appender 1108 to perform compression appending processing (S3207). As a result, the compressed data of the data of the storage destination of SS-VDEV11S is not stored in CR-VDEV11C via Dedup-VDEV11D and without changing the CPU211 of the processing body.

[0209] If the result of determination in S3201 is true (S3201: Yes), the Dedup adding program 1107 updates the Dedup allocation management table 1014 (S3202). In S3202, an entry of Dedup allocation information corresponding to the data stored in the target Dedup-VDEV11D is added to the Dedup allocation management table 1014.

[0210] The Dedup adding program 1107 updates the CR-Mapping management table 1012 ( S3203 ). In S3203 , an entry for CR-Mapping-Info corresponding to the data stored in Dedup-VDEV11D is added to the CR-Mapping management table 1012 .

[0211] The Dedup appender 1107 updates the Dir management table 1009 corresponding to the Dir-Info of the object Dedup-VDEV11D (S3204). In S3204, the CR-Mapping-Info (information indicating the reference destination address in CR-VDEV11CC) for the duplicate data is associated with the address of the object Dedup-VDEV11D of the data. In this way, by associating the duplicate data with the already saved data, the used capacity of the pool is reduced.

[0212] The dedup adding program 1107 initializes the CR-Mapping management table 1012 before adding (S3205).

[0213] The dedup adding program 1107 invalidates the pre-update allocation information (S3206). In S3206, the dedup adding program 1107 updates the dedup allocation management table 1014 and the compressed allocation management table 1011. In S3206, the target entry of the compressed allocation information is also garbaged for the area of ​​the dedup allocation management table 1014 where the allocation destination is 0.

[0214] Fig.33 The following is a flow of the compression and addition process. The compression and addition process is executed by the compression and addition program 1108 called from the Dedup addition program 1107 .

[0215] The compression adding program 1108 compresses the data to be written (S3301). The compression adding program 1108 updates the compression allocation management table 1011 (S3302). In S3302, for one or more sub-blocks that are storage destinations for the compressed data in S3301, the entry corresponding to each of the sub-blocks is updated.

[0216] The compression adding program 1108 causes the dump program 1109 to execute the dump process (S3303).

[0217] The compression adding program 1108 updates the CR-Mapping management table 1012 after the addition (S3304).

[0218] The compression adding program 1108 updates the Dir management table 1009 (S3305).

[0219] The compression adding program 1108 initializes the object entry of the CR-Mapping management table 1012 before adding (S3306).

[0220] The compression adding program 1108 invalidates the pre-update allocation information (S3307). In S3307, the Dedup adding program 1107 updates the Dedup allocation management table 1014 and the compression allocation management table 1011. In S3307, the target entry of the compression allocation information is also garbaged for the area of ​​the Dedup allocation management table 1014 where the allocation destination is 0.

[0221] Fig.34 The dump process is shown in FIG. 11. The dump process is executed by a dump program 1109 called from a compression adding program 1108.

[0222] The dump program 1109 determines whether the additional data (one or more compressed data) of the RAID stripe is in the cache unit 903 (S3401). A "RAID stripe" is a stripe in a RAID group (a storage area across multiple SSDs 220 constituting the RAID group). In the case where the RAID level of the RAID group requires a parity bit, the size of the "additional data of the RAID stripe" can be the size obtained by subtracting the size of the parity bit from the size of the stripe. In the case where the determination result of S3401 is false (S3401: No), the processing ends.

[0223] If the result of S3401 is true (S3401: Yes), the dump program 1109 refers to the Pool-Mapping management table 1015 to determine whether page 14 has been allocated to the storage destination (address of CR-VDEV11C) of the additional data of the RAID stripe amount (S3402). If the result of S3402 is false (S3402: No), the process proceeds to S3405.

[0224] If the result of the determination in S3402 is true (S3402: Yes), the dump program 1109 updates the Pool allocation management table 1016 (S3403). Specifically, the dump program 1109 allocates page 14. In S3403, the entry corresponding to the allocated page 14 in the Pool allocation management table 1016 (for example, the status 2704, the allocation destination VDEV# 2705, and the allocation destination address 2706) is updated.

[0225] The dump program 1109 registers page #2602 of the allocated page in the entry corresponding to the storage destination of the additional data of the RAID stripe amount in the Pool allocation management table 1016 (S3404).

[0226] The dump program 1109 writes the additional data of the RAID stripe amount into the stripe that is the basis of the page (S3405). If the RAID level is a RAID level that requires parity, the dump program 1109 generates parity based on the additional data of the RAID stripe amount and writes the parity into the stripe.

[0227] Fig.35 11 is a flowchart showing the processing procedure of the read process. The read process is executed by the read / write program 1105 in response to a read request from the host device.

[0228] First, in S3500, the read / write program 1105 obtains the address of the data of the read request object from the server system 202 in the PVOL or snapshot. Next, in S3701, the read / write program 1105 determines whether the data of the read request object is a cache hit. If the data of the read request object is a cache hit (S3501: Yes), the read / write program 1105 transfers the processing to S3508, and if there is no cache hit (S3501: No), the processing is transferred to S3502.

[0229] In S3502, the read / write program 1105 refers to the Dir management table 1009 and the SS-Mapping management table 1010, and obtains the address on the SS-VDEV of the reference destination based on the address in the PVOL / snapshot obtained in S3500. At this time, if the size of the target data of the read request is larger than the management unit of the SS-Mapping management table 1010, all entries are referred to and the address on the SS-VDEV is obtained.

[0230] Next, in S3503, the read / write program 1105 refers to the Dir management table 1009 and the CR-Mapping management table 1012, and acquires the address in the CR-VDEV or the Dedup-VDEV based on the address in the SS-VDEV acquired in S3502.

[0231] Next, in S3504, it is determined whether the reference destination address obtained in S3503 is an address on the Dedup-VDEV. Specifically, the reference destination CR-VDEV#2303 in the CR-Mapping management table 1012 is obtained, and the CR-VDEV management table 1002 is referenced to determine the VDEV#1301 that the CR-VDEV#2303 is consistent with the CR-VDEV#1302. In the case where the result of the determination in S3504 is false (S3504: No), the read / write program 1105 proceeds to S3506. On the other hand, in the case where the result of the determination in S3504 is true (S3504: Yes), the read / write program 1105 refers to the Dir management table 1009 and the CR-Mapping management table 1012 based on the address in the Dedup-VDEV determined in S3503, and obtains the address in the CR-VDEV (S3505).

[0232] Next, the read / write program 1105 expands the data stored in the address in the CR-VDEV determined in S3503 or S3505 and updates it to the cache memory.

[0233] Next, the read / write program 1105 determines whether all the data in the range requested by the host device has been read out to the cache (S3507). If the result of the determination is true, the read / write program 1105 proceeds to S3508, transfers the data that hit the cache in S3501 or the data updated in S3506 to the host device, and ends the process.

[0234] On the other hand, when the result of S3507 is false (S3507: No), the read / write program 1105 returns to S3502 and re-updates the insufficient data in the cache. In this way, when the data in the range requested by the host is stored in a continuous area on the CR-VDEV, the data can be fully prepared in the cache by only updating from the drive once. However, when the data is stored in a dispersed manner on the SS-VDEV, the Dedup-VDEV or the CR-VDEV, the throughput performance decreases due to multiple metadata references or update operations from the drive.

[0235] As described above, the disclosed storage system 201 is characterized in that it includes an SSD 220 as a storage device and a processor 211 for accessing the storage device; the processor 211 manages a primary volume 10P as a target for reading and writing by a host and a snapshot volume 10S generated based on the primary volume 10P as a snapshot group 9; the processor 211 uses a snapshot virtual device 11S, which is a logical address space corresponding to the snapshot group 9, as a storage destination for data of the primary volume 10P and the snapshot volume 10S; when receiving a write request from the host, the processor 211 switches between overwriting processing and new allocation processing, the overwriting processing overwriting an already allocated area on the snapshot virtual device 11S and the new allocation processing allocating a new area on the snapshot virtual device 11S to the address range of the write destination based on a reference status of the snapshot volume 10S to the address range of the write destination and a distribution degree of the address range of the write destination in the snapshot virtual device 11S.

[0236] Therefore, in a storage system providing snapshots, by optimizing the update amount of mapping information and the data transfer amount according to the length of data written from the host and the state of mapping, and switching the allocation of virtual device areas, higher throughput performance can be achieved.

[0237] In addition, since the RoW method is used as the snapshot function, the snapshot data can be compressed in the same way as normal data, so the capacity efficiency is high, and the use of storage media such as flash memory and its power consumption can be reduced, thereby saving resources and saving power.

[0238] Furthermore, the processor 211 performs the overwrite process on the condition that there is no reference to the write destination address range from the snapshot volume 10S and the number of distributions of the write destination address range is smaller than a threshold value on the snapshot virtual device 11S.

[0239] Therefore, when the write destination is independent data and is sufficiently continuous, overwrite processing is performed, and when the write destination is not independent data or is independent data but written in a dispersed manner in a discontinuous area, new allocation processing is performed.

[0240] Furthermore, in the disclosed storage system, when a plurality of volumes belonging to the same snapshot group 9 have the same data, a predetermined area on the snapshot virtual device 11S is allocated to the same data, and the plurality of volumes refer to the predetermined area.

[0241] Therefore, data referred to by the snapshot can be managed efficiently.

[0242] Furthermore, when a plurality of volumes belonging to different snapshot groups 9 have the same data, the disclosed storage system allocates a predetermined area on the deduplication virtual device 11D referred to from the snapshot virtual device 11S to the same data.

[0243] Therefore, duplicate data can be managed efficiently.

[0244] In addition, the mapping information for managing the correspondence between the address of the volume belonging to the snapshot family 9 and the area on the snapshot virtual device 11S includes information related to the generation of the snapshot. When the generation of the address range of the write destination is inconsistent with the latest generation, the processor 211 performs the new allocation processing.

[0245] Therefore, whether or not the write destination is independent data can be managed efficiently.

[0246] In addition, when there is no reference to the address range of the write destination from the snapshot volume 10S and the address range of the write destination is a dispersed number above a threshold on the snapshot virtual device 11S, the processor 211 determines whether there is an area required for the new allocation processing on the snapshot virtual device 11S, and performs the allocation when the required area exists; and performs the new allocation processing after expanding the snapshot virtual device 11S when the required area does not exist.

[0247] Therefore, efficient memory operation can be achieved while expanding the snapshot virtual device 11S as needed.

[0248] Furthermore, the processor 211 sets a compression-addition virtual device 11C between the snapshot virtual device 11S and the storage device, and compresses the write-requested data and writes the data into the storage device.

[0249] Therefore, in a storage system that manages data in a compressed manner, resources of virtual devices can be effectively utilized to achieve high throughput.

[0250] In addition, the present invention is not limited to the above-mentioned embodiments, but includes various modifications. For example, the above-mentioned embodiments are described in detail in order to easily understand the present invention, and are not necessarily limited to having all the structures described. In addition, not only can the removal of the structure be carried out, but also the replacement or addition of the structure can be carried out.

Claims

1. A storage system, characterized in that: have: Storage device; as well as A processor accesses the storage device; The processor manages the primary volume as the object to be read and written by the host and the snapshot volume generated from the primary volume as a snapshot family. The processor uses the logical address space corresponding to the snapshot family, that is, the snapshot virtual device, as a storage destination for the data of the primary volume and the snapshot volume. When the processor receives a write request from the host, the processor switches between overwriting processing and new allocation processing based on a reference status of the address range of the write destination from the snapshot volume and a distribution degree of the address range of the write destination in the snapshot virtual device. The overwriting processing overwrites the allocated area on the snapshot virtual device, and the new allocation processing allocates a new area on the snapshot virtual device for the address range of the write destination.

2. The storage system according to claim 1, characterized in that: The processor performs the overwrite process on the condition that there is no reference to the write destination address range from the snapshot volume and the address range of the write destination has a distribution number smaller than a threshold value on the snapshot virtual device.

3. The storage system according to claim 1, characterized in that: When a plurality of volumes belonging to the same snapshot family have the same data, a predetermined area on the snapshot virtual device is allocated to the same data, and the plurality of volumes refer to the predetermined area.

4. The storage system according to claim 1, wherein: When a plurality of volumes belonging to different snapshot groups have the same data, a predetermined area on the deduplication virtual device referenced from the snapshot virtual device is allocated to the same data.

5. The storage system according to claim 1, wherein: The above processors, The mapping information for managing the correspondence between the address of the volume belonging to the snapshot family and the area on the snapshot virtual device includes information on the generation of the snapshot. When the generation of the address range of the write destination does not coincide with the latest generation, the new allocation process is performed.

6. The storage system according to claim 2, characterized in that: The processor determines whether an area required for the new allocation process exists on the snapshot virtual device when there is no reference to the address range of the write destination from the snapshot volume and the address range of the write destination is a dispersed number greater than a threshold value on the snapshot virtual device, and performs the new allocation process when the required area exists, and performs the new allocation process after expanding the snapshot virtual device when the required area does not exist.

7. The storage system according to claim 1, characterized in that: The processor sets a compression-addition virtual device between the snapshot virtual device and the storage device, and compresses the write-requested data and writes the data into the storage device.

8. A data processing method is a data processing method of a storage system, the storage system comprising a storage device and a processor for accessing the storage device, wherein the data processing method is characterized in that: The processor manages the primary volume as the object to be read and written by the host and the snapshot volume generated from the primary volume as a snapshot family. The processor uses the logical address space corresponding to the snapshot family, that is, the snapshot virtual device, as a storage destination for the data of the primary volume and the snapshot volume. When the processor receives a write request from the host, the processor switches between overwriting processing and new allocation processing based on a reference status of the address range of the write destination from the snapshot volume and a distribution degree of the address range of the write destination in the snapshot virtual device. The overwriting processing overwrites the allocated area on the snapshot virtual device, and the new allocation processing allocates a new area on the snapshot virtual device for the address range of the write destination.

Images