Storage system

By dynamically adjusting compression unit sizes based on SSD rewrite life, the storage system enhances data reduction rates and extends SSD lifespan by minimizing read-modify-write operations.

JP2025044512APending Publication Date: 2025-04-02HITACHI VANTARA LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2023152114
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-20
Publication Date
2025-04-02

AI Technical Summary

Technical Problem

Existing storage systems with data compression methods that increase the compression unit size beyond the write data unit require read-modify-write operations, which reduce the rewrite life of SSDs due to the limited rewrite capacity of non-volatile semiconductor devices.

Method used

A storage system that dynamically adjusts the compression unit size based on the remaining rewrite life of SSDs, using larger units when life is ample and smaller units when life is nearing expiration to minimize read-modify-write operations.

Benefits of technology

This approach improves data reduction rates and extends the lifespan of SSDs by reducing the frequency of read-modify-write operations, thereby maintaining efficient storage performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025044512000001_ABST
    Figure 2025044512000001_ABST
Patent Text Reader

Abstract

To provide a storage system capable of increasing utilization efficiency of a storage area to extend operating time of the storage device.SOLUTION: A storage system includes a controller and one or more storage devices, wherein the controller is capable of integrally compressing data of one or a plurality of continuous addresses by a compression unit of each of different compression units. The controller receives write data to determine whether or not read of data stored in the one or more storage devices is required to compress the write data by a first compression unit. If read is not necessary, the controller determines compression by the first compression unit of the write data, and if read is necessary, determines compression by the first compression unit or by a second compression unit smaller than the first compression unit on the basis of rewrite residual life of the one or more devices.SELECTED DRAWING: Figure 16
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to data compression in storage systems. [Background technology]

[0002] In recent years, the importance of technologies that create new value by storing and analyzing huge amounts of data, such as AI (Artificial Intelligence), is increasing. This requires storage systems with high I / O (Input / Output) performance to store and analyze the stored data, in addition to storing huge amounts of data.

[0003] As a storage system with high-performance I / O performance, there is an AFA (All Flash Array) equipped with an SSD (Solid State Drive) instead of an HDD (Hard Disk Drive), which has overwhelmingly high I / O performance compared to an HDD. In general, AFAs are more expensive than storage systems equipped with conventional HDDs. This is because the price per unit capacity (bit cost) of SSDs is more expensive than that of HDDs. For this reason, AFAs aim to reduce bit costs by equipping them with data reduction functions such as compression.

[0004] As a method for improving the compression rate, there is a method disclosed in Patent Document 1 in which data is compressed collectively and then read in its entirety and decompressed when it is read out. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] U.S. Patent No. 11210032 Summary of the Invention [Problem to be solved by the invention]

[0006] In Patent Document 1, data is compressed in the order in which it was written, thereby increasing the data compression unit and improving the compression rate. On the other hand, when trying to expand the compression unit in an existing storage system, it is possible to expand the compression unit in units of consecutive LBA (Logical Block Address) data. In this case, if the compression unit is larger than the write data unit from the host (host write unit), a read-modify-write is required, but Patent Document 1 does not take into account the case of read-modify-write.

[0007] This read-modify-write increases the amount of writing to the SSD installed in the storage system, which reduces the rewrite life of the SSD. This is because the non-volatile semiconductor device installed in the SSD has a limit to the number of rewrites, and once this limit is exceeded, data cannot be read or written. Therefore, if the data compression unit is increased, the rewrite life of the SSD will decrease. [Means for solving the problem]

[0008] A storage system of one embodiment of the present invention includes a controller and one or more storage devices, wherein the controller is capable of compressing data of one or more consecutive addresses collectively in each compression unit of different compression units, receives write data, determines whether it is necessary to read data stored in the one or more storage devices in order to compress the write data in a first compression unit, and if it is not necessary to read, decides to compress the write data in the first compression unit, and if it is necessary to read, decides to compress the write data in the first compression unit or in a second compression unit smaller than the first compression unit based on the remaining rewrite life of the one or more storage devices. Effect of the Invention

[0009] According to one embodiment of the present invention, it is possible to improve the data reduction rate and suppress shortening of the lifespan of a storage device having a rewrite lifespan. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of the configuration of an information system including a storage system. [Diagram 2] FIG. 2 illustrates an example of the configuration of a main memory. [Diagram 3] FIG. 4 is a diagram illustrating an example of the configuration of a program area. [Figure 4] 11 is a diagram showing a configuration example of a management information area. FIG. [Diagram 5] FIG. 13 is a diagram illustrating an example of the configuration of a PDEV management table. [Figure 6] FIG. 13 illustrates an example of the configuration of a PVOL management table. [Figure 7] FIG. 13 is a diagram illustrating an example of the configuration of an LDEV management table. [Figure 8] 13 is a diagram illustrating an example of the configuration of a PVOL page management table. [Figure 9] FIG. 13 is a diagram illustrating an example of the configuration of an LDEV page management table. [Figure 10] FIG. 13 is a diagram illustrating an example of the configuration of a buffer segment management table. [Figure 11] FIG. 13 is a diagram illustrating an example of the configuration of a cache segment management table. [Figure 12] FIG. 1 is a diagram showing the relationship between LDEVs, PVOLs, and PDEVs in a storage system. [Figure 13] FIG. 11 is a diagram showing an example of a write data flow involving RMW when a large compression unit is used in a storage system. [Figure 14] FIG. 11 is a diagram showing an example of a write data flow when a small compression unit is used in a storage system. [Figure 15] 11 is a flow diagram showing an example of a processing flow based on an I / O request from a host in a storage system. [Figure 16] FIG. 11 is a flow diagram illustrating an example of a data compression process in the storage system. [Figure 17A] 11 is a flow diagram showing an example of a process for determining a data compression unit in a storage system. [Figure 17B]FIG. 11 is a flow diagram showing another example of the process of determining the data compression unit in the storage system. [Figure 18] FIG. 11 is a flow diagram illustrating an example of a data recompression process in the storage system. [Figure 19] 13 is a flow diagram showing an example of a process for determining the lifespan of a PDEV in a storage system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment will be described with reference to the drawings. Note that the embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention.

[0012] In the following explanation, various information may be explained using the expression "xxx table", but the various information may be expressed in a data structure other than a table. To show that it does not depend on the data structure, the "xxx table" can be called "xxx information".

[0013] Furthermore, in the following description, numbers are used as identification information for elements, but other types of identification information (eg, names, identifiers) may be used.

[0014] In addition, in the following description, when describing elements of the same type without distinguishing between them, common symbols (or reference signs) may be used, and when describing elements of the same type with distinction between them, reference signs (or element IDs) may be used.

[0015] In the following description, the "main memory" may be one or more storage devices including a memory. For example, the main memory may be at least a main storage device among a main storage device (typically a volatile storage device) and an auxiliary storage device (typically a non-volatile storage device). The storage unit may include at least one of a cache area (e.g., a cache memory or a partial area thereof) and a buffer area (e.g., a buffer memory or a partial area thereof).

[0016] Furthermore, in the following explanation, "PDEV" refers to a physical storage device, and may typically be a non-volatile storage device (for example, an auxiliary storage device). The PDEV may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

[0017] In the following explanation, "RAID" is an abbreviation for Redundant Array of Independent (or Inexpensive) Disks. A RAID group is made up of multiple PDEVs, and stores data according to the RAID level associated with the RAID group.

[0018] Furthermore, in the following explanation, a "PVOL" is made up of multiple PDEVs, and these PDEVs may form a RAID group.

[0019] Furthermore, in the following explanation, an "LDEV" refers to a logical storage device, and is made up of all or part of a "PVOL", and a host executes I / O requests to an "LDEV".

[0020] Moreover, an "appendable data structure" refers to a structure in which updated data is stored in a different physical location from the data before the update, and data is updated by changing the reference destination. Since the size of compressed data varies depending on the content of the pre-compression data, in order to increase the efficiency of data reduction, it is necessary to store the compressed data without any gaps in the PVOL (i.e., the PDEV corresponding to the PVOL).

[0021] The "append-type data structure" is widely used in storage systems with data reduction functions such as compression, because compressed data can be stored from any position in the PVOL, starting from the front. In the following explanation, the storage system has an "append-type data structure", and when an "LDEV" is updated by a host write, the updated data is stored in free space in the PVOL, and the data is updated by switching the reference destination of the data in the "LDEV".

[0022] Furthermore, when processing is described below with a "program" as the subject, the program is executed by a processor (e.g., a CPU (Central Processing Unit)) included in the storage controller to perform a defined process using a storage resource (e.g., a main memory) and / or a communication interface device (e.g., an HCA) as appropriate, and therefore the subject of the process may be the storage controller or the processor. The storage controller (CTL) may also include a hardware circuit that performs all or part of the process. The computer program may be installed from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium.

[0023] Furthermore, in the following description, a "host" is a system that sends an I / O request to a storage system, and may include an interface device, a storage unit (e.g., a memory), and a processor connected thereto. A host system may be composed of one or more host computers. At least one host computer may be a physical computer, and the host system may include a virtual host computer in addition to a physical host computer.

[0024] An example of a storage system that compresses data on a logical device basis, or on a logical device basis and consecutive LBAs (Logical Block Addresses) will be described below. Note that the embodiments described below do not limit the scope of the invention, and not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

[0025] In one embodiment of this specification, two or more compression units (large and small) are used. The amount of write to the SSD is monitored, and the compression unit is selected based on the remaining rewrite life of the SSD. In one example, during the planned operating period of the SSD, it is determined whether the SSD will reach its rewrite life before reaching the planned operating period. If the result of the determination indicates that the life will not be reached, the data reduction rate is improved by compressing the data using a large compression unit (first compression unit). On the other hand, if it is determined that the life will be reached and read-modify-write is not required, the data is compressed using a large compression unit, and on the other hand, if read-modify-write is required, the data is compressed using a small compression unit (second compression unit). Note that other determination criteria may be used.

[0026] In this embodiment, monitoring of the write amount means statistical monitoring of the write amount. That is, the write amount for the SSD after the start of operation is continuously monitored to analyze the transition of the write amount. If the result of this analysis indicates that the total write amount (506 in FIG. 5) within a scheduled operating time arbitrarily determined for the SSD exceeds the maximum writable capacity (505 in FIG. 5) allowed for the SSD, the compression unit is switched and / or the recompression process is applied or not applied.

[0027] This improves the data reduction rate and reduces the bit cost of an AFA (All Flash Array). In addition, the read-modify-write that accompanies enlarging the compression unit for a write from a user with a size less than the compression unit can be reduced, in other words, data compression using a second compression unit smaller than the first compression unit can be effectively used to suppress a decrease in the life span of an SSD. Note that three or more types of compression units of different sizes may be used. An SSD is a typical example of a storage device (also called a storage drive) with a set writable (rewritable) capacity (amount of data), and other storage devices with a rewrite life span can be used instead of or together with an SSD.

[0028] 1 is a diagram showing an example of the configuration of an information system 101. The information system 101 includes one or more storage systems 102, and one or more hosts 103. The storage system 102 includes one or more CTLs (Controllers) 104, and one or more PDEV BOXes 105. In this embodiment, the storage system 102 is configured to include one CTL 104, but it may also be configured to include multiple CTLs and provide redundancy to the CTLs.

[0029] The PDEV BOX 105 includes one or more PDEVs 110. In Fig. 1, the CTL 104 and the PDEV BOX 105 are directly connected, but they may be connected via a network. The CTL 104 includes a processor 106, a main memory 107, an FE I / F (FE I / F: FrontEnd Interface) 108, and a BE I / F (BE I / F: BackEnd Interface) 109. The number of various elements constituting the CTL 104 may be one or more.

[0030] The processor 106 controls the entire CTL 104, and operates based on a microprogram stored in a main memory 107. The FE I / F 108 is controlled by the processor 106, and performs the sending and receiving of I / O requests and I / O data from the host 103. The BE I / F 109 is controlled by the processor 106, and performs the sending and receiving of data to and from the PDEV 110 via the PDEV BOX 105.

[0031] 2 is a diagram showing an example of the configuration of the main memory 107. In the main memory 107, a program area 201, a management information area 202, a buffer area 203, and a cache area 204 are secured.

[0032] The program area 201 is an area in which each program for the processor 106 to execute processing is stored. The management information area 202 is an area accessed by the processor 106, and is an area in which various management tables are stored. The buffer area 203 and the cache area 204 are areas in which data is temporarily stored during data transfer by the FE I / F 108, the BE I / F 109, etc. The buffer area 203 and the cache area 204 are made up of a plurality of segments (units of area division), and are managed in segment units.

[0033] FIG. 3 is a diagram showing an example of a program stored in the program area 201. As shown in FIG.

[0034] The program area 201 stores, for example, an I / O program 301, a segment control program 302, a data compression / decompression program 303, a PDEV control program 304, a PVOL control program 305, an LDEV control program 306, and a compression unit control program 307.

[0035] The I / O program 301 executes the corresponding processing in accordance with an I / O request from the host 103. The segment control program 302 is called when the I / O program 301 is processing an I / O request, and secures and releases buffer segments and cache segments. The data compression / decompression program 303 is called when the I / O program 301 is processing an I / O request, and compresses data received from the host 103, or decompresses compressed data.

[0036] The PDEV control program 304 manages the area and status of the PDEV 110, and controls the transmission and reception of I / O data, etc. The PVOL control program 305 controls the area and status of the PVOL. The LDEV control program 306 controls the area and status of the LDEV. The compression unit control program 307 controls the unit for compressing data, etc., based on the rewrite lifespan of the PDEV 110.

[0037] 4 is a diagram showing an example of information stored in the management information area 202. In the management information area 202, a PDEV management table 401, a PVOL management table 402, an LDEV management table 403, a PVOL page management table 404, an LDEV page management table 405, a buffer segment management table 406, and a cache segment management table 407 are stored.

[0038] The PDEV management table 401 indicates the status of the PDEV 110 and the correspondence between the PDEV 110 and the PVOL. The PVOL management table 402 indicates the status of the PVOL, the correspondence between the PVOL and the PDEV 110, and the correspondence between the PVOL and the LDEV. The LDEV management table 403 indicates the status of the LDEV, and the correspondence between the PVOL and the LDEV.

[0039] The PVOL page management table 404 is used to manage pages obtained by dividing the PVOL area into unit capacities. The LDEV page management table 405 is used to manage pages obtained by dividing the LDEV area into unit capacities. The buffer segment management table 406 is used to manage segments of the buffer area 203. The cache segment management table 407 is used to manage segments of the cache area 204.

[0040] FIG. 5 is a diagram showing an example of the configuration of the PDEV management table 401.

[0041] The PDEV management table 401 has the following columns: PDEV# 501 , capacity 502 , status 503 , associated PVOL# 504 , writable capacity 505 , total write capacity 506 , scheduled operating time 507 , and operating time 508 .

[0042] PDEV# 501 indicates the identifier of the PDEV 110. Capacity 502 indicates the capacity in which data can be stored in the PDEV 110. Status 503 indicates whether the PDEV 110 is normal or abnormal (failed or has reached the end of its rewrite life). Belonging PVOL# 504 indicates which PVOL the PDEV 110 belongs to. Writable capacity 505 indicates the capacity (amount of data) that can be written to the PDEV 110. Although it is possible to write data again to each cell that makes up an SSD by clearing written data (deleting data to make it free space), there is a physical limit to the number of times this operation can be performed.

[0043] Therefore, the value obtained by multiplying the design capacity of the SSD by the number of times this clear / write can be executed, or a similar value, is set as the writable capacity (amount of data) for the product life. Total written capacity 506 indicates the total capacity that has been written to the PDEV 110 up to now, or in other words, can be defined as the total amount of writes since the start of SSD operation. Planned operation time 507 indicates the total time that the PDEV 110 is scheduled to operate. Operation time 508 indicates the total time that the PDEV 110 has been operating.

[0044] 6 is a diagram showing an example of the configuration of the PVOL management table 402. The PVOL management table 402 has columns of PVOL# 601, used capacity / total capacity 602, rate of recompressible data 603, associated LDEV# 604, status 605, redundant configuration 606, associated PDEV 607, and PVOL page management table storage address 608.

[0045] PVOL# 601 indicates an identifier of the PVOL. Used capacity / total capacity 602 indicates the used capacity of the PVOL where data is already stored, and the total capacity including the used capacity and the capacity where data is not yet stored. Recompressible data ratio 603 indicates the ratio of data that can be recompressed to improve the data compression rate of data that is already stored in the PVOL.

[0046] The associated LDEV# 604 indicates the identifier (LDEV#) of the LDEV separated from the PVOL. The status 605 indicates whether the status of the PVOL is normal or not. The redundant configuration 606 indicates the RIAD level of the PDEV 110 that constitutes the PVOL. The associated PDEV 607 indicates the identifier (PDEV#) of the PDEV 110 that constitutes the PVOL. The PVOL page management table storage address 608 indicates the address in the main memory 107 that stores a table for managing pages obtained by dividing the PVOL into unit capacities.

[0047] 7 is a diagram showing an example of the configuration of the LDEV management table 403. The LDEV management table 403 has an LDEV#701, a capacity 702, a status 703, an associated PVOL#704, and an LDEV page management table storage address 705.

[0048] LDEV# 701 indicates the identifier of the LDEV. Capacity 702 indicates the capacity that can store data in the LDEV. Status 703 indicates whether I / O to the LDEV is possible normally. Belonging PVOL# 704 indicates the PVOL# to which the LDEV belongs. LDEV page management table storage address 705 indicates the address in the main memory 107 that stores a table for managing pages that divide the LDEV into unit capacities.

[0049] 8 is a diagram showing an example of the configuration of the PVOL page management table 404. The PVOL page management table 404 has a PVOL page #801, a status 802, a number of valid LDEV pages 803, a number of invalid LDEV pages 804, and a next write start address 805 in the PVOL page.

[0050] PVOL page #801 indicates the identifier of the PVOL page. Status 802 indicates the status of the PVOL page, where OPEN indicates that writing is in progress (a state in which data is stored halfway within the PVOL page), CLOSED indicates that writing has been completed, and FREE indicates that the page is unused.

[0051] The number of valid LDEV pages 803 indicates the number of LDEV pages allocated to a PVOL page in which valid data is stored. The number of invalid LDEV pages 804 indicates the number of LDEV pages allocated to a PVOL page in which invalid data is stored. One or more LDEV pages are allocated to one PVOL page, and in this example, multiple LDEV pages are allocated. The next write start address in PVOL page 805 indicates the start address of an unwritten area from the start of a PVOL page in a PVOL page whose status 802 is open.

[0052] 9 is a diagram showing an example of the configuration of the LDEV page management table 405. The LDEV page management table 405 has an LDEV page #901, a status 902, an allocation destination PVOL page #903, a start address in the PVOL page 904, a compression unit (number of LDEV pages) 905, a post-compression size 906, and a page #907 in the compressed data.

[0053] The LDEV page #901 indicates the identifier of the LDEV page. The status 902 indicates whether the LDEV page is assigned to a PVOL page. The assigned PVOL page #903 indicates the PVOL page # to which the LDEV page is assigned. The start address in the PVOL page 904 indicates the start address in the PVOL page where the compressed data including the LDEV page is stored.

[0054] The compression unit (number of LDEV pages) 905 indicates the compression unit used when compressing the data (the number of LDEV pages compressed together). The compressed size 906 indicates the size of the compressed data including the LDEV page. The page # in compressed data 907 indicates an identifier for identifying the LDEV page among the compressed data including the LDEV page.

[0055] 10 is a diagram showing an example of the configuration of the buffer segment management table 406. The buffer segment management table 406 has a segment #1001 and a status 0102. The segment #1001 indicates an identifier of the buffer segment. The status 1002 indicates whether the buffer segment is reserved (locked, free).

[0056] 11 is a diagram showing an example of the configuration of the cache segment management table 407. The cache segment management table 407 includes a segment #1101, a status 1102, a data type 1103, an allocation destination LDEV #1104, and an LDEV page #1105.

[0057] The segment # 1101 indicates the identifier of the cache segment. The status 1102 indicates the status of the cache segment, where clean indicates that the latest data has been stored in the PDEV, dirty indicates that the data in the cache segment is the latest, and free indicates that it is unused.

[0058] The data type 1103 indicates whether the data stored in the cache segment is compressed or uncompressed. The allocation destination LDEV# 1104 indicates the LDEV# to which the data stored in the cache segment belongs. The LDEV page# 1105 indicates the LDEV page# in the LDEV# to which the data stored in the cache segment belongs.

[0059] FIG. 12 is a diagram showing the correspondence between the above-mentioned host 103, LDEV, PVOL, PDEV 110, LDEV page, and PVOL page.

[0060] One or more LDEVs 1201 exist in the storage system 102, and provide an address space accessible from the host 103. PVOLs 1202 are a pool (address space) made up of one or more PDEVs 110. LDEVs 1201 are made up of one or more LDEV pages 1203. PVOLs 1202 are made up of one or more PVOL pages 1204. PDEVs 110 are partitioned into one or more areas 1205, and each area 1205 corresponds to one PVOL page 1204.

[0061] The host 0103 is connected to one or more LDEVs 1201 (1206). The LDEV pages 1203 are allocated to one or more PVOL pages 1204 (1207). The PVOL pages 1204 are allocated to partitioned areas 1205 of one or more PDEVs 110 (1208).

[0062] In one embodiment of this specification, a plurality of compression units of different sizes are used for write data from the host 103. An example of a write processing sequence using compression units of different sizes will be described below. First, Fig. 13 shows an example of a write processing sequence in the storage system 102, which involves read modify for compression processing using a large compression unit.

[0063] In this diagram, some of the components of the information system 101 are omitted in order to explain the data write processing sequence. Also, the write data size from the host 103 is equivalent to the LDEV page 1203, and the compression unit is shown as four LDEV pages 1203. The write data size is the unit of data written from the host 103. The write data unit, that is, the address of the LDEV page, is the LBA. Note that one LBA address may include multiple LBA pages.

[0064] In the following explanation, it is assumed that in the storage system 104, the pre-compression data for four LDEV pages 1203 included in one compressed data is mapped at fixed addresses so that the LBAs are consecutive. This makes it possible to reduce the complexity of the implementation of the address conversion program and the size of the metadata used for address conversion, compared to a case where the LBAs are non-consecutive. Note that the pre-compression data for four LDEV pages 1203 does not have to be fixed as long as the LBAs are consecutive.

[0065] The host 103 writes data 1301 to the CTL 104 (1302). The write data is stored in the cache area 204. To compress the data, the CTL 104 reads compressed data-before-update 1303 including that data from the PDEV 110 (1304). The CTL 104 stores the compressed data-before-update 1303 in the buffer area 203 and then decompresses it (1305).

[0066] The CTL 104 temporarily stores the decompressed data 1306 in the buffer area 203, and transfers (read-modify) the data except for the data 1301 to the cache area 204 (1307, 1308, 1309). The CTL 104 compresses the read-modified data 1310 (1311). The CTL 104 temporarily stores the compressed data-after-update 1312 in the cache area 204, and then transfers it to the PDEV 110 (1313). In this way, when the write data size is smaller than the compression unit, a read-modify-write occurs.

[0067] Fig. 14 shows an example of a write processing sequence in the storage system 0104 using a compression unit smaller than the compression unit shown in Fig. 13. In order to explain the data write processing sequence, some of the components of the information system 101 are omitted in Fig. 14. Also, in the write processing sequence explained with reference to Fig. 14, a case is described in which the write data size from the host 103 is equivalent to the LDEV page 1203, and the compression unit is one LDEV page 1203.

[0068] The host 103 writes (1402) data 1401 to the CTL 104. The write data is stored in the cache area 204 and compressed (1403). Thereafter, the compressed data--updated 1404 is transferred to the PDEV 110 (1405).

[0069] In this way, by compressing the write data in a compression unit selected from a plurality of compression units, read modify before updating the compressed data is unnecessary, and the amount of data written to the PDEV 110 can be reduced.

[0070] FIG. 15 is a flow diagram showing an example of the flow of processing an I / O request received by the storage system 102 from the host 103.

[0071] After receiving an I / O request from the host 103, the I / O program 301 of the CTL 104 analyzes the I / O request and clarifies the I / O type (read, write, other) etc. (1501).

[0072] The I / O program 301 uses the I / O type determined in process 1501 of analyzing the I / O request from the host to determine whether the I / O type is a write (1502). If the I / O type is a write (1503: Yes), the process proceeds to process 1504 (A). On the other hand, if the I / O type is not a write (1503: No), the process proceeds to process 1510 (B).

[0073] (A) After the segment control program 302 reserves the cache segment, the I / O program 301 receives the write data from the host 103 and registers the data in the cache (1503).

[0074] The I / O program 301 notifies the host 103 of the completion of the write (1504).

[0075] The I / O program 301 calls the data compression process to compress the data (1505).

[0076] The I / O program 301 invokes a data recompression process to improve the data compression rate in the storage system 102 (1506).

[0077] The I / O program 301 invokes a garbage collection process to eliminate fragmentation in the PVOL pages caused by the log writing, and after executing this process, ends the process (1507).

[0078] (B) The I / O program 301 executes the processing based on the I / O request and then ends the processing (1508). Since this processing is not affected by the present invention, the details of the processing will not be described here.

[0079] FIG. 16 is a flow diagram showing an example of the flow of the data compression process 1505 called from the flow diagram explained in FIG.

[0080] The data compression / decompression program 303 refers to the cache segment management table 407 and acquires the status information of the cache segment related to the write destination LDEV of the write data received from the host 103 (1601).

[0081] The data compression / decompression program 303 calls the compression unit determination process and receives the compression unit determination result (1602). In the example described below, one compression unit is selected from two different compression unit sizes. For example, the larger compression unit is four LDEV pages, and the smaller compression unit is one LDEV page. The compression unit determination process will be described in detail later.

[0082] The segment control program 302 reserves a free buffer segment and a free cache segment (1603).

[0083] The data compression / decompression program 303 determines whether or not read modify is necessary based on the results of step 1601 for acquiring cache segment information of the LDEV# and step 1602 for determining the compression unit (1604).

[0084] If all data required for compression in the determined compression unit is included in the write data, read modify is not required. If read modify is not required, the old compressed write data is discarded without being updated, and compressed data consisting of the new write data is stored in the free space of the PVOL. If the determined compression unit is a small compression unit, read modify is not required. If the determined compression unit is a large compression unit, read modify is required if some of the data to be compressed is stored in the PDEV 110, and if not, read modify is not required.

[0085] If lead modification is necessary (1604: Yes), the flow proceeds to process 1605 (A). On the other hand, if lead modification is not necessary (1604: No), the flow proceeds to process 1607 (B).

[0086] (A) The PDEV control program 304 transfers the compressed data, including the data to be read modified, from the PDEV 110 to the buffer segment secured in step 1603 (1605).

[0087] The data compression / decompression program 303 decompresses the compressed data transferred in process 1605, and transfers (1606) only the data to be compressed to the cache segment secured in process 1603. After that, the process proceeds to process 1607 (B).

[0088] (B) The data compression / decompression program 303 compresses the data on the cache segment and transfers the compressed data to the cache segment (1607). At this time, in addition to the host write data, if read modify is performed, the data to be read modified is also compressed. The compression unit uses the result of process 1602.

[0089] The PDEV control program 304 transfers the data compressed in step 1607 from the cache segment to the PDEV 110 (1608).

[0090] The LDEV control program 306 updates the information (0902 to 0907) relating to the data storage location in the LDEV page management table 405 for the LDEV page corresponding to the data transferred to the PDEV 110 in step 1608. The PDEV control program 304 also updates the PDEV management table 401 for the total write capacity 506 and operating time 508 of the PDEV 110 (1609).

[0091] The segment control program 302 releases the buffer segment secured in step 1603. It also updates the cache segment management table 407, changes the status of the cache segment corresponding to the data stored in the PDEV 110 in step 1608 to clean, and releases (1610) the other cache segments secured in step 1603. Then, the process ends.

[0092] Fig. 17A is a flow diagram showing an example of the flow of the compression unit decision process 1602 called from the flow diagram explained in Fig. 16. In the following explanation, it is assumed that one compression unit is selected from two different sizes of compression units. For example, the larger compression unit is four LDEV pages, and the smaller compression unit is one LDEV page.

[0093] The compression unit control program 307 acquires the size of the data to be compressed (1701).

[0094] The compression unit control program 307 judges (1702) whether or not read modify is required when using a large-sized compression unit, based on the information acquired in step 1701. The judgment method is the same as described above. In other words, if some of the data required for compression using a large-sized compression unit is stored in the PDEV 110, read modify is required, and if not, read modify is not required.

[0095] If lead modification is necessary (1702: Yes), the flow proceeds to process 1703 (A). On the other hand, if lead modification is not necessary (1702: No), the flow proceeds to process 1707 (C).

[0096] (A) The compression unit control program 307 refers to the LDEV management table 403 and the PVOL management table 402, and identifies the PDEV 110 belonging to the PVOL to which the destination LDEV of the data to be compressed belongs (1703). Generally, there are multiple PDEVs 110 belonging to a PVOL.

[0097] The compression unit control program 307 calls a PDEV lifespan determination process 1704. The PDEV lifespan can be known in a number of ways. As will be described later, it can also be estimated by referencing the PDEV management table 401 and from the information in the writable capacity 505, total write capacity 506, planned operation time 507 and operation time 508. Alternatively, information on the lifespan of each PDEV 110 can be obtained from that PDEV 110.

[0098] Based on the result of step 1704, the compression unit control program 307 determines whether or not each of the PDEVs 110 identified in step 1703 is expected to reach the end of its rewrite life within the expected operation time (1705).

[0099] If any of the PDEVs is expected to reach the end of its rewrite life within the planned operation time (1705: Yes), the flow proceeds to step 1706 (B). On the other hand, if none of the PDEVs is expected to reach the end of its rewrite life within the planned operation time (1705: No), the flow proceeds to step 1707 (C).

[0100] By referring to the remaining rewrite life and the preset planned operation time, it is possible to reduce the possibility that any PDEV will reach its rewrite life within the planned operation time. It is not necessary to refer to the planned operation time. For example, a determination result of whether or not the remaining rewrite life has reached a preset threshold value may be referenced. This point is similar to the determination in other steps that refer to the planned operation time and the remaining rewrite life.

[0101] (B) The compression unit control program 307 selects a small-sized compression unit and returns this to the calling process (1706). In other words, the data compression / decompression program 303 is notified that the selected compression unit is small-sized, and since a small-sized compression unit close to the size of the data to be compressed is applied, it is determined that read modify is unnecessary (1604). Then, the processing ends. This makes it possible to avoid an increase in the amount of write data due to read modify associated with the application of a large-sized compression unit when the rewrite life of the PDEV is approaching, and to reduce the possibility that the actual operating time of the PDEV 110 will be shorter than the scheduled operating time.

[0102] (C) The compression unit control program 307 selects a large-sized compression unit and returns this to the calling process (1707). In other words, the result of the selection of a large-sized compression unit is provided to the data compression / decompression program 303, which determines that read modify is necessary (1604). In this way, in an environment where the rewrite life of the PDEV is ample, the storage area of ​​the PDEV 110 can be used more efficiently by applying a large-sized compression unit. Then, the process ends.

[0103] In this embodiment, two compression units (large and small) are used, but three or more compression units may be used depending on the remaining rewrite life of the PDEV 110. For example, the sizes of the four compression units may be 1 LDEV page, 2 LDEV pages, 4 LDEV pages, and 8 LDEV pages. The size of each compression unit may be a power of two.

[0104] For example, the compression unit control program 307 determines, starting from the largest compression unit, whether any of the corresponding PDEVs 110 will reach their rewrite life within the expected operation time, and selects the largest compression unit for which none of the corresponding PDEVs 110 will reach their rewrite life within the expected operation time.

[0105] In the example shown in Fig. 17A, a determination is made as to whether or not read modify should be performed when applying a large size compression unit (1702), and then a PDEV remaining life determination is performed (1704). This determination order can be reversed. In other words, the PDEV remaining life determination may be performed first, and then a determination as to whether or not to apply read modify may be performed.

[0106] Fig. 17B shows a flowchart of the above-mentioned other example. Steps 1711 and 1712 are similar to steps 1701 and 1703 in Fig. 17A. In this processing method, after executing a PDEV life determination process (1713) and a PDEV remaining life determination (1714), a read modify application / non-application determination (1715) is executed. Depending on the determination results of the PDEV remaining life determination (1714) and the read modify application / non-application determination (1715), a small size compression unit is selected (1716) or a large size compression unit is selected (1717). The determination result and the selection of the compression unit size are similar to the processing in Fig. 17A.

[0107] Compression efficiency (how much data can be reduced) qualitatively improves the larger the compression unit. Therefore, statistically speaking, a compression unit of 32 KB has better compression efficiency than 8 KB. However, when actually looking at individual write data, the compressed results show that 32 KB compression is more efficient than 8 KB compression, but although 32 KB is expected to be better than 8 KB, it is not certain.

[0108] The processing method shown in Fig. 17A applies a large size compression unit to data for which the use of read modify is inappropriate, and applies a large size compression unit that is likely to produce a good compression result even for data for which read modify can be applied if the PDEV has a margin in terms of the remaining life. In other words, this is an approach that makes it possible to manage the remaining life while prioritizing high compression efficiency. On the other hand, the processing method shown in Fig. 17B is an approach that first determines the remaining life of the PDEV, so it prioritizes remaining life management and then appropriately manages compression efficiency.

[0109] Fig. 18 is a flow diagram showing an example of the flow of the data recompression process 1506 called from the flow diagram explained in Fig. 15. The data recompression process may be executed periodically. The data recompression process enables efficient use of the storage area while reducing the possibility of replacing the PDEV before its scheduled operation time.

[0110] The compression unit control program 307 refers to the LDEV management table 403 and starts searching for LDEVs that are the subject of data recompression, starting from the first LDEV #701 (1801).Then, the program proceeds to step 1802 (A).

[0111] (A) The compression unit control program 307 refers to the LDEV management table 403 and the PVOL management table 402, and identifies the PDEV 110 that belongs to the LDEV# 701 being processed (1802).

[0112] The compression unit control program 307 calls a PDEV lifespan determination process 1704 .

[0113] Based on the result of step 1704, the compression unit control program 307 determines (1803) whether or not each of the PDEVs 110 identified in step 1802 is expected to reach its rewrite life within the expected operation time. If any of the PDEVs is expected to reach its rewrite life within the expected operation time (1803: Yes), the flow proceeds to step 1804 (B). On the other hand, if none of the PDEVs is expected to reach its rewrite life within the expected operation time (1803: No), the flow proceeds to step 1806 (D).

[0114] (B) The compression unit control program 307 refers to the LDEV management table 403 and judges whether the LDEV#701 currently being searched for is not the final number (1804). If the LDEV#701 currently being searched for is not the final number (1804: Yes), the program proceeds to step 1805 (C). On the other hand, if the LDEV#701 currently being searched for is the final number (1804: No), the program ends the process.

[0115] (C) The compression unit control program 307 refers to the LDEV management table 403, determines the number to be searched next after the LDEV #701 currently being searched, and starts the search (1805).Then, the process proceeds to step 1802 (A).

[0116] (D) The compression unit control program 307 refers to the LDEV page management table 405 corresponding to the LDEV currently being searched for, and starts searching for LDEV pages for recompressing data, starting from the first LDEV page #901 (1806).Then, the program proceeds to step 1807 (E).

[0117] (E) The compression unit control program 307 determines whether or not the currently searched LDEV page #901 contains data that can be recompressed (1807). Note that recompressible data can be determined by whether or not it contains data compressed in a compression unit that is smaller than the maximum size of the compression unit that can be selected.

[0118] Furthermore, the determination as to whether recompression is possible is made for each number of LDEV pages in the large-size compression unit, including the LDEV page #901 being searched for. For example, if the large-size compression unit is four LDEV pages, the determination is made for each four consecutive LBA pages starting from the LDEV page #901 being searched for.

[0119] If the result of the determination is that the LDEV page contains recompressible data (1807: Yes), the flow proceeds to step 1808 (F). On the other hand, if the LDEV page does not contain recompressible data (1807: No), the flow proceeds to step 1815 (G).

[0120] (F) The segment control program 302 reserves a free buffer segment and a free cache segment (1808).

[0121] The PDEV control program 304 transfers the compressed data to be recompressed from the PDEV 110 to the buffer segment secured in process 1808 (1809).

[0122] The CTL 104 decompresses the compressed data to be recompressed and transfers it to the cache segment (1810).

[0123] The compression unit control program 307 compresses the data expanded in the process 1810 using a large size compression unit, and transfers it to the cache segment (1811).

[0124] The PDEV control program 304 transfers the data compressed in step 1811 to the PDEV 110 (1812).

[0125] The LDEV control program 306 updates the information (0902 to 0907) relating to the data storage location in the LDEV page management table 405 for the LDEV page corresponding to the data transferred to the PDEV 110 in step 1812. The PDEV control program 304 also updates the PDEV management table 401 for the total write capacity 506 and operating time 508 of the PDEV 110 (1813).

[0126] The segment control program 302 releases (1814) the buffer segment and cache segment secured in step 1808. After that, the process proceeds to step 1815 (G).

[0127] (G) The compression unit control program 307 refers to the LDEV page management table 405 corresponding to the LDEV currently being searched for, and judges whether the LDEV page in question is the last page (1815). Note that this judgment is made for each number of LDEV pages in the large-size compression unit, including the LDEV page #901 being searched for. For example, if the large-size compression unit is four LDEV pages, judgment is made for each four consecutive LBA pages starting from the LDEV page #901 being searched for. If the LDEV page being judged includes the page with the last page number (1815: Yes), proceed to step 1816 (H). On the other hand, if the LDEV page being judged does not include the page with the last page number (1815: No), proceed to step 1804 (B).

[0128] (H) The compression unit control program 307 refers to the LDEV page management table 405 corresponding to the LDEV currently being searched, determines the number to search after the LDEV page #901 currently being searched for, and starts the search (1816). The recompression process is executed for each number of LDEV pages in the large-size compression unit, including the LDEV page #901 currently being searched for. For example, if the large-size compression unit is four LDEV pages, four consecutive LBA pages starting from the LDEV page #901 currently being searched for are processed at a time. In this case, the number to search next is the number obtained by adding four to the LDEV page #901 currently being searched for. The flow then proceeds to process 1807 (E).

[0129] The recompression process described above reduces the possibility that the rewrite lifespan will be reached within the planned operation time of the PDEV while performing recompression, thereby improving the utilization efficiency of the storage area. It is not necessary to refer to the planned operation time to determine whether or not to perform recompression. For example, the result of the determination of whether or not the remaining rewrite lifespan has reached a preset threshold value may be referenced. In this way, the compressed data to be recompressed can be determined based on the remaining lifespan of the PDEV.

[0130] FIG. 19 is a flow diagram showing an example of the flow of the PDEV life determination process 1704 called from the flow diagrams described with reference to FIGS. 17A, 17B, and 18. In FIG.

[0131] The compression unit control program 307 refers to the PDEV management table 401 and calculates the expected remaining operation time of the target PDEV (the expected operation time 507 minus the operation time 508). It also refers to the writable capacity 505 and calculates the write amount per operation time (1901).

[0132] The compression unit control program 307 judges (1902) whether the PDEV is expected to exceed the writable capacity 505 during the scheduled operating time 507 (whether it is expected to reach its lifespan) based on the calculation result of step 1901. If it is expected to reach its lifespan (1902: Yes), it responds that it is expected to reach its lifespan (1903). On the other hand, if it is expected not to reach its lifespan (1903: No), it responds that it is unlikely to reach its lifespan (1904). Then, the process ends.

[0133] Although the amount of writing is used here as an index for determining the lifespan of a PDEV, other means may be used, such as an indicator value relating to the lifespan that is unique to the PDEV.

[0134] As described above, according to one embodiment of this specification, it is possible to reduce the frequency of SSD maintenance and replacement without increasing the proportion of SSDs that reach their rewrite lifespan during the operation of the storage system, and to improve the data reduction rate.

[0135] The present invention is not limited to the above-mentioned embodiment, but includes various modified examples. For example, the above-mentioned embodiment has been described in detail to clearly explain the present invention, and is not necessarily limited to those including all of the configurations described. It is also possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

[0136] In addition, the above-mentioned configurations, functions, processing units, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the program, table, file, etc. that realizes each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card or SD card.

[0137] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0138] 102 Storage System 103 Host 104 Controller 105 PDEV BOX 106 Processor 107 Main memory 110 PDEV 301 I / O program, 302 Segment Control Program 303 Data compression / decompression program 304 PDEV control program 305 PVOL control program 306 LDEV control program 307 Compression Unit Control Program 401 PDEV Management Table 402 PVOL Management Table 403 LDEV Management Table 404 PVOL page management table 405 LDEV page management table 406 Buffer segment management table 407 Cache Segment Management Table

Claims

1. 1. A storage system comprising: A controller; one or more storage devices; The controller is capable of compressing data of one or a plurality of consecutive addresses together in each of different compression units, The controller: Receives write data, determining whether it is necessary to read data stored in the one or more storage devices in order to compress the write data using a first compression unit; If the read is not required, determining to compress the write data in the first compression unit; If the read is necessary, the storage system determines whether to compress using the first compression unit or a second compression unit smaller than the first compression unit based on a remaining rewrite life of the one or more storage devices.

2. 2. The storage system according to claim 1, A storage system, wherein an address range for each of the different compression units is fixed.

3. 2. The storage system according to claim 1, A storage system, wherein the controller, when determining that any one of the one or more storage devices will reach its rewrite life within a preset planned operating time, determines to compress in the second compression unit.

4. 2. The storage system according to claim 1, The second compression unit coincides with a write unit of the write data to the storage system.

5. 2. The storage system according to claim 1, the controller determines whether or not to execute a re-compression process for the data compressed in the second compression unit and stored in the one or more storage devices based on a remaining rewrite life of the one or more storage devices; The recompression process includes: reading, from the one or more storage devices, compressed data necessary to compress the data compressed in the second compression unit in the first compression unit; the storage system decompresses the necessary compressed data that has been read, compresses it in the first compression unit, and stores it in the one or more storage devices.

6. 2. The storage system according to claim 1, the controller executes a recompression process for compressed data stored in the one or more storage devices; The recompression process includes: determining whether each storage device of the one or more storage devices will reach its rewrite life within a scheduled operating time; when it is determined that each storage device of the one or more storage devices will not reach the rewrite life within the expected operating time, determining that the data compressed in the second compression unit stored in the one or more storage devices is to be recompressed; reading, from the one or more storage devices, compressed data necessary to compress the recompression target in the first compression unit; the storage system decompresses the necessary compressed data that has been read, compresses it in the first compression unit, and stores it in the one or more storage devices.

7. A data compression method in a storage system, comprising: The storage system includes: Each compression unit of different compression units can compress data of one or more consecutive addresses together, The data compression method includes the steps of: Receives write data, determining whether it is necessary to read data stored in one or more storage devices in order to compress the write data using the first compression unit; If the read is not required, determining to compress the write data in the first compression unit; A data compression method, comprising: determining, when the read is necessary, whether to compress using the first compression unit or a second compression unit smaller than the first compression unit, based on a remaining rewrite life of the one or more storage devices.

8. 8. A data compression method according to claim 7, comprising the steps of: A method of compressing data, wherein the address range for each compression unit of the different compression units is fixed.

9. 8. A data compression method according to claim 7, comprising the steps of: A data compression method, wherein when the storage system determines that any one of the one or more storage devices will reach its rewrite life within a preset planned operating time, compression in the second compression unit is determined.

10. 8. A data compression method according to claim 7, comprising the steps of: A data compression method, wherein the second compression unit coincides with a write unit of the write data to the storage system.

11. 8. A data compression method according to claim 7, comprising the steps of: the storage system determines whether or not to execute a recompression process for the data compressed in the second compression unit and stored in the one or more storage devices based on a remaining rewrite life of the one or more storage devices; The recompression process includes: reading, from the one or more storage devices, compressed data necessary to compress the data compressed in the second compression unit in the first compression unit; the necessary compressed data that has been read is expanded, compressed in the first compression unit, and stored in the one or more storage devices.

12. 8. A data compression method according to claim 7, comprising the steps of: the storage system executes a recompression process for compressed data stored in the one or more storage devices; The recompression process includes: determining whether each storage device of the one or more storage devices will reach its rewrite life within a scheduled operating time; when it is determined that each storage device of the one or more storage devices will not reach the rewrite life within the expected operating time, determining that the data compressed in the second compression unit stored in the one or more storage devices is to be recompressed; reading, from the one or more storage devices, compressed data necessary to compress the recompression target in the first compression unit; the necessary compressed data that has been read is expanded, compressed in the first compression unit, and stored in the one or more storage devices.

Citation Information

Patent Citations

  • Storage device and data processing method

    US11210032B1