Storage system and data processing method

Abstract

The invention provides a storage system and a data processing method, which can efficiently utilize resources of virtual equipment to realize high throughput. The processor uses a snapshot virtual device as a storage destination of data of a main volume and a snapshot volume, compresses data stored in the snapshot virtual device and stores the compressed data in a compression virtual device, and stores the data stored in the compression virtual device in the storage device. When the processor receives a write request from the host, the write request is written according to the size of the address range of the write destination. An overwrite process for overwriting the allocated area on the snapshot virtual device to the large-size data and a new allocation process for allocating a new area on the snapshot virtual device to the address range of the write destination to the small-size data are switched, and a plurality of pieces of small-size data stored in the new area are compressed. And intensively storing in the compressed virtual equipment.

Description

Technical Field

[0001] The present 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 opportunity for data replication has also increased. As a result, in a storage system, a snapshot function has become increasingly important. Conventionally, a representative implementation method of a snapshot is a Redirect on Write (RoW) method. In the RoW method, since there is no replication of data and meta information, it has an advantage of having little influence on I / O performance at the time of snapshot generation. The RoW method is widely used in an All Flash Array (AFA) device. The RoW method is a method of appending and writing data. Appending and writing means that when writing data to a storage system, instead of overwriting the data stored before the write, the data to be written is stored in a new area, and the meta information is rewritten in such a way as to refer to the data stored in the new area.

[0003] In such data management that applies a deduplication technique and a snapshot technique, when the address of data in a virtual device is changed due to garbage collection or other reasons, and when the address is a reference destination of different multiple addresses in multiple snapshot families, it is necessary to change the reference destination address for each of the multiple addresses. Therefore, the change of the address mapping takes a long time, and as a result, the time of the entire process accompanying the change of the address mapping becomes long.

[0004] In Patent Document 1, the following method is proposed: data shared from multiple VOLs through deduplication and snapshot is allocated to a virtual space different from the storage destination of individual data referred to only from 1 VOL, thereby reducing the number of references to duplicate data and improving the efficiency of garbage collection processing.

[0005] However, in the case of adding a virtual device space as in Patent Document 1, the mapping information referred to and updated during read / write IO processing increases, and as a result, there are problems of an increase in the load of the storage controller and a decrease in throughput.

[0006] Patent Document 1: U.S. Patent No. 10,817,209 Specification Summary of the Invention

[0007] Therefore, an object of the present invention is to achieve both garbage collection performance and high throughput by effectively using the resources of a virtual device.

[0008] To achieve the above object, one representative storage system of the present invention includes a storage device and a processor that accesses the storage device. The processor manages a main volume that is the object of reading and writing by a host and a snapshot volume generated from the main volume as a snapshot family. The processor uses a logical address space corresponding to the snapshot family, i.e., a snapshot virtual device, as the storage destination for the data of the main volume and the snapshot volume. The processor compresses the data stored in the snapshot virtual device and stores it in a compressed virtual device, and stores the data stored in the compressed virtual device in the storage device. When the processor receives a write request from the host, according to the size of the address range of the write destination, the processor switches between an overwrite process of overwriting an area allocated on the snapshot virtual device for large-sized data and a new allocation process of allocating a new area on the snapshot virtual device to the address range of the write destination for small-sized data, compresses a plurality of small-sized data stored in the new area, and centrally stores it in the compressed virtual device.

[0009] In addition, one representative data processing method of the present invention is a data processing method for a storage system including a storage device and a processor that accesses the storage device. The processor manages a main volume that is the object of reading and writing by a host and a snapshot volume generated from the main volume as a snapshot family. The processor uses a logical address space corresponding to the snapshot family, i.e., a snapshot virtual device, as the storage destination for the data of the main volume and the snapshot volume. The processor compresses the data stored in the snapshot virtual device and stores it in a compressed virtual device, and stores the data stored in the compressed virtual device in the storage device. When the processor receives a write request from the host, according to the size of the address range of the write destination, the processor switches between an overwrite process of overwriting an area allocated on the snapshot virtual device for large-sized data and a new allocation process of allocating a new area on the snapshot virtual device to the address range of the write destination for small-sized data, and compresses a plurality of small-sized data stored in the new area and centrally stores it in the compressed virtual device.

[0010] According to the present invention, it is possible to efficiently utilize the resources of the virtual device to achieve high throughput. Through the following description of the embodiments, problems, structures, and effects other than the above become clear. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a block diagram showing the hardware structure of the storage system in the present invention.

[0012] Figure 2 It is a schematic diagram of the storage control of the storage system in the present invention.

[0013] Figure 3 It is a schematic diagram of the management of the mapping between the addresses in the SS-Family and the addresses in the SS-VDEV.

[0014] Figure 4 It is a schematic diagram of the management of the mapping between the addresses in the SS-VDEV and the addresses in the Dedup-VDEV, the management of the mapping between the addresses in the SS-VDEV and the addresses in the CR-VDEV, and the management of the mapping between the addresses in the Dedup-VDEV and the addresses in the CR-VDEV.

[0015] Figure 5 It is an explanatory diagram showing the structure of the memory possessed by the storage controller of the present invention.

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

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

[0018] Figure 8 It is a diagram showing the structure of the ownership management table.

[0019] Figure 9 It is a diagram showing the structure of the CR-VDEV management table.

[0020] Figure 10 It is a diagram showing the structure of the snapshot management table.

[0021] Figure 11 It is a diagram showing the structure of the VOL-Dir management table.

[0022] Figure 12 It is a diagram showing the structure of the latest generation table.

[0023] Figure 13 It is a diagram showing the structure of the reclaim management table.

[0024] Figure 14 It is a diagram showing the structure of the generation management tree table.

[0025] Figure 15 It is a diagram showing the structure of the snapshot allocation management table.

[0026] Figure 16 It is a diagram showing the structure of the Dir management table.

[0027] Figure 17 It is a diagram showing the structure of the SS-Mapping management table.

[0028] Figure 18 It is a diagram showing the structure of the compression allocation management table.

[0029] Figure 19 It is a diagram showing the structure of the CR-Mapping management table.

[0030] Figure 20 It is a diagram showing the structure of the Dedup-Dir management table.

[0031] Figure 21 It is a diagram showing the structure of the Dedup allocation management table.

[0032] Figure 22 It is a diagram showing the structure of the Pool-Mapping management table.

[0033] Figure 23 It is a diagram showing the structure of the Pool allocation management table.

[0034] Figure 24 It is a diagram showing the process of snapshot acquisition processing.

[0035] Figure 25 It is a diagram showing the process of snapshot restoration processing.

[0036] Figure 26 It is a diagram showing the process of snapshot deletion processing.

[0037] Figure 27 It is a diagram showing the process of asynchronous recovery processing.

[0038] Figure 28 It is a diagram showing the process of write processing (front-end).

[0039] Figure 29 It is a diagram showing the process of write processing (back-end).

[0040] Figure 30 It is a diagram showing the process of snapshot allocation determination processing.

[0041] Figure 31 It is a diagram showing the process of snapshot append processing.

[0042] Figure 32 It is a diagram showing the process of Dedup append processing.

[0043] Figure 33 It is a diagram showing the process of compression append processing.

[0044] Figure 34 It is a diagram showing the process of destaging processing.

[0045] Figure 35 It is a diagram showing the process of read processing.

[0046] Figure 36This is a diagram showing the process of GC (Garbage Collection) processing. Detailed implementation

[0047] Hereinafter, embodiments will be described with reference to the accompanying drawings.

[0048] [Embodiment 1]

[0049] Figure 1 It shows the hardware structure of a computer system.

[0050] 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. The storage network 204 and the management network 205 can be the same communication network.

[0051] The storage system 201 includes a plurality of storage controllers 210 and a plurality of SSDs 220. A 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. The data stored in the page 14 of the pool 13 is stored in one or more SSDs 220.

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

[0053] The CPU 211 executes programs stored in the memory 212.

[0054] The memory 212 stores programs executed by the CPU 211 and data used by the CPU 211, etc. The memory can be dualized in the group of the memory 212 and the CPU 211.

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

[0056] The backend 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 backend interface 213.

[0057] 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 server system 202 is connected to the front-end interface 214 via the storage network 204.

[0058] 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.

[0059] 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) 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) or a logical address such as an LBA (Logical Block Address).

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

[0061] Figure 2 Represents an overview of the storage control of the storage system. In addition, in Figure 2 The data marked with capital letters (Data A, B, C,...) are block data, and the data marked with lowercase letters (Data a, b, c,...) are sub-block data. The block data can be data in units of blocks. A block can be a logical storage area (logical address range) with a fixed length. The sub-block data is compressed data of the block data, and a sub-block group (one or more sub-blocks) is the data to be stored. A sub-block can be a logical storage area smaller than the block. For example, an integer multiple of the sub-block can be the block.

[0062] The 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 (Deduplication Virtual Device) 11D, a CR-VDEV (Compression Append Virtual Device) 11C, and a pool 13.

[0063] The SS-Family 9 is a VOL group that includes a PVOL10P and an SVOL10S that is a snapshot of the PVOL10P.

[0064] The SS-VDEV 11S is a virtual device as a logical address space, and a certain VOL10 in the SS-Family 9 is set as the storage destination of the data to be stored.

[0065] The Dedup-VDEV 11D is a virtual device as a logical address space different from the SS-VDEV 11S, and is set as the storage destination of the duplicate data of two or more SS-VDEVs 11S.

[0066] CR-VDEV11C is a virtual device that serves as a logical address space different from SS-VDEV11S and Dedup-VDEV11D, and is set as the storage destination for compressed data.

[0067] Multiple CR-VDEV11Cs each correspond to one of SS-VDEV11S and Dedup-VDEV11D, and do not correspond to both VDEV11S and 11D. That is, in each CR-VDEV11C, the VDEV (virtual device) corresponding to this CR-VDEV11C becomes the storage destination for the data whose storage destination it is, and the VDEV that does not correspond to this CR-VDEV11C does not become the storage destination for the data whose storage destination it is. Regarding the compressed data for which CR-VDEV11C is the storage destination, Pool 13 is the storage destination.

[0068] Pool 13 is a logical address space based on at least a part of the storage devices (e.g., permanent storage devices) of the storage system. Pool 13 can also be based on at least a part of the external storage devices (e.g., permanent storage devices) of the storage system instead of or in addition to at least a part of the storage devices of the storage system. Pool 13 has multiple pages 14 as multiple logical regions. The compressed data for which CR-VDEV11C is the storage destination is stored in page 14 of Pool 13. The mapping between the addresses in CR-VDEV11C and the addresses in Pool 13 is 1:1. Pool 13 is composed of one or more pool VOLs.

[0069] According to Figure 2 the example shown below, the following storage control is performed.

[0070] The processor generates SVOL10S0 as a snapshot of PVOL10P0, thereby enabling the realization of SS-Family9-0 with PVOL10P0 as the root VOL. In addition, the processor generates SVOL10S1 as a snapshot of PVOL10P1, thereby enabling the realization of SS-Family9-1 with PVOL10P1 as the root VOL. According to Figure 2 as examples of multiple SS-Families, there are SS-Family9-0 and 9-1.

[0071] The storage system has one or more SS-VDEV11S for each of the multiple SS-Family9s. Regarding each SS-Family9, for the data whose storage destination is a certain VOL10 in this SS-Family9, the SS-VDEV11S corresponding to this SS-Family9 among the multiple SS-VDEV11S is used as the storage destination. Taking SS-Family9-0 as an example, specifically, it is as follows.

[0072] · For the data A whose storage destination for the SVOL10S of SS-Family9-0 is the processor, the SS-VDEV11S0 is used as the storage destination. The processor maps the address corresponding to the data A in the SVOL10S0 to the address corresponding to the data A in the SS-VDEV11S0 corresponding to SS-Family9-0.

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

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

[0075] That is, since the data C is duplicated in the SS-VDEV11S0 and 11S1 (an example of two or more SS-VDEV11Ss) of SS-Family9-0 and 9-1, the processor maps the two addresses of the duplicate data C in the SS-VDEV11S0 and 11S1 to the address corresponding to the duplicate data C in the Dedup-VDEV11D. Then, the processor compresses the duplicate data C and sets the storage destination of the compressed data c to the CR-VDEV11CC corresponding to the Dedup-VDEV11D. That is, the processor maps the address (block address) of the duplicate data C in the Dedup-VDEV11D to the address (sub-block address) of the compressed data c in the CR-VDEV11CC. In addition, the processor allocates the page 14B to the CR-VDEV11CC and stores the compressed data c in the page 14B. The address of the compressed data c in the CR-VDEV11CC is mapped to the address in the page 14B of the pool 13.

[0076] On the other hand, regarding SS-VDEV11S0, the data A does not duplicate with the data in other SS-VDEV11S1. Therefore, the processor compresses the non-duplicate data A and sets the compressed data a as 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 in page 14A of pool 13.

[0077] CR-VDEV11C is an append-type VDEV. Therefore, when the processor makes CR-VDEV11C corresponding to SS-VDEV11S the storage destination of updated data and when the processor makes CR-VDEV11C corresponding to Dedup-VDEV11D the storage destination of updated data, the address mapping is updated. Specifically, the processor performs the following storage control, for example.

[0078] · When the storage object for CR-VDEV11C0 is the updated data a′ of the compressed data a, the processor sets the storage destination of the updated data a′ as the free 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 is mapped to the address of the compressed data a to the storage destination address of the updated data a′ in CR-VDEV11C0 instead of the address of the compressed data a in CR-VDEV11C0. In addition, the processor maps the address in page 14A that is mapped to the address of the compressed data a to the storage destination address of the updated data a′ in CR-VDEV11C0 instead of the address of the compressed data a in CR-VDEV11C0.

[0079] · When the storage object for CR-VDEV11CC is the updated data c′ which is compressed data c, the processor sets the storage destination of the updated data c′ to the free address in CR-VDEV11CC and invalidates the address of the compressed data c before the update. The processor maps the address in Dedup-VDEV11D that is mapped to the address of the compressed data c to the storage destination address of the updated data c′ in CR-VDEV11CC instead of the address of the compressed data c in CR-VDEV11CC. In addition, the processor maps the address in page 14B that is mapped to the address of the compressed data c to the storage destination address of the updated data c′ in CR-VDEV11CC instead of the address of the compressed data a in CR-VDEV11CC. Generally, in order to increase the reduction effect of the data volume generated by snapshot and deduplication, the above mapping is managed in small units such as 4KB and 8KB.

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

[0081] According to Figure 2 In the example shown, different from SS-VDEV11S which is set as the storage destination of the data in SS-Family9, Dedup-VDEV11D is prepared as the storage destination of the duplicate data in two or more SS-Family9s. Therefore, even if the address of the duplicate data C in Dedup-VDEV11D changes, the address mapping of the changed object can be completed through two mappings (the mappings of the two addresses in SS-VDEV11S0 and 11S1 respectively). On the other hand, in a comparative example, the storage destination of the data in SS-Family9 and the storage destination of the duplicate data in two or more SS-Family9s are the same VDEV. In this case, the address mapping of the changed object related to the duplicate data C is four mappings (the mappings related to each of the four addresses in VOL10P0, 10S0, 10P1, and 10S1). In the present embodiment, it is expected to change the address mapping in a shorter time compared with a comparative example.

[0082] Prepare CR-VDEV11CC separately for Dedup-VDEV11D from Dedup-VDEV11D. Therefore, even if the address of the compressed data c in CR-VDEV11CC changes, the address mapping of the changed object is completed through one mapping (a mapping related to one address in Dedup-VDEV11D). 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-Family9s are the same VDEV. In this case, the address mapping of the changed object related to the compressed data c of the duplicate data C is four mappings (mappings related to each of the four addresses in VOL10P0, 10S0, 10P1, and 10S1). In the present embodiment, it is expected to change the address mapping in a shorter time compared to a comparative example.

[0083] The address change 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 maps the address in Dedup-VDEV11D mapped to the address before the change to the address after the change in CR-VDEV11CC. Since it is desired to change the address mapping related to the compressed data of the duplicate data in a short time, it is desired to perform garbage collection in a short time. In addition, the garbage collection of CR-VDEV11C corresponding to SS-VDEV11S includes the following processing, for example. That is, the processor changes the address of the updated data a' (the updated data of the compressed data a) in CR-VDEV11C0, and maps the address in SS-VDEV11S0 mapped to the address before the change to the address after the change in CR-VDEV11C0.

[0084] Regarding at least one CR-VDEV11C, a write-once VDEV that stores uncompressed data may be used instead of CR-VDEV11C, but in the present embodiment, CR-VDEV11C is used as the write-once VDEV. Therefore, the data finally stored in the storage device is compressed data, and thus the consumed storage capacity can be reduced.

[0085] Figure 3 Shows an overview of the management of the mapping between the address in SS-Family9 and the address in SS-VDEV11S. In addition, in the drawings, "GX" (X is an integer of 0 or more) represents generation X. In addition, Figure 3 Take SS-Family9-0 and SS-VDEV11S0 as examples.

[0086] The processor can use the meta-information to manage the mapping between the addresses in VOL10 of SS-Family9-0 and the addresses in SS-VDEV11S0. The meta-information includes Dir-Info (directory information) and SS-Mapping-Info (snapshot mapping information). The processor manages the data of PVOL10P0 and SVOL10S0 by establishing a correspondence between Dir-Info and SS-Mapping-Info. Regarding the data with VOL10 as the storage destination, Dir-Info has information representing the address of the reference source (the address in VOL10), and the SS-Mapping-Info corresponding to this data has information representing the address of the reference destination (the address in SS-VDEV11S0).

[0087] Moreover, the processor manages the time series of PVOL10P0 and SVOL10S0 through the generation information associated with Dir-Info. For each data with SS-VDEV11S0 as the storage destination, the generation information indicating the generation in which the data is generated is managed in association with SS-Mapping-Info. In addition, the processor manages the latest generation information at this time point as the latest generation.

[0088] Assume that before the snapshot is taken, there are data A0, B0, and C0 with PVOL10P0 as the storage destination. In addition, assume that the latest generation is "0".

[0089] The Dir-Info corresponding to PVOL10P0 is associated with "0" as the generation # (representing the generation number), and includes reference information representing the reference destinations of all data A0, B0, and C0 in PVOL10P0. Thereafter, when the generation # associated with Dir-Info is "X", it can be said that Dir-Info is generation X.

[0090] Set SS-VDEV11S0 as the storage destination for data A0, B0, and C0, and associate SS-Mapping-Info with data A0, B0, and C0 respectively. In addition, each SS-Mapping-Info is associated with "0" as the generation #. When the generation # associated with SS-Mapping-Info represents "X", it can be said that the data corresponding to SS-Mapping-Info is the data of generation X.

[0091] In the state before snapshot acquisition, for each of data A0, B0, and C0, the information in Dir-Info refers to the SS-Mapping-Info corresponding to that data. By correlating Dir-Info with SS-Mapping-Info in this way, PVOL10P0 can be made to correspond to SS-VDEV11S0, enabling data processing for PVOL10P0.

[0092] To acquire a snapshot, the processor sets the copy of Dir-Info to the read-only Dir-Info of SVOL10S0. Then, the processor increments the generation of the 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 referred to by both the Dir-Info of generation 0 and the Dir-Info of generation 1.

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

[0094] Here, when a snapshot is acquired, the snapshot (SVOL10S0) in which writing is prohibited and the data is fixed at the acquisition time becomes generation 0, and PVOL10P0, which can write data even after the snapshot is acquired, becomes generation 1. Generation 0 is "one generation earlier in the direct line" relative to generation 1, and is conveniently referred to as "parent". Similarly, generation 1 is "one generation later in the direct line" relative to generation 0, and is conveniently referred to as "child". The storage system manages the parent-child relationship of generations as the Dir-Info generation management tree 70. In addition, the generation # of Dir-Info is the same as the generation # of VOL10 corresponding to that Dir-Info. In addition, the generation # of SS-Mapping-Info is the earliest generation # among the generation #s of one or more Dir-Info that refer to that SS-Mapping-Info.

[0095] Figure 4 Outlines the management of the mapping between the addresses in SS-VDEV11S and the addresses in Dedup-VDEV11D, the management of the mapping between the addresses in SS-VDEV11S and the addresses in CR-VDEV11C, and the management of the mapping between the addresses in Dedup-VDEV11D and the addresses in CR-VDEV11C. Figure 4 Taking SS-VDEV11S0, CR-VDEV11C0, and 11CC as examples.

[0096] The processor can use the meta-information to manage the mapping of addresses in SS-VDEV11S0 and addresses in Dedup-VDEV11D, the mapping of addresses in SS-VDEV11S0 and addresses in CR-VDEV11C0, and the mapping of 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 establishing a correspondence between Dir-Info and CR-Mapping-Info. Regarding the data with SS-VDEV11S0 as the storage destination, Dir-Info has information representing the address of the reference source (the address in SS-VDEV11S0), and the corresponding CR-Mapping-Info has information representing the address of the reference destination (the address in CR-VDEV11C0 or the address in Dedup-VDEV11D). Regarding the data with Dedup-VDEV11D as the storage destination, Dir-Info has information representing the address of the reference source (the address in Dedup-VDEV11D), and the corresponding CR-Mapping-Info has information representing the address of the reference destination (the address in CR-VDEV11CC). The processor can determine the address in SS-VDEV11S or Dedup-VDEV11D based on the address in CR-VDEV11C by referring to the compression allocation information.

[0097] Although omitted in the drawings, for moving the valid data on the CR-VDEV and ensuring continuous free areas, the storage system 201 holds the compression allocation management table 1011 on the memory 212 as the information of the reverse mapping from the address in the CR-VDEV to the address in the SS-VDEV or Dedup-VDEV.

[0098] Figure 5 Represents the structure of the memory 212.

[0099] The memory 212 has a control information section 901 for storing control information (which can also be called management information), a program section 902 for storing programs, and a cache section 903 for temporarily storing data.

[0100] Figure 6 Represents the information stored in the control information section 901.

[0101] 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 recycling 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.

[0102] Figure 7 Represents the program stored in the program unit 902.

[0103] The program unit 902 stores a snapshot acquisition program 1101, a snapshot recovery program 1102, a snapshot deletion program 1103, an asynchronous recycling program 1104, a read / write program 1105, a snapshot append program 1106, a Dedup append program 1107, a compression append program 1108, a downgrading 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.

[0104] Figure 8 Represents the structure of the ownership management table 1001.

[0105] The ownership management table 1001 manages the ownership of VOL10 or VDEV11. For example, the ownership management table 1001 has entries for each VOL10 and each VDEV11. The entry has information on VOL# / VDEV#1201 and owner CPU#1202.

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

[0107] In addition, regarding the owner CPU, instead of allocation in units of CPU211, allocation in units of CPU groups or allocation in units of storage controller 210 can also be used.

[0108] Figure 9 Represents the structure of the CR-VDEV management table 1002.

[0109] The CR-VDEV management table 1002 represents the CR-VDEV 11C corresponding to the SS-VDEV 11S or the Dedup-VDEV 11D. For example, the CR-VDEV management table 1002 has entries for each SS-VDEV 11S and each Dedup-VDEV 11D. The entries have information such as VDEV#1301 and CR-VDEV#1302.

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

[0111] Figure 10 Represents the structure of the snapshot management table 1003.

[0112] There is a snapshot management table 1003 for each PVOL10P (each SS-Family 9). The snapshot management table 1003 represents the acquisition time of each snapshot (SVOL10S). For example, the snapshot management table 1003 has entries for each SVOL10S. The entries have information such as PVOL#1401, SVOL#1402, and acquisition time 1403.

[0113] PVOL#1401 represents the identification number of the PVOL10P. SVOL#1402 represents the identification number of the SVOL10S. The acquisition time 1403 represents the acquisition time of the SVOL10S.

[0114] Figure 11 Represents the structure of the VOL-Dir management table 1004.

[0115] The VOL-Dir management table 1004 represents the correspondence between VOL and Dir-Info. For example, the VOL-Dir management table 1004 has entries for each VOL10. The entries have information such as VOL#1501, Root-VOL#1502, and Dir-Info#1503.

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

[0117] Figure 12 Represents the structure of the latest generation table 1005.

[0118] The latest generation table 1005 exists for each PVOL10P (each SS-Family9) and represents the generation (generation #) of that PVOL10P.

[0119] Figure 13 Represents the structure of the recycle management table 1006.

[0120] The recycle management table 1006 can be, for example, a bitmap and exists for each PVOL10P (each SS-Family9), in other words, exists for each Dir-Info generation management tree 70. The recycle management table 1006 has entries for each Dir-Info. The entries contain information such as Dir-Info#1701 and recycle request 1702.

[0121] Dir-Info#1701 represents the identification number of the Dir-Info. The recycle request 1702 indicates whether the recycle of the Dir-Info is requested. "1" indicates that the recycle is requested, and "0" indicates that the recycle is not requested.

[0122] Figure 14 Represents the structure of the generation management tree table 1007.

[0123] The generation management tree table 1007 exists for each PVOL10P (each SS-Family9), in other words, exists for each Dir-Info generation management tree 70. The generation management tree table 1007 has entries for each Dir-Info. The entries contain information such as Dir-Info#1801, generation #1802, Prev1803, and Next1804.

[0124] Dir-Info#1801 represents the identification number of the Dir-Info. Generation #1802 represents the generation of the VOL10 corresponding to the Dir-Info. Prev1803 represents the parent (upper level) Dir-Info of the Dir-Info. Next1804 represents the child (next) Dir-Info of the Dir-Info. The number of Next1804 can be the same as the number of child Dir-Info. In Figure 14 There are two child Dir-Info, so there are two Next1804 (Next-A1804A and Next-B1804B).

[0125] Figure 15 Represents the structure of the snapshot allocation management table 1008.

[0126] The snapshot allocation management table 1008 exists for each SS-VDEV11S and represents the mapping from the address in the SS-VDEV11S to the address in the VOL10. The snapshot allocation management table 1008 has entries for each address in the SS-VDEV11S. The entries have information such as the block address 1901, the status 1902, the allocation destination VOL#1903, and the allocation destination address 1904.

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

[0128] Figure 16 Represents the structure of the Dir management table 1009.

[0129] The Dir management table 1009 exists for each Dir-Info and represents the Mapping-Info of the reference destination of each data (each block data). For example, the Dir management table 1009 has entries for each address (block address). The entries have information such as the VOL / VDEV address 2001 and the reference destination Mapping-Info#2002.

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

[0131] Figure 17 Represents the structure of the SS-Mapping management table 1010.

[0132] The SS-Mapping management table 1010 exists for each Dir-Info of the VOL10. The SS-Mapping management table 1010 has entries for each SS-Mapping-Info corresponding to the Dir-Info of the VOL10. The entries have information such as the Mapping-Info#2101, the reference destination address 2102, the reference destination SS-VDEV#2103, and the generation #2104.

[0133] Mapping-Info#2101 represents the identification number of the SS-Mapping-Info. The reference destination address 2102 represents the address (the address in SS-VDEV11S) referred to by the SS-Mapping-Info. The reference destination SS-VDEV#2103 represents the identification number of the SS-VDEV11S having the address referred to by the SS-Mapping-Info. The generation #2104 represents the generation of the data corresponding to the SS-Mapping-Info.

[0134] Figure 18 Represents the structure of the compression allocation management table 1011.

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

[0136] The sub-block address 2201 represents the address of the sub-block. The data length 2202 represents the number of sub-blocks (for example, "2" means that the compressed data exists in two sub-blocks) that make up the sub-block group (one or more sub-blocks) storing the compressed data. The status 2203 represents the status of the sub-block ("0" means free, "1" means allocated, "2" means the object of GC (garbage collection)). The start sub-block address 2204 represents the address of the sub-block at the start of one or more sub-blocks (one or more sub-blocks storing the compressed data) containing the sub-block. The allocation destination VDEV#2205 represents the identification number of the VDEV11 (SS-VDEV11S or Dedup-VDEV11D) of the block having the allocation destination of the sub-block. The allocation destination address 2206 represents the address of the block of the allocation destination of the sub-block (the block address in SS-VDEV11S or Dedup-VDEV11D).

[0137] Figure 19 Represents the structure of the CR-Mapping management table 1012.

[0138] The CR-Mapping management table 1012 exists for each Dir-Info of the Dedup-VDEV 11D and each Dir-Info of the SS-VDEV 11S. The CR-Mapping management table 1012 has entries for each CR-Mapping-Info corresponding to the Dir-Info of the Dedup-VDEV 11D and each CR-Mapping-Info corresponding to the Dir-Info of the SS-VDEV 11S. The entries have information such as Mapping-Info#2301, reference destination address 2302, reference destination CR-VDEV#2303, and data length 2304.

[0139] Mapping-Info#2301 represents the identification number of the CR-Mapping-Info. The reference destination address 2302 represents the address (the address of the first sub-block in the sub-block group) referred to by the CR-Mapping-Info. The reference destination CR-VDEV#2303 represents the identification number of the CR-VDEV 11C having the sub-block address referred to by the CR-Mapping-Info. The data length 2304 represents the number of blocks (blocks in the Dedup-VDEV 11D) referred to by the CR-Mapping-Info, or the number of sub-blocks constituting the sub-block group referred to by the CR-Mapping-Info.

[0140] Figure 20 Represents the structure of the Dedup-Dir management table 1013.

[0141] The Dedup-Dir management table 1013 exists for each Dedup-VDEV 11D and is equivalent to the Dedup-Dir-Info. The Dedup-Dir management table 1013 has entries for each address in the Dedup-VDEV 11D. The entries have information such as the Dedup-VDEV address 2401 and the reference destination allocation information#2402.

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

[0143] Figure 21 Represents the structure of the Dedup allocation management table 1014.

[0144] The Dedup allocation management table 1014 exists for each Dedup-VDEV11D (each Dedup-Dir-Info), representing the inverse reference mapping from the Dedup allocation information corresponding to the address in the Dedup-VDEV11D to the address in the SS-VDEV11S. The Dedup allocation management table 1014 has entries for each Dedup allocation information. The entry has information such as the allocation information #2501, the allocation destination SS-VDEV #2502, the allocation destination address 2503, and the linked allocation information #2504.

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

[0146] According to Figure 21 , the Dedup allocation information # "3" is linked to the Dedup allocation information # "1", and there is no Dedup allocation information linked to the Dedup allocation information # "3". Therefore, it can be known that the duplicate data in the Dedup-VDEV address corresponding to the Dedup allocation information # "1" is the duplicate data in the SS-VDEV11S referred to by the Dedup allocation information # "1" and the SS-VDEV11S referred to by the Dedup allocation information # "3". Since the number of duplicate data is uncertain, the Dedup allocation information is linked according to the number of duplicate data. When the duplicate data exists in N SS-VDEV11S, N sequential Dedup allocation information is prepared.

[0147] Figure 22 Represents the structure of the Pool-Mapping management table 1015.

[0148] The Pool-Mapping management table 1015 exists for each CR-VDEV11C. The Pool-Mapping management table 1015 has entries for each area in the CR-VDEV11C in units of page size. The entry has information such as the VDEV address 2601 and the page #2602.

[0149] The VDEV address 2601 represents the start address of a region (e.g., multiple blocks) in units of the page size. The page #2602 represents the identification number of the allocated page 14 (e.g., the address in the pool 13 of page 14). In addition, in the case where there are multiple pools 13, the page #2602 may include the identification number of the pool 13 having page 14.

[0150] Figure 23 Represents the structure of the Pool allocation management table 1016.

[0151] For example, in the case where there are multiple pools 13, the Pool allocation management table 1016 exists for each pool 13. The Pool allocation management table 1016 represents the correspondence between page 14 and the region in the CR-VDEV11C. The Pool allocation management table 1016 has entries for each page 14. The entries have information such as page #2701, RG#2702, start address 2703, status 2704, allocation destination VDEV#2705, and allocation destination address 2706.

[0152] The page #2701 represents the identification number of page 14. The RG#2702 represents the identification number of the RAID group (in this embodiment, a RAID group composed of two or more SSD220s) that is the basis of page 14. The start address 2703 represents the start address of page 14. The status 2704 represents the status of page 14 ("1" indicates allocated, "0" indicates unallocated). The allocation destination VDEV#2705 represents the identification number of the CR-VDEV11C to which page 14 is allocated ("n / a" indicates unallocated). The allocation destination address 2706 represents the allocation destination address of page 14 (the address in the CR-VDEV11C) ("n / a" means unallocated).

[0153] Figure 24 Represents the flow of the snapshot acquisition process. According to a snapshot acquisition instruction from the management system 203 (or another system such as the server system 202), the snapshot acquisition process is executed by the snapshot acquisition program 1101. In the snapshot acquisition instruction, for example, the target PVOL10P is specified.

[0154] First, the snapshot acquisition program 1101 allocates the Dir management table 1009 that becomes the replication destination, and updates the VOL-Dir management table 1004 (S2401).

[0155] 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 # as the replication source, and sets the generation # before increment as the replication destination.

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

[0157] When the determination result in S2404 is "true" (S2404: yes), the snapshot acquisition program 1101 causes the snapshot append program 1106 to execute snapshot append processing (S2405).

[0158] When the determination result in 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 at the copy destination (S2406).

[0159] After that, the snapshot acquisition program 1101 updates the snapshot management table 1003 (S2407) and ends the process. In S2407, an entry with the PVOL#1401 representing the identification number of the target PVOL10P, the SVOL#1402 representing the identification number of the acquired snapshot (SVOL10S), and the acquisition time 1403 representing the acquisition time is added.

[0160] Figure 25 Represents the process flow of the snapshot recovery process. According to the recovery instruction from the management system 203 (or other systems such as the server system 202), the snapshot recovery program 1102 executes the snapshot recovery process. In the recovery instruction, for example, the recovery source SVOL and the recovery destination PVOL are specified.

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

[0162] 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 as the copy source and the latest generation # as the copy destination.

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

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

[0165] After that, the snapshot recovery program 1102 registers the Dir-Info# of the old Dir-Info at the recovery destination in the recovery management table 1006 (S2506), and ends the process. In S2506, the recovery request 1702 corresponding to this Dir-Info# is set to "1".

[0166] Figure 26 Shows the process of snapshot deletion processing. According to the snapshot deletion instruction from the management system 203 (or other systems such as the server system 202), the snapshot deletion process is executed by the snapshot deletion program 1103. In the recovery instruction, for example, the target SVOL is specified.

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

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

[0169] Figure 27 Shows the process of asynchronous recovery processing. The asynchronous recovery program 1104 executes the asynchronous recovery processing regularly, for example.

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

[0171] After that, the asynchronous recovery program 1104 determines whether there is an unprocessed entry (S2702). The "unprocessed entry" here refers to the entry in the recovery management table 1006 for which the recovery request 1702 is "1" and the asynchronous recovery processing is unprocessed.

[0172] When the determination result in S2702 is "true" (S2702: Yes), the asynchronous recovery program 1104 determines a processing target entry (an entry including the recovery request 1702 "1") from one or more unprocessed entries (S2703), and determines a reference destination Mapping-Info#2002 from the Dir management table 1009 corresponding to the target Dir-Info (the Dir-Info determined from Dir-Info#1701 in the processing target entry) (S2704).

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

[0174] When the determination result in S2705 is "true" (S2705: Yes), the asynchronous recovery program 1104 determines a reference destination Mapping-Info#2002 from the Dir management table 1009 corresponding to the Dir-Info in the sub-generation, and determines whether the reference destination Mapping-Info#2002 of the target Dir-Info is the same as the reference destination Mapping-Info#2002 of the Dir-Info in the sub-generation (S2706). When the determination result in S2706 is "true" (S2706: Yes), the process returns to S2702.

[0175] When the determination result in S2706 is "false" (S2706: No), or when the determination result in S2705 is "false" (S2705: No), the asynchronous recovery program 1104 determines whether the generation # of the Dir-Info in the parent generation of the target Dir-Info is earlier than the generation #2104 of the reference destination Mapping-Info of the target Dir-Info (refer to Figure 21 ). (S2707). When the determination result in S2707 is "false" (S2707: No), the process returns to S2702.

[0176] When the determination result in S2707 is "true" (S2707: Yes), the asynchronous recovery 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 (S2708). After that, the process returns to S2702. The release in S2708 is equivalent to the release of the block in the SS-VDEV.

[0177] When the determination result in S2702 is "false" (S2702: No), the asynchronous recovery program 1104 updates the recovery management table 1006 (S2709), and updates the generation management tree table 1007 (Dir-Info generation management tree 70) (S2710), and ends the process.

[0178] Figure 28 Represents the process of the write process (front end). When a write request from the server system 202 is received, the read / write program 1105 executes the write process (front end).

[0179] First, the read / write program 1105 determines whether the object data of the write request is cache hit (S2801). "Cache hit" means that a cache area corresponding to the VOL address of the write destination of the object data (the VOL address specified in the write request) has been ensured. When the determination result in S2801 is "false" (S2801: No), the read / write program 1105 ensures a cache area corresponding to the VOL address of the write destination of the object data from the cache unit 903 (S2802). After that, the process proceeds to S2806.

[0180] When the determination result in S2801 is "true" (S2801: Yes), the read / write program 1105 determines whether the cached data (the data in the ensured cache area) is dirty data (data not reflected (not written) to the pool 13) (S2803). When the determination result in S2803 is "false" (S2803: No), the process proceeds to S2806.

[0181] When the determination result in S2803 is "true" (S2803: Yes), the read / write program 1105 determines whether the WR (Write) generation # of the dirty data is the same as the generation # of the object data of the write request (S2804). The "WR generation #" is held, for example, in the management information (not shown) of the cache data. In addition, the generation # of the object data of the write request is obtained from the latest generation #403. S2804 is a process for preventing the data of the snapshot from being corrupted by updating the dirty data with the object data of the write request during the process of not performing the append process of the object data (dirty data) of the just obtained snapshot.

[0182] When the determination result in S2804 is "false" (S2804: No), the read / write program 1105 causes the snapshot append program 1106 to execute the snapshot append process (S2805).

[0183] After S2802 or when the determination result in S2804 is "true" (S2804: Yes), the read / write program 1105 writes the object data of the write request to the cache area ensured in S2802 or the cache area obtained through S2805 (S2806). After that, 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).

[0184] Figure 29 Represents the process of the write process (backend). The write process (backend) is a process of writing the unreflected data (dirty data) to the pool 13 when there is unreflected data (dirty data) in the cache unit 903. The write process (backend) is performed synchronously or asynchronously with the write process (frontend). The write process (backend) is executed by the read / write program 1105.

[0185] The read / write program 1105 determines whether there is dirty data in the cache unit 903 (S2901). When the determination result in S2901 is "true" (S2901: Yes), the read / write program 1105 causes the snapshot append program 1106 to execute the snapshot allocation determination process (S2902).

[0186] Figure 30 Represents the process of the snapshot allocation determination process. In the snapshot allocation determination process, for the area of PVOL10P that is the object of the write request from the host, it is determined whether to newly allocate an area on the SS-VDEV11S or overwrite an area already allocated on the SS-VDEV11S. The snapshot allocation determination process is executed by the snapshot allocation determination program 1113 called from the read / write program 1105.

[0187] First, the snapshot allocation determination program 1113 determines whether the generation # of the Dir-Info of the object VOL (the VOL where the data is written) is the same as the generation # of the SS-Mapping-Info before append (S3001). When the determination result in S3001 is "false" (S3001: No), the snapshot allocation determination program 1113 executes the snapshot append process (S3007).

[0188] When the determination result in S3001 is "true" (S3001: Yes), it proceeds to S3002. When the determination result in S3001 is "true", the data in the range of the write request received from the host is in a state where it is not referenced by other snapshots (hereinafter, referred to as the separate state), so by overwriting the same address on the SS-VDEV, it is possible to update the snapshot allocation management table and the SS-Mapping management table without the need.

[0189] Next, the snapshot allocation determination program 1113 obtains the transfer length of the write data requested from the host computer and determines whether this length is below a threshold value (S3002). If the transfer length is below the threshold value (S3002: Yes), it proceeds to S3003. If the transfer length is greater than the threshold value (S3002: No), it proceeds to S3006. The threshold value here is set to switch which one of overwriting without allocating a new area on the snapshot space and entering the Dedup append process, or allocating a new area on the snapshot space and uniformly updating the mapping information (snapshot append process) is more advantageous in terms of performance. The specific threshold value is set according to the actual installation of the program and performance characteristics.

[0190] Next, the snapshot allocation determination program 1113 determines whether it is possible to allocate a new area as a continuous area for the area of the write object on the SS-VDEV (S3003). Specifically, referring to the snapshot allocation management table 1008, it determines whether a continuous area in an unallocated state can be ensured. If it is determined that allocation is possible (S3003: Yes), the snapshot allocation determination program 1113 executes the snapshot append process (S3007). If it is determined that allocation is not possible (S3003: No), it proceeds to S3004.

[0191] Next, the snapshot allocation determination program 1113 determines whether it is possible to allocate a new VDEV on the SS-VDEV (S3004). If it is determined that allocation is possible (S3004: Yes), it proceeds to S3005, and a new VDEV is allocated to the SS-VDEV. Next, the snapshot allocation determination program 1113 executes the snapshot append process (S3007) and allocates a new area on the SS-VDEV. If it is determined that a new VDEV cannot be allocated (S3004: No), it proceeds to S3006 and overwriting is performed on the SS-VDEV.

[0192] When proceeding to S3006, the snapshot allocation determination program 1113 executes the Dedup append process. At this time, different from the case of the snapshot append process when proceeding to S3007, the snapshot append process is skipped and overwriting is performed on the same address on the SS-VDEV. Thereby, it is possible not to update the snapshot allocation management table and the SS-Mapping management table.

[0193] Figure 31 Represents the process flow of the snapshot append process. The snapshot append process is a process of newly allocating an area on the SS-VDEV11S for the area of the PVOL10P that is the object of the write request from the host. The snapshot append process is executed by the snapshot append program 1106 called by the snapshot acquisition program 1101 and the read / write program 1105.

[0194] The snapshot tracking program 1106 ensures a new area (block address with status 1902 being "0") in the object SS-VDEV11S (the SS-VDEV11S corresponding to the SS-Family9 that includes the object VOL (e.g., the SVOL of the acquired object or the VOL where data is written)) by updating the snapshot allocation management table 1008 (S3101). Then, the snapshot tracking program 1106 causes the Dedup tracking program 1107 to perform Dedup tracking processing (S3102).

[0195] After that, the snapshot tracking program 1106 updates the SS-Mapping management table 1010 (S3103). In S3103, for example, the snapshot tracking program 1106 sets the latest generation # (the generation # represented by the latest generation table 1005) to the generation #2104 corresponding to the Mapping-Info # of the SS-Mapping-Info of the object. The "SS-Mapping-Info of the object" here refers to the SS-Mapping-Info corresponding to the data in the object VOL.

[0196] The snapshot tracking program 1106 updates the Dir management table 1009 corresponding to the Dir-Info of the object SS-VDEV11S (S3104). In S3104, the SS-Mapping-Info related to the data written to the object (information indicating the reference destination address in the SS-VDEV) is associated with the address in the VOL10 of the data.

[0197] The snapshot tracking 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 object VOL (the VOL where data is written) is the same as the generation # of the SS-Mapping-Info before tracking (S3106).

[0198] When the determination result in S3106 is "true" (S3106: yes), it means that after data was stored in the area on the SS-VDEV pointed to by the SS-Mapping-Info before tracking, no snapshot sharing that area was generated. That is, it can be determined that the area on the SS-VDEV pointed to by the SS-Mapping-Info before tracking has become garbage. Therefore, the snapshot tracking program 1106 releases the object entry in the snapshot allocation management table 1008 (S3107) and ends the process. At this time, the mapping information to the CR-VDEV or Dedup-VDEV space corresponding to the area on the SS-VDEV pointed to by the SS-Mapping-Info before tracking remains valid. That is, the object entry in the SS-Mapping management table 1010 is not initialized.

[0199] When the determination result in S3106 is "false" (S3106: No), it means that after data is stored in the area on the SS-VDEV pointed to by the SS-Mapping-Info before backtracking, a snapshot sharing the area is generated, and the generation # of the DIR-Info is incremented. In this case, the area on the SS-VDEV before backtracking does not become garbage, so the SS-Mapping management table 1010 before backtracking remains unchanged, and the process ends.

[0200] Figure 32 Represents the process of the Dedup backtracking process. The Dedup backtracking process is executed by the Dedup backtracking program 1107 called from the snapshot backtracking program 1106.

[0201] The Dedup backtracking program 1107 determines whether there is duplicate data in the data stored in the Pool (S3201). Although not detailed in the figure, if all data is checked for the existence of data with the same content, the computational complexity becomes huge. Therefore, the following method is adopted: by performing operations using a hash function on each data, calculating representative values of the data such as hash values, and only comparing the data with the same representative values. When the determination result in S3201 is "false" (S3201: No), the Dedup backtracking program 1107 causes the compression backtracking program 1108 to execute the compression backtracking process (S3207). Thus, the compressed data of the data with the SS-VDEV11S as the storage destination is stored in the CR-VDEV11C without passing through the Dedup-VDEV11D and without changing the CPU211 of the processing entity.

[0202] When the determination result in S3201 is "true" (S3201: Yes), the Dedup backtracking program 1107 updates the Dedup allocation management table 1014 (S3202). In S3202, an entry related to the Dedup allocation information corresponding to the data with the object Dedup-VDEV11D as the storage destination is added to the Dedup allocation management table 1014.

[0203] The Dedup backtracking program 1107 updates the CR-Mapping management table 1012 (S3203). In S3203, an entry related to the CR-Mapping-Info corresponding to the data with the Dedup-VDEV11D as the storage destination is added to the CR-Mapping management table 1012.

[0204] The Dedup append program 1107 updates the directory management table 1009 (S3204) corresponding to the Dir-Info of the target Dedup-VDEV 11D. In S3204, the CR-Mapping-Info related to the duplicate data (information indicating the reference destination address in the CR-VDEV 11CC) is associated with the address in the target Dedup-VDEV 11D of this data. In this way, the usage capacity of the Pool is reduced by associating the duplicate data with the already stored data.

[0205] The Dedup append program 1107 invalidates the pre-update allocation information (S3205). In S3205, the Dedup append program 1107 updates the Dedup allocation management table 1014 and the compression allocation management table 1011. In addition, in S3205, for the areas where the number of allocation destinations in the Dedup allocation management table 1014 is zero, the garbage collection of the object entries of the compression allocation information is also performed.

[0206] Figure 33 Indicates the process flow of the compression append process. The compression append process is executed by the compression append program 1108 called from the Dedup append program 1107.

[0207] The compression append program 1108 determines whether the data length that can be compression appended is equal to or greater than the threshold value. This data length can be the data length requested by the above-mentioned Dedup append program 1107, or the data length that has already been stored in the cache memory and includes the data that is not compressed and not reflected in the drive. The threshold value is a pre-determined data length, for example, sizes such as 256 KB and 512 KB, which are assumed to be larger than the unit for managing snapshots and deduplication mappings. When performing the compression append process on the data in the cache memory, the continuous data is aggregated and processed as much as possible, so that the update process of the compression allocation management table (S3303) and the update process of the CR-Mapping management table (S3305) described later can be updated in one go, reducing the processing overhead. If the determination result in S3301 is "true" (S3301: yes), the compression append program 1108 proceeds to S3302. If the determination result in S3301 is "false" (S3301: no), the process ends. In this case, the data is temporarily stored in the cache memory in an uncompressed state. Thus, when other data is written by the host computer, the data can be continuously written in the cache memory through the snapshot append process, so that the update processing overhead of the mapping information can be reduced.

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

[0209] The compression append program 1108 causes the demotion program 1109 to execute demotion processing (S3304).

[0210] The compression append program 1108 updates the CR-Mapping management table 1012 after appending (S3305).

[0211] The compression append program 1108 updates the Dir management table 1009 (S3306).

[0212] The compression append program 1108 invalidates the pre-update allocation information (S3307). In S3307, the Dedup append program 1107 updates the Dedup allocation management table 1014 and the compression allocation management table 1011. Additionally, in S3307, for regions where the allocation destination in the Dedup allocation management table 1014 is zero, garbage collection is also performed on the object entries of the compression allocation information.

[0213] Figure 34 Shows the process of demotion processing. The demotion processing is executed by the demotion program 1109 called from the compression append program 1108.

[0214] The demotion program 1109 determines whether there is append data (one or more compressed data) of the RAID stripe amount in the cache unit 903 (S3401). A "RAID stripe" is a stripe in a RAID group (spanning the storage areas of multiple SSDs 220 that make up the RAID group). When the RAID level of the RAID group requires parity check, the size of the "append data of the RAID stripe amount" can be the size obtained by subtracting the size of the parity check from the size of the stripe. If the determination result in S3401 is "false" (S3401: No), the process ends.

[0215] If the determination result in S3401 is "true" (S3401: Yes), the demotion program 1109 refers to the Pool-Mapping management table 1015 and determines whether a page 14 has been allocated to the storage destination (the address in the CR-VDEV11C) of the append data of the RAID stripe amount (S3402). If the determination result in S3402 is "false" (S3402: No), the process proceeds to S3405.

[0216] When the determination result of S3402 is "true" (S3402: Yes), the downgrade program 1109 updates the Pool allocation management table 1016 (S3403). Specifically, the downgrade program 1109 allocates page 14. In S3403, the entries corresponding to the allocated page 14 in the Pool allocation management table 1016 (such as status 2704, allocation destination VDEV #2705, and allocation destination address 2706) are updated.

[0217] The downgrade program 1109 registers the 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).

[0218] The downgrade program 1109 writes the additional data of the RAID stripe amount to the stripe that is the basis of the page. When the RAID level is a RAID level that requires parity, the downgrade program 1109 generates parity based on the additional data of the RAID stripe amount, and the parity is also written to the stripe.

[0219] Figure 35 It is a flowchart showing the processing procedure of the read processing. According to the read request from the host device, the read / write program 1105 executes the read processing.

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

[0221] In S3502, the read / write program 1105 refers to the Dir management table 1009 and the SS-Mapping management table 1010, and based on the PVOL / snapshot internal address obtained in S3500, obtains the address on the SS-VDEV of the reference destination. At this time, when the size of the object 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.

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

[0223] 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 referring to the CR-VDEV management table 1002, the VDEV#1301 in which the CR-VDEV#2303 coincides with the CR-VDEV#1302 is determined. When the determination result in S3504 is "false" (S3504: No), the read / write program 1105 proceeds to S3506. On the other hand, when the determination result in S3504 is "true" (S3504: Yes), the read / write program 1105 obtains the address within the CR-VDEV by referring to the Dir management table 1009 and the CR-Mapping management table 1012 based on the address within the Dedup-VDEV determined in S3503 (S3505).

[0224] Next, in S3506, the read / write program 1105 decompresses the data stored at the address within the CR-VDEV determined in S3503 or S3505 and upgrades (stages) it to the cache memory.

[0225] 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). When the determination result is "true", the read / write program 1105 proceeds to S3508, transfers the data that hit the cache in S3501 or the data upgraded in S3506 to the host device, and ends the process.

[0226] On the other hand, when the result in S3507 is "false" (S3507: No), the read / write program 1105 returns to S3502 and upgrades again the data that is insufficient on the cache. Thus, when the data in the range requested by the host is stored in a continuous area on the CR-VDEV, it is possible to make the data available on the cache with only one upgrade from the drive. However, when the data is stored dispersedly on the SS-VDEV, the Dedup-VDEV, or the CR-VDEV, the reference of metadata or the upgrade operation from the drive occurs multiple times, and thus the throughput performance deteriorates.

[0227] Figure 36 Represents the process flow of the GC (Garbage Collection) process. The GC process is executed by the GC program 1110, for example, periodically (or in response to an instruction from the management system 203).

[0228] The GC program 1110 refers to the Pool-Mapping management table 1015 and the compression allocation management table 1011 to determine the pages of sub-blocks with a garbage state (status 2203 "2") (S3601). If there are no pages of sub-blocks with a garbage state, the GC process can end. Additionally, in S3601, the GC program 1110 can preferentially select the CR-VDEV11C with the fewest free areas among multiple CR-VDEV11Cs. Additionally, in S3601, the GC program 1110 can preferentially determine the pages of sub-blocks with the most garbage states in the CR-VDEV11C. Additionally, GC can also be performed in units of areas different from page 14.

[0229] The GC program 1110 determines whether there are unprocessed (not yet determined in S3603) sub-blocks in the pages determined in S3601 (S3602).

[0230] When the determination result in S3602 is "true" (S3602: yes), the GC program 1110 refers to the compression allocation management table 1011 to determine the sub-block to be processed (S3603). The GC program 1110 determines whether the corresponding status 2203 of the sub-block to be processed is "1" (allocated) (S3604). When the determination result in S3604 is "false" (S3604: no), the process returns to S3602. When the determination result in S3604 is "true" (S3604: yes), the GC program 1110 determines whether the allocation of the sub-block to be processed is also valid on the SS-VDEV (S3605). Specifically, the GC program 1110 refers to the compression allocation management table 1011 to determine the allocation destination VDEV2205 and the allocation destination Address2206 corresponding to the sub-block to be processed, thereby determining the address on the SS-VDEV where the sub-block to be processed is allocated. Then, referring to the snapshot allocation management table 1008, it is determined whether the Status1902 of the entry corresponding to the address on the SS-VDEV is 1 (allocated). When Status1902 is 1 (allocated), it is determined that the allocation of the sub-block to be processed is also valid on the SS-VDEV.

[0231] When the determination result of S3605 is "false" (S3605: No), the process returns to S3602. When the determination result of S3605 is "true" (S3605: Yes), the GC program 1110 adds the sub-block to be processed to another area (S3606). This "another area" can be a free sub-block (a sub-block with status 2203 being "0") in a CR-VDEV11C different from the CR-VDEV11C (the CR-VDEV11C having the page allocation destination of the sub-block determined in S3601) that is the object of the GC process. In addition, this "different CR-VDEV11C" can be a CR-VDEV11C in which all sub-blocks are free sub-blocks. Also, page 14 can be allocated to this "another area", and the compressed data in the sub-block to be processed can be written to this page 14 (in other words, the compressed data can be moved from the page allocated to the sub-block to be processed to the page allocated to another area).

[0232] When the determination result of S3602 is "false" (S3602: No), the GC program 1110 updates all entries of the compressed allocation management table 1011 corresponding to the CR-VDEV11C that is the object of the GC process (S3607). In step S3607, for example, the status 2203 of all entries becomes "0".

[0233] In addition, the GC program 1110 updates the Pool-Mapping management table 1015 and the Pool allocation management table 1016 (S3608). In S3806, for example, all entries of the page #2602 in the Pool-Mapping management table 1015 corresponding to the CR-VDEV11C that is the object of the GC process can be initialized, and the status 2704 corresponding to all pages allocated to the CR-VDEV11C that is the object of the GC process can be set to "0" (free).

[0234] In this way, for the GC process of this embodiment, it is only necessary to transfer the valid compressed data (the compressed data in the allocated sub-blocks) between CR-VDEV11Cs to make multiple allocated sub-blocks in a non-continuous state into a continuous state. In addition, to make multiple allocated sub-blocks in a non-continuous state into a continuous state, it can also be done without moving data between CR-VDEV11Cs.

[0235] As described above, the disclosed storage system 201 includes an SSD 220 as a storage device and a processor 211 that accesses the storage device. The processor 211 manages a main volume 10P, which is the object of read and write operations by the host, and a snapshot volume 10S generated from the main volume 10P as a snapshot family 9. The processor 211 uses a snapshot virtual device 11S, which is a logical address space corresponding to the snapshot family 9, as the storage destination for the data of the main volume 10P and the snapshot volume 10S. The data stored in the snapshot virtual device is compressed and then stored in a compressed virtual device, and the data stored in the compressed virtual device is stored in the storage device. When the processor 211 receives a write request from the host, it switches between an overwrite process of overwriting an area on the snapshot virtual device 11S where data with a large data size has been allocated and a new allocation process of allocating a new area on the snapshot virtual device 11S to the address range of the write destination according to the size of the address range of the write destination. The multiple data with a small data size stored in the new area are compressed and centrally stored in the compressed virtual device.

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

[0237] That is, in the case of random writes, the fragmented data can be concentratedly moved from the snapshot virtual device to the compressed virtual device, thereby improving the throughput performance.

[0238] In addition, continuous new areas on the snapshot virtual device are allocated to multiple data with a small data size.

[0239] Therefore, the storage of data from the snapshot virtual device to the compressed virtual device can be made efficient.

[0240] In addition, the above-mentioned processor 211 uses the snapshot allocation management table 1008 indicating the mapping from the addresses in the above-mentioned snapshot virtual device 11S to the addresses in the above-mentioned main volume and / or the above-mentioned snapshot volume to manage whether the addresses in the above-mentioned snapshot virtual device 11S are allocated to the addresses of a certain volume. When the above-mentioned processor 211 performs the above-mentioned new allocation process upon receiving the above-mentioned write request, the area of the above-mentioned snapshot virtual device 11S within the address range that has been allocated to the write destination before this new allocation process is regarded as an area where the addresses are not allocated to any volume, and the above-mentioned snapshot allocation management table 1008 is updated. When the above-mentioned processor 211 performs garbage collection processing, for the storage area of the above-mentioned compressed virtual device that is a candidate for recycling, the addresses in the above-mentioned snapshot virtual device 11S referred to by this storage area are determined, and the above-mentioned snapshot allocation management table 1008 is referred to for the determined addresses. The area where the addresses are not allocated to any volume is used as the condition for the above-mentioned recycling.

[0241] If this processing is used, there is no need to update the SS-Mapping management table 1010, etc. during writing, and the writing process can be speeded up. This is because the size of the snapshot allocation management table 1008 is small, and the update of the snapshot allocation management table 1008 ends in a shorter time compared to the update of the SS-Mapping management table 1010, etc. The SS-Mapping management table 1010 is updated when the appended write data is centrally reflected in the storage device. In addition, during garbage collection, in addition to the condition that the state 2203 of the compression allocation management table 1011 indicates "garbage collection is required", the snapshot allocation management table 1008 is also used to confirm whether the allocation on the snapshot virtual device is valid. Therefore, even if the CR-Mapping management table 1012 is not updated during writing, the object of garbage collection can be accurately determined.

[0242] In addition, the above-mentioned processor 211 performs the above-mentioned overwrite process on the condition that there is no reference from the above-mentioned snapshot volume 10S to the address range of the above-mentioned write destination, and the transfer length of the above-mentioned write destination address range on the above-mentioned snapshot virtual device 11S is above a threshold. When the transfer length is less than the threshold, the above-mentioned new allocation process is executed.

[0243] In addition, in the disclosed storage system, when multiple volumes belonging to the same snapshot family 9 have the same data, a predetermined area on the above-mentioned snapshot virtual device 11S is allocated to the above-mentioned same data, and the above-mentioned multiple volumes refer to this predetermined area.

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

[0245] In addition, in the case where multiple volumes belonging to different snapshot families 9 have the same data, a predetermined area on the deduplication virtual device 11D referred to from the above snapshot virtual device 11S is allocated to the same data.

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

[0247] In addition, the above processor 211 includes information related to the generation of the snapshot in the mapping information for managing the correspondence between the addresses in the volumes belonging to the above snapshot family 9 and the areas on the above snapshot virtual device 11S. If the generation of the address range of the write destination does not match the latest generation, the above new allocation process is performed.

[0248] Therefore, it is possible to efficiently manage whether the write destination is independent data.

[0249] Furthermore, the present invention is not limited to the above embodiments and includes various modifications. For example, the above embodiments are examples described in detail for easy understanding of the present invention and are not limited to having all the structures described. In addition, not limited to the deletion of this structure, structure replacement and addition can also be performed.

[0250] Description of Reference Numerals

[0251] 9 Snapshot family

[0252] 10P Primary volume

[0253] 10S Snapshot volume

[0254] 11C Compression append virtual device

[0255] 11D Deduplication virtual device

[0256] 11S Snapshot virtual device

[0257] 13 Pool

[0258] 70Dir-Info Generation management tree

[0259] 100 Computer system

[0260] 201 Storage system

[0261] 202 Server system

[0262] 203 Management system

[0263] 204 Storage network

[0264] 205 Management network

[0265] 210 Storage controller

[0266] 211 CPU

[0267] 212 Memory

[0268] 213 Back-end Interface

[0269] 214 Front-end Interface

[0270] 215 Management Interface

[0271] 901 Control Information Department

[0272] 902 Program Department

[0273] 903 Cache Department

Claims

1. A storage system, characterized in that: have: Storage device; as well as a processor, which accesses the storage device, The processor manages the master volume that will be the read / write target of the host and the snapshot volume generated from the master volume as a snapshot family. The processor performs the following processing: Using the logical address space corresponding to the snapshot family, namely the snapshot virtual device, as the storage destination of the data of the primary volume and the snapshot volume, compressing the data stored in the snapshot virtual device and storing it in the compressed virtual device, storing the data stored in the compressed virtual device in the storage device, When the processor receives a write request from the host, the processor switches between overwriting the area on the snapshot virtual device that has been allocated for data of large size and allocating the data of small size to a new area on the snapshot virtual device to the address range of the write destination according to the size of the address range of the write destination, and compresses multiple small-sized data stored in the new area and stores them centrally in the compressed virtual device.

2. The storage system according to claim 1, characterized in that: A continuous new area on the snapshot virtual device is allocated to the plurality of small-sized data.

3. The storage system according to claim 1, characterized in that: The processor manages whether the address in the snapshot virtual device is allocated to the address of a certain volume using a snapshot allocation management table indicating mapping from the address in the snapshot virtual device to the address in the primary volume and / or the snapshot volume, When the processor receives the write request and performs the new allocation process, the processor updates the snapshot allocation management table with the area of ​​the snapshot virtual device that has been allocated to the address range of the write destination before the new allocation process as an area of ​​the address that is not allocated to any volume. When performing garbage collection, the processor determines the address of the snapshot virtual device referenced by the storage area of ​​the compressed virtual device that is a candidate for recycling, refers to the snapshot allocation management table for the determined address, and uses the area of ​​the address that is not allocated to any volume as the condition for recycling.

4. The storage system according to claim 1, characterized in that: The processor performs the overwrite process when there is no reference from the snapshot volume to the address range of the write destination and the data length of the write request is equal to or larger than a threshold value, and performs the new allocation process when the data length is less than the threshold value.

5. The storage system according to claim 1, characterized in that: In the case where 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.

6. The storage system according to claim 1, characterized in that: In the case where a plurality of volumes belonging to different snapshot families have the same data, a predetermined area on the deduplication virtual device referenced from the snapshot virtual device is allocated to the same data.

7. The storage system according to claim 1, characterized in that: The mapping information for managing the correspondence between the address in the volume belonging to the snapshot family and the area on the snapshot virtual device includes information related to the generation of the snapshot. If the generation of the address range of the write destination does not coincide with the latest generation, the processor performs the new allocation process.

8. The storage system according to claim 3, characterized in that: When there is no reference from the snapshot volume to the address range of the write destination and the data length of the write request is greater than a threshold, the processor determines whether there is an area required for the new allocation processing on the snapshot virtual device, and performs the allocation if the required area exists; if not, performs the new allocation processing on the basis of expanding the snapshot virtual device.

9. A data processing method for a storage system, the storage system comprising a storage device and a processor for accessing the storage device, characterized in that: The processor manages the master volume that will be the read / write target of the host and the snapshot volume generated from the master volume as a snapshot family. The processor uses the logical address space corresponding to the snapshot family, namely the snapshot virtual device, as a storage destination for the data of the primary volume and the snapshot volume. The processor compresses the data stored in the snapshot virtual device and stores the compressed data in the compressed virtual device. The processor stores the data stored in the compressed virtual device in the storage device, When the processor receives a write request from the host, the processor switches between overwriting the area on the snapshot virtual device that has been allocated for data of large size and allocating the data of small size to a new area on the snapshot virtual device to the address range of the write destination according to the size of the address range of the write destination, and compresses multiple small-sized data stored in the new area and stores them centrally in the compressed virtual device.

Images