Storage Device

Abstract

To improve an I / O performance of a storage device while protecting a drive life.SOLUTION: A storage device manages data stored in storage drives, in a plurality of logical hierarchies. The plurality of logical hierarchies include a postscript layer. The storage device writes user data received through a host interface in a data-writable empty area, in the postscript layer, and selects a garbage collection operation mode of a first logic area in the postscript layer, from a plurality of operation modes including a first operation mode and a second operation mode. Execution conditions of a garbage collection of the first operation mode include a capacity of the empty area of the postscript layer being lower than a threshold, and the quantity of garbage being updated invalid data of the first logic area being greater than or equal to the threshold. The execution conditions of the garbage collection of the second operation mode include that the condition of the capacity of the empty area of the postscript layer is excepted, and the quantity of the garbage of the first logic area is greater than or equal to the threshold.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to garbage collection processing in a storage device. [Background technology]

[0002] Data reduction technologies such as data compression and deduplication have become widespread as a means of reducing the cost of storage media in storage systems. When these data reduction technologies are applied, a difference occurs between the size of data written from the host to the storage system and the size of data actually written to the storage media. Therefore, in order to effectively utilize the storage area of ​​the storage media, an append-type data storage method (e.g., Log-Structured Storage) is used in which data after data reduction is applied is written forward into free area.

[0003] In an append-type data storage method, when data is updated, the pre-update data (valid data) is no longer accessible. Data in this state is called garbage (invalid data). As the host repeatedly updates data and the storage system continues to append data, the amount of garbage increases and free space decreases. Free space is an area that does not store either valid data before the update or garbage, which is updated invalid data.

[0004] Therefore, when using an append-type data storage method, in order to delete the generated garbage, a method is adopted in which the ratio of garbage contained in a specified storage area is calculated as the invalidity rate, and garbage collection is performed when the invalidity rate exceeds a preset invalidity rate threshold. Here, garbage collection is a process in which valid data is copied to another free area, and then the specified storage area is released to make it reusable. For example, International Publication No. 2018 / 020593 is one example.

[0005] In addition, a method of performing garbage collection when the total of the used capacity and garbage amount of an SSD becomes equal to or exceeds a certain value, or when the free capacity becomes equal to or less than a certain value may be adopted. For example, Japanese Patent Application Laid-Open No. 2020-035300 is one such example. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] International Publication No. 2018 / 020593 [Patent Document 2] JP 2020-035300 A Summary of the Invention [Problem to be solved by the invention]

[0007] Garbage collection involves copying valid data recorded on a storage medium (hereafter referred to as a drive) to another free area. This copying process involves writing data to the drive, which consumes the drive's lifespan. For example, flash memory elements have a rewrite lifespan. The more the same element is rewritten, the more it deteriorates. If the upper limit on the number of rewrites is exceeded, the probability of it becoming impossible to read or write increases.

[0008] On the other hand, garbage collection processing requires the use of storage system resources (e.g. CPU bandwidth and drive bandwidth), which reduces the performance of other processes that consume storage system resources (e.g. I / O processing with external devices). Therefore, in a storage system that requires high I / O performance, it is necessary to reduce the impact that garbage collection processing has on I / O performance. [Means for solving the problem]

[0009] One aspect of the present invention is a storage device that manages data stored in a storage drive in multiple logical hierarchies, the storage device including a host interface that communicates with a host, and a processor, the multiple logical hierarchies including an appending hierarchical layer, the processor writing user data received via the host interface to a free area in the appending hierarchical layer to which data can be written, and selecting a garbage collection operation mode for a first logical area in the appending hierarchical layer from a plurality of operation modes including a first operation mode and a second operation mode, the execution conditions for garbage collection in the first operation mode including that the capacity of the free area in the appending hierarchical layer is less than a threshold and that the amount of garbage, which is updated invalid data, in the first logical area is equal to or greater than a threshold, the execution conditions for garbage collection in the second operation mode excluding the condition of the capacity of the free area in the appending hierarchical layer includes that the amount of garbage in the first logical area is equal to or greater than a threshold, and the garbage collection selects valid data before the update from the first logical area and copies it to another logical area in the appending hierarchical layer to free up the first logical area. Effect of the Invention

[0010] According to one aspect of the present invention, in a storage device, it is possible to improve I / O performance while suppressing wear on the drive lifespan. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 illustrates a hardware configuration of a storage system according to an embodiment. [Diagram 2] FIG. 1 is a diagram showing an overview of garbage collection according to drive type in an embodiment; [Diagram 3] FIG. 1 shows a logical configuration according to an embodiment. [Figure 4] FIG. 1 shows a metadata management table in one embodiment. [Diagram 5] FIG. 13 illustrates a page management table according to an embodiment. [Figure 6] FIG. 13 is a diagram showing a RAID configuration management table according to an embodiment; [Figure 7] FIG. 13 is a diagram showing a pool management table in one embodiment. [Figure 8] FIG. 1 illustrates a write process according to an embodiment. [Figure 9] FIG. 2 illustrates a garbage collection process in one embodiment. [Figure 10] FIG. 13 is a diagram showing a garbage collection execution determination process in one embodiment. [Figure 11] FIG. 13 is a diagram showing an operation mode selection screen in one embodiment. [Figure 12] FIG. 13 is a diagram showing a drive state determination process in one embodiment; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the accompanying drawings, functionally identical elements may be indicated by the same numerals. The accompanying drawings show specific embodiments and examples according to the principles of the present invention. These embodiments and examples are for understanding the present invention and should not be used to interpret the present invention in a limiting manner.

[0013] In addition, in the following description, when elements of the same type are not differentiated from one another, common reference symbols are used, and when elements of the same type are differentiated from one another, reference symbols (or the ID of the element (e.g., identification number)) may be used. For example, when multiple pages are not differentiated from one another, "page 70" may be written, and when each page is differentiated, "page 70A," "page 70B," and so on may be written. The same applies to other elements. EXAMPLES

[0014] In the first embodiment, the storage device employs an append-type data storage method. Fig. 1 is a diagram showing an overview of a storage system 100 in the first embodiment. The storage system 100 includes a storage device 11, a host computer 40 connected to the storage device 11, and a management computer 42 connected to the storage device 11.

[0015] The storage device 11 receives I / O commands from one or more host computers 40 via a first communications network 41 (for example, a SAN (Storage Area Network)). The management computer 42 and the storage device 11 can communicate with each other via a second communications network 43 (for example, a LAN (Local Area Network)).

[0016] The host computer 40 and the management computer 42 may be physical computers, or may be virtual computers executed on a physical computer. The storage device 11 has one or more storage controllers 22, and a plurality of storage drives 29 (also simply called drives) connected to the one or more storage controllers 22. In the configuration example of FIG. 1, the storage device 11 includes two storage controllers 22.

[0017] Each storage controller 22 includes a host interface (I / F) 23 that communicates with a host computer 40, a CPU 24 that controls the entire device, a memory 25 that stores programs and information used by the CPU 24, and a drive I / F 26 that communicates with physical drives 29. The number of these components is arbitrary. In the configuration example shown in Fig. 1, the multiple drives 29 are housed in a drive housing. The drives 29 are, for example, devices having non-volatile data storage media, and may be SSDs (Solid State Drives) or HDDs (Hard Disk Drives).

[0018] Fig. 2 is a diagram showing an overview of processing in an embodiment of the present specification. A plurality of drives constitute one RAID (Redundant Arrays of Inexpensive Disks) group. In the configuration example of Fig. 2, drives 29A to 29D constitute a RAID group 80A, and drives 29E to 29H constitute a RAID group 80B.

[0019] 2, drives 29A-29D are relatively low-endurance drives (QLC SSDs are shown as an example in the figure), and drives 29E-29H are relatively high-endurance drives (TLC SSDs are shown as an example in the figure). Here, durability refers to the write lifespan, and higher durability means that more writes can be performed.

[0020] A pool 60 is a logical storage area for storing data. The storage area of ​​the pool 60 is allocated in units of pages 70, which are logical storage areas. A page 70 is a logical area, and is uniquely allocated to the storage area of ​​one RAID group 80. In the following explanation, the page size is constant, but it does not have to be constant.

[0021] In the example of FIG. 2, pages including pages 70A-70D are allocated to pool 60A, and pages including pages 70E-70H are allocated to pool 60A. Also, valid data in each page is represented by a diagonal pattern, invalid data (garbage) is represented by a dot pattern, and free space is represented in white. For example, valid data and garbage are stored in page 70G. Also, page 70G includes a space (free space) where neither valid data nor garbage is stored.

[0022] 2, the flow of processing for collecting garbage contained in pools 60A and 60B will be described. The CPU 24 refers to the type of drive (if the drive 29 constitutes a RAID group 80, the drive 29 that constitutes the RAID group 80 corresponding to the pool 60) to which the storage areas of pools 60A and 60B are allocated, and judges the durability of the drive 29. Based on the result of this judgment, the garbage collection processing, which will be described later, is controlled.

[0023] Here, as a method for determining the durability of each type of drive, for example, in the case of an SSD made of NAND type flash memory, the type can be determined from the number of bits per cell. The more bits that can be stored per cell in a NAND type flash memory, the larger the capacity becomes, but the lower the durability tends to be. Examples of drive types with low durability include QLC SSD and PLC SSD. Examples of drive types with high durability include MLC SSD and TLC SSD.

[0024] As another example of a method for determining the durability of a drive, a durability index published by a manufacturer can be used. For example, DWPD (Drive Writes Per Day), which is an index indicating the amount of data that can be written per day during the drive warranty period, can be used. The CPU 24 can obtain the DWPD from each drive 29.

[0025] As in the above two methods, the durability of a drive can be determined based on the drive specifications (attributes). If the drive specifications match the predefined low durability conditions, the drive is determined to have low durability. If the drive specifications match the predefined high durability conditions, the drive is determined to have high durability. A drive that does not meet the low durability conditions may be determined to have high durability. The CPU 24 may determine the type of drive based on the drive specifications. Durability (high durability or low durability) is associated in advance with the drive type.

[0026] When the CPU 24 determines that the durability of the drive 29 corresponding to the pool 60 is low, it operates to reduce the frequency of copying valid data between pages 70 and reduce wear on the lifespan of the drive 29 by accumulating garbage as much as possible and then performing garbage collection.

[0027] 2, when the CPU 24 determines that the durability of the drives 29A-29D constituting the pool 60A is low based on the type of the drives 29A-29D (QLC SSD), it does not perform garbage collection (stops it) until the free space of the pool 60A falls below a predetermined threshold. After the free space falls below the predetermined threshold, it performs garbage collection on pages 70B that contain a predetermined amount or more of garbage among the pages 70 in the pool 60A.

[0028] On the other hand, if the CPU 24 determines that the drives 29 that make up the pool 60 are highly durable, it actively performs garbage collection without allowing garbage to accumulate, and actively reserves free space in the pool 60 in advance, thereby improving the processing performance for I / O from the host computer.

[0029] Specifically, in FIG. 2, when the CPU 24 determines that the durability of the drives 29E-29H constituting pool 60B is high based on the type of the drives 29E-29H (TLC SSD), it performs garbage collection on page 70E among the pages 70 in pool 60B that contains more than a predetermined amount of garbage, regardless of the free space in pool 60B.

[0030] The threshold value of the pool free space used as the execution criterion for garbage collection may be, for example, the free space value itself, or may be expressed as the ratio of the free space to the pool capacity. The predetermined amount (threshold value) of the garbage amount used as the execution criterion for garbage collection may also be the garbage amount value itself, or may be expressed as the ratio of the garbage amount to the page capacity.

[0031] <Logical configuration> 3 is a diagram for explaining the storage logical configuration in this embodiment. The LUN 50 is a logical drive recognized by the host computer 40, and host I / O is executed for a logical address space on the LUN 50.

[0032] The pool 60 is a logical storage area (also simply referred to as a logical area) linked to one or more LUNs 50 and one or more RAID groups 80. In this embodiment, user data stored in the LUNs 50 is compressed and / or deduplication is performed and stored in the pool 60. For example, data A, data B, and data C in the LUNs 50 are compressed, respectively, to generate data a, data b, and data c, which are stored in the pool 60. Data a is stored in page 70A, and data b and data c are stored in page 70B. Note that data reduction processing such as compression / deduplication processing may be omitted.

[0033] The pool 60 is managed by pages 70. The pages 70 are unit areas for managing the pool 60, and are associated with logical storage areas within the RAID group 80. In each page 70, compressed data is arranged front-filling. This allows data to be stored efficiently.

[0034] In both update writes and new writes by the host computer 40, the received user data is stored at the beginning of the free space in the page 70. When existing user data is updated by the host computer 40, the new user data is stored at the beginning of the free space in the page 70, and the old user data that was originally stored becomes garbage.

[0035] A page 70 is a logical storage area for storing data. The page 70 is associated with a logical storage area in a RAID group 80 configured from multiple drives 29. In the configuration example of Fig. 3, a page 70A in the pool 60 is assigned to the RAID group 80A, and a page 70B is assigned to the RAID group 80B.

[0036] The RAID group 80 is configured from a plurality of drives 29. By combining a plurality of drives 29 to configure a logical storage medium, redundancy is ensured in the event that a drive in the RAID group 80 fails. The logical storage area of ​​the RAID group 80 is linked to the physical storage area of ​​the drive 29.

[0037] As shown in FIG. 3, the storage logical configuration has a hierarchical structure, and the storage device 11 manages data in a plurality of logical hierarchies. FIG. 3 shows a hierarchical level of LUNs 50, a hierarchical level of RAID groups 80, and a hierarchical level of pools 60 between them. The hierarchical level of pools 60 is an append hierarchical level in which user data received via the host interface 23 is written to free space. Although FIG. 3 shows one LUN 50 and one pool 60, a plurality of LUNs and a plurality of pools may be defined in the storage device 11. A storage area in a hierarchical level is associated with a storage area in an adjacent hierarchical level above and / or below. Although FIG. 3 shows three logical hierarchical levels, other hierarchical levels may be defined.

[0038] <Metadata management table> 4 is a diagram for explaining the metadata management table 202 in this embodiment. The CPU 24 forms the metadata management table 202. The metadata management table 202 is managed by the CPU 24, and is stored in the drive 29, for example, and loaded into the memory 25. The metadata management table 202 is managed, for example, in units of LDEV 50. Each entry in the metadata management table 202 is a table for managing the correspondence between the logical address of user data included in each LDEV 50 and the physical address where the data is stored. The physical address may be an address within the RAID group 80, or may be an address within the pool 60.

[0039] Each column of the metadata management table 202 will be explained below.

[0040] Column 2021 records the start address of the address range within the corresponding LDEV 50 .

[0041] Column 2022 records the start address of an address range within the RAID group 80 as the storage address of user data. For ease of explanation, the address within the RAID group 80 will be referred to as a physical address for convenience. Also, an address within the pool 60 may be used as the storage address of user data instead of an address within the RAID group.

[0042] Column 2023 records the data size of the corresponding user data before compression.

[0043] Column 2024 records the data size of the corresponding user data after compression.

[0044] <Page management table> 5 is a diagram for explaining the page management table 203 in this embodiment. The CPU 24 forms the page management table 203. The page management table 203 is managed by the CPU 24, and is stored in the drive 29, for example, and loaded into the memory 25. Each entry in the page management table 203 records the correspondence between a page 70, which is a logical recording area, the ID of the RAID group 80 associated with the page 70, and the address range in the RAID group 80 corresponding to the page 70. Also, the amount of garbage contained in the page 70 and the end address (previously written address) where the last additional writing was performed in the page are recorded.

[0045] Each column of the page management table 203 will be described below. Column 2031 records an ID indicating a page 70. Column 2032 records an ID indicating the RAID group 80 to which the page 70 is assigned. Column 2033 records an address range within the RAID group 80 that corresponds to the page 70. Column 2034 records the amount of garbage contained in the page 70.

[0046] Column 2035 records the position (end address) where data was last appended within the above page 70. The appending process is executed in a front-padding manner starting from the start address of page 70. Therefore, the area after this end address is an area where no data is stored (i.e., an area where data can be written).

[0047] <RAID Configuration Management Table> FIG. 6 is a diagram for explaining the RAID configuration management table 204 in this embodiment. The RAID configuration management table 204 is managed by the CPU 24, stored in, for example, the drive 29, and loaded into the memory 25. The RAID configuration management table 204 is a data structure that records, for each RAID group 80 within the storage system, the RAID level of the RAID group 80, a list of IDs corresponding to the drives 29 belonging to the RAID group 80, the type of the drives constituting the RAID group 80, the logical capacity of the RAID group 80, and the used capacity of the RAID group 80.

[0048] Hereinafter, each column of the RAID configuration management table 204 will be described. Column 2041 records the ID of the RAID group 80 included in the storage system 100. Column 2042 records the RAID level (e.g., RAID1, RAID5, etc.) of the corresponding RAID group 80. Column 2043 records a list of drive IDs belonging to the corresponding RAID group 80.

[0049] Column 2044 records the type of the drives (e.g., HDD, QLC SSD, TLC SSD, etc.) belonging to the corresponding RAID group 80. Column 2045 records the logical capacity of the corresponding RAID group 80. Column 2046 records the used capacity of the corresponding RAID group 80. This used capacity is the sum of the sizes of the areas used to store data (e.g., user data and metadata) in the corresponding RAID group 80.

[0050] The CPU 24 acquires the RAID level from the user and stores it in column 2042. The CPU 24 may acquire the drive ID from the user and store it itself, or the CPU 24 may generate and store it. When the CPU 24 generates the drive ID, for example, the drive ID may be uniquely determined from the physical position of the drive 29. The information in the other columns is generated and stored by the CPU 24. For example, the CPU 24 determines the drive type based on specification information acquired from the drive 29 and stores it in column 2044.

[0051] <Pool management table> 7 is a diagram for explaining the pool management table 205 in this embodiment. The pool management table 205 is created and managed by the CPU 24, and is, for example, stored in the drive 29 and loaded into the memory 25. The pool management table 205 is a data structure that records, for each pool in the storage system 100, the ID of the pool 60, a list of the IDs of the RAID groups 80 corresponding to the pool 60, the logical capacity of the pool 60, the used capacity of the pool 60, and the garbage collection (GC) operation mode for the pool.

[0052] Each column of the pool management table 205 will be described below. Column 2051 records the ID of the pool 90 included in the storage system 100. Column 2052 records a list of the IDs of the RAID groups 80 that provide pages to the corresponding pool 60. One or more RAID groups are assigned to one pool. For example, the drive type of the RAID groups assigned to one pool is the same. Column 2053 records the logical capacity of the corresponding pool 60.

[0053] Column 2054 records the used capacity of the corresponding pool 60. This used capacity is the total size of the area in the pool 60 that is being used to store data (for example, user data, metadata).

[0054] Column 2055 records the GC operation mode for the corresponding pool 60. In this embodiment, there are two types of GC operation modes: "performance priority", which is a mode (second operation mode) that prioritizes I / O performance, and "life priority", which is a mode (first operation mode) that prioritizes protecting the lifespan of the drives. The CPU 24 determines the GC operation mode according to the results of judging the durability of the drives that make up the pool. If the constituent drives are judged to have low durability, the lifespan priority mode is determined for the pool. If the constituent drives are judged to have high durability, the performance priority mode is determined for the pool.

[0055] In this example, the CPU 24 determines the GC operation mode according to the type of the constituent drives. The drive types are shown in column 2044 of the RAID configuration management table 204. In this example, the lifespan priority mode is determined for the pool of QLC SSDs, and the performance priority mode is determined for the pool of TLC SSDs. In this way, in the storage device 11, the QLC SSDs are defined as low-endurance SSDs, and the TLC SSDs are defined as high-endurance SSDs.

[0056] Based on the setting of the GC operation mode, the CPU 24 switches the internal processes of the garbage collection process and the garbage collection execution determination process, which will be described later.

[0057] <Write processing> 8 is a diagram illustrating the processing flow of the write process in this embodiment. The write process is a process of receiving a write request from the host computer 40 and recording data in the storage device 11. In the write request, for example, the LUN ID and logical address of the write destination are specified by the host computer 40.

[0058] The process flow of the write process in this embodiment will be described below with reference to Fig. 8. S801: The CPU 24 receives a data write request and data from the host computer 40. S802: The CPU 24 applies compression processing to the data received from the host computer 40 to obtain compressed data. This compression processing may be performed by the CPU 24 itself, or, if the storage apparatus 11 has hardware capable of executing compression processing, the hardware may be made to execute the compression processing.

[0059] S803: The CPU 24 selects a destination page 70 for storing the compressed data. The CPU 24 refers to the page management table 203, the RAID configuration management table 204, and the pool management table 205. The size from the final append position of the page to the end of the page is set as the free space in the page, and a page 70 in which the free space in the page is larger than the size of the compressed data is selected as the data storage destination page.

[0060] S804: If the CPU 24 can select a page that satisfies the condition in step S803 as the storage destination page, the process proceeds to step S805. If there is no page that satisfies the condition, the process proceeds to step S808. S805: The CPU 24 stores the compressed data in the memory 25.

[0061] S806: The CPU 24 updates the values ​​of the page ID 2021 and the physical address 2022 corresponding to the logical address 2021 in the page, the pre-compression size information 2023, and the post-compression size information 2024 in the metadata management table 202. In addition, in the case of update write, the value of the garbage amount 2034 corresponding to the page 70 in the page management table 203 that stored the pre-update data is increased by the size of the pre-update data. In this way, the amount of garbage data is managed. In addition, the value of the previous append position 2035 is updated with the value of the append position where the current compressed data is stored.

[0062] S807: The CPU 24 returns a response to the host computer 40 indicating that the write process has been completed, and ends the process. S808: The CPU 24 returns a response to the host computer 40 indicating that the write process has failed due to a lack of free space, and ends the process.

[0063] 8, the compression process is performed before a write completion response is sent to the host computer 40, but this compression process may be performed asynchronously with the write process. For example, after the data received from the host computer 40 is stored in the memory 25, a write completion response may be sent to the host computer 40, and then the compression process may be performed asynchronously on the data in the memory 25.

[0064] <Garbage collection process> 9 is a diagram for explaining the process flow of garbage collection in this embodiment. The garbage collection process is a process in which, of the valid data and garbage contained in a target page 70, only the valid data is transferred to another page, and then the target page 70 is discarded, thereby releasing the storage area occupied by garbage and making it reusable.

[0065] The CPU 24 performs garbage collection processing on a storage area (eg, page 70) that has been determined to be a garbage collection target in a garbage collection execution determination process, which will be described later.

[0066] The CPU 24 may periodically perform garbage collection on pages 70 that it has determined are to be subject to garbage collection, or may perform the garbage collection synchronously or asynchronously with the write processing when the amount of garbage contained in the pool 60 or pages 70 increases as a result of the write processing.

[0067] Furthermore, garbage collection processing may be performed when a change is made to the logical configuration within the storage system 100. For example, garbage collection processing may be performed when the size of a LUN 50, an LDEV, a pool 60, or a RAID group 80 is changed.

[0068] Alternatively, the process may be performed when there is a change in the physical configuration within the storage system 100. For example, the process may be performed when the drives 29 are added or removed.

[0069] The process flow of the garbage collection process in this embodiment will be described below with reference to FIG.

[0070] S901: The CPU 24 refers to the page management table 203 and lists the data included in the address range from the top address of the target page to the previous additional writing position.

[0071] S902: The CPU 24 selects the top data from the data enumerated in step S1101 as the data to be processed.

[0072] S903: The CPU 24 judges whether or not any unprocessed data remains among the data enumerated in step S901. If unprocessed data remains (S903: YES), the process proceeds to step S904. If no unprocessed data remains (S903: NO), all valid data contained in the page 70 has been transferred to another page 70, and the garbage collection process is completed.

[0073] S904: The CPU 24 refers to the physical address information 2022 and logical address information in the metadata management table 202 and determines whether the target data is valid data. If a corresponding logical address exists for the physical address where the target data is located, the target data is determined to be valid data. If not, the target data is determined to be not valid data. If it is valid data (S904: YES), proceed to step S905. If it is not valid data (S904: NO), proceed to step S906.

[0074] S905: The CPU 24 copies the target data to another page 70 in the pool 60.

[0075] S906: The CPU 24 selects the next data from the data enumerated in step S1201, and proceeds to step S1203.

[0076] S907: The CPU 24 refers to the page management table 203, and rewrites the value of the garbage amount 2034 and the value of the previous additional write position 2035 in the entry corresponding to the target page 70 to their initial values.

[0077] <Garbage collection execution determination process> 10 is a diagram illustrating the process flow of the garbage collection execution determination process in this embodiment. The garbage collection execution determination process is a process for determining whether or not to execute garbage collection processing for each pool 60 in the storage system 100.

[0078] The garbage collection execution determination process may be performed periodically by the CPU 24, or may be performed synchronously or asynchronously with the write process when the amount of garbage contained in the pool 60 or page 70 increases by a certain amount due to the write process.

[0079] The garbage collection execution determination process may be executed when the logical configuration in the storage system 100 is changed. For example, the garbage collection execution determination process may be executed when the size of the LUN 50, the LDEV, the pool 60, or the RAID group 80 is changed. Alternatively, the garbage collection execution determination process may be executed when the physical configuration in the storage system 100 is changed. For example, the garbage collection execution determination process may be executed when the drive 29 is added or removed.

[0080] The process flow of the garbage collection execution determination process in this embodiment will be described below with reference to FIG.

[0081] S1001: The CPU 24 refers to the pool management table 205 and acquires the GC operation mode of the target pool 60. If the GC operation mode is "lifespan priority", the CPU 24 proceeds to S1002. If the GC operation mode is "performance priority", the CPU 24 proceeds to S1003.

[0082] In this embodiment, when the GC operation mode is "performance-oriented", GC is executed regardless of the free space in the target pool 60, and therefore when "performance-oriented", a transition is made directly to S1003.

[0083] To achieve the same operation, a transition to S1002 may be made regardless of the GC operation mode, and different pool thresholds may be used depending on the GC operation mode in S1002. For example, when the GC operation mode is "performance-oriented", a value equal to or greater than the capacity of the target pool 60 (for example, infinity) may be used as the pool threshold, resulting in a transition from S1002 to S1003 regardless of the free capacity of the target pool 60, thereby achieving the same operation.

[0084] S1002: The CPU 24 refers to the pool management table 205, acquires the pool capacity and pool usage capacity of the target pool 60, and calculates the pool free capacity from the difference between the pool capacity and the pool usage capacity. If the pool free capacity is equal to or greater than the pool threshold, the CPU 24 proceeds to S1007. If not, the CPU 24 proceeds to S1003.

[0085] Here, the pool threshold is designed based on, for example, the garbage collection processing speed (the amount of free space in the pool that can be generated per unit time by garbage collection processing) and the drive lifespan. The larger the pool threshold, the more free space in the pool will increase, and the less likely the pool will become depleted. The more free space maintained in the pool, the more processing resources can be allocated to I / O processing, but the amount of data written back by garbage collection processing increases, which can wear down the drive lifespan.

[0086] S1003: The CPU 24 refers to the page management table 203, and performs the following determination (X1) for all pages 70 corresponding to the target pool 60. (X1) The amount of garbage contained in the target page 70 is equal to or greater than the page-based garbage amount threshold. If there is one or more pages 70 for which the result of the determination (X1) is positive among the target pages 70, the CPU 24 proceeds to S1004. If not, the CPU 24 proceeds to S1006. Note that the garbage amount threshold may be set to a different value for a different operation mode.

[0087] S1004: The CPU 24 determines the amount of computational resources of the CPU 24 to be allocated to the garbage collection process. If the amount of computational resources of the CPU 24 already allocated to the garbage collection process has not reached the target value, the CPU 24 proceeds to S1005. If not, the CPU 24 proceeds to S1006.

[0088] The "amount of computational resources" is expressed, for example, as the operating rate of the CPU 24 (the ratio of the operating time of the CPU 24 to the total time). The target value of the amount of computational resources to be allocated to the garbage collection process varies according to the free capacity of the pool. This is because, in order to prevent the pool capacity from being exhausted, the smaller the free capacity, the higher the garbage collection process speed must be.

[0089] The amount of computational resources allocated to garbage collection processes may be controlled, for example, through the degree of parallelism (the number of parallel executions) of the garbage collection processes. In this case, the amount of computational resources increases in proportion to the degree of parallelism.

[0090] The "target value of the amount of computational resources" may be calculated so that the target value of the amount of computational resources is a maximum value at the lower limit of a certain range R of a pool capacity and a minimum value at the upper limit of the range R, and the target value of the amount of computational resources is linear between the upper limit and the lower limit of the range R. When the pool capacity is outside the range R, the target value of the computational resources at the closest value within the range R may be adopted.

[0091] S1005: The CPU 24 determines that the target pool 60 is a target for performing garbage collection, and ends the process.

[0092] S1006 and S1007: The CPU 24 determines that the target pool 60 is not a target for garbage collection, and ends the process.

[0093] As described above, according to the first embodiment of the present invention, it is possible to selectively use an operation that protects the drive lifespan and an operation that prioritizes I / O performance depending on the type of drive that belongs to the storage system. EXAMPLES

[0094] A second embodiment will be described below. In this regard, differences from the first embodiment will be mainly described, and explanations of points in common with the first embodiment will be omitted or simplified (the same applies to the third embodiment described below). In the first embodiment, the GC operation mode of each pool in the storage system was determined by the CPU 24 based on the type of drives that make up the pool. In the second embodiment, the GC operation mode of each pool can be set by the administrator of the storage system 100.

[0095] <Operation mode selection screen> 11 is a diagram illustrating an operation mode selection screen 1101. This screen 1101 is a screen for inputting the garbage collection operation mode from the management computer 42. On this screen 1101, the user of the management computer 42 specifies the pool ID and GC operation mode for the target pool 60.

[0096] In this embodiment, there are two types of GC operation modes: “performance priority” and “lifespan priority.” The CPU 24 records the GC operation mode for the pool ID specified by the management computer 42 via the screen 1101 in an entry in the pool management table 205.

[0097] This concludes the description of embodiment 2. According to embodiment 2, the administrator of the storage system can selectively use a storage system operation that prioritizes drive lifespan and a storage system operation that prioritizes performance based on the requirements of drive lifespan and I / O performance.

[0098] In the operation mode selection screen (see FIG. 11) of this embodiment, the GC operation mode is specified in units of pools 60, but it may also be specified in units of RAID groups. This makes it possible to set the mode from a perspective different from that of the pool. In this case, the CPU 24 may record information about the GC operation mode specified in units of drives 29 in the RAID configuration management table 204, rather than in the pool management table 205.

[0099] For example, when a GC operation mode is specified for a RAID group consisting of drives 29 with drive IDs 0 to 3, the CPU 24 may record the GC operation mode in a new column that holds the GC operation mode for the entry of that RAID group 80 (in the example of FIG. 6, the RAID group with a RAID group ID of 20). In this case, in checking the GC operation mode (S1001) in the garbage collection implementation determination process (see FIG. 10), the RAID configuration management table 204 is referenced instead of the pool management table 205, and the GC operation mode is obtained from the entry of the corresponding RAID group. EXAMPLES

[0100] A third embodiment will be described below. In the third embodiment of the present invention, an operation mode selection screen (see FIG. 11) is displayed on the management computer 42, and a GC operation mode for the pool ID is input. In this embodiment, one of "performance-oriented", "lifespan-oriented", or "balanced" is specified as the GC operation mode ("balanced" is not specified in FIG. 11). The GC operation mode "balanced" in this embodiment is an operation mode that dynamically controls the execution of garbage collection according to the lifespan of the drives that make up the pool.

[0101] <Operation mode selection screen> 11 is a diagram illustrating an operation mode selection screen 1101. This screen 1101 is a screen for inputting the garbage collection operation mode from the management computer 42. On this screen 1101, the user of the management computer 42 specifies the pool ID and GC operation mode for the target pool 60.

[0102] In this embodiment, there are three types of GC operation modes: “performance priority”, “lifespan priority”, and “balanced”. The CPU 24 records the GC operation mode for the pool ID specified by the management computer 42 via the screen 1101 in an entry in the pool management table 205.

[0103] <Drive status determination process> 12 is a diagram for explaining the process flow of the drive status determination process in this embodiment. The drive status determination process is executed by the CPU 24, and for each pool defined in the storage system, it is a process for determining a control method of the garbage collection process for that pool based on the status of the drives that constitute that pool. The drive status determination process may be executed periodically, or may be executed synchronously with the garbage collection process.

[0104] The process flow of the drive state determination process in this embodiment will be described below with reference to Fig. 12. The drive state determination process is executed in S1003 of the garbage collection execution determination process shown in Fig. 10 for a pool in the balance mode (third operation mode).

[0105] S1201: The CPU 24 refers to the pool management table 205 and the RAID configuration management table 204, and obtains list information of the drives 29 corresponding to the target pool 60.

[0106] S1202: The CPU 24 acquires monitor data inside the drive 29 for each drive 29 included in the list information of the drive 29 acquired in S1201. This monitor data is data suggesting life information of the drive 29, such as information on the total amount of data that can be written to the drive 29 and information on the total amount of data that has been written to the drive 29.

[0107] An example of the above monitor data is SMART (Self-Monitoring Analysis and Reporting Technology) information provided by an SSD.

[0108] S1203: The CPU 24 predicts the remaining life (remaining life time) of each drive 29 based on the monitor data of each drive 29 acquired in S1202. Methods for predicting the remaining life of a drive in a storage system are well known, so details will be omitted.

[0109] S1204: The CPU 24 determines a threshold value for the amount of garbage on a page-by-page basis. The threshold value for the amount of garbage on a page-by-page basis can be determined based on various factors, but in this embodiment, the following factors are used: (E1) Remaining life of the underlying drives of the target pool (E2) Write speed to the underlying drives of the target pool (E3) Write amplification rate for the "page-level garbage threshold" The values ​​for these drives can be, for example, the average values ​​of the drives assigned to the pool.

[0110] For example, the threshold for the amount of garbage per page is set as high as possible within the range that satisfies a pre-specified lifespan (for example, the expiration of the warranty period from implementation) for the remaining lifespan of the target drive based on the value (drive write speed after correction by the threshold) obtained by multiplying element (E2) by element (E3) as a coefficient. Here, the write amplification factor is an index that indicates the extent to which the amount of write data to the drive is amplified relative to the amount of write data from the host computer to the storage system. The future write amount is predicted from the write speed and write amplification factor, and the remaining lifespan of the drive is predicted based on this.

[0111] The element (E3) may be empirically determined, for example, as follows. For example, when the storage system is in operation, the amount of write data from the host computer to the LDEVs linked to each pool and the amount of write data to the drives linked to each pool are recorded, and the write amplification factor is calculated from these. From the combination of the write amplification factor obtained at this time and the "page-based garbage amount threshold" that was applied during the operation period, the write amplification factor for the "page-based garbage amount threshold" can be calculated. This may be calculated periodically, the results recorded in memory, and referenced in S1204.

[0112] The lower the "page garbage amount threshold", the more frequently garbage collection is performed, which increases the amount of write data to the drive and increases the write amplification rate. Also, instead of the page garbage amount threshold, a page garbage rate threshold may be used. The "page garbage rate" is the ratio of the size of the area occupied by garbage to the total area within one page.

[0113] The above is the process flow of the drive status determination process in this embodiment. When the CPU 24 executes the garbage collection execution determination process (see FIG. 10) for a pool whose GC operation mode is "balanced", in S1003, it refers to the garbage amount threshold set in the drive status determination process, and if there is a page whose amount is equal to or greater than the garbage amount threshold, it is set as a target for garbage collection. In S1001, the CPU 24 may make a determination about the balanced mode, for example, in the same way as the performance-oriented mode.

[0114] As a result, when the remaining lifespan of a drive is short, garbage collection processing is performed less frequently on that drive, thereby suppressing wear on that drive's lifespan. On the other hand, when the remaining lifespan of a drive is sufficiently long, garbage collection processing is actively performed on that drive to ensure a large amount of free space. As a result, when the load of I / O requests on the storage system is high, more system resources can be allocated to I / O processing, thereby improving I / O performance.

[0115] As described above, according to the third embodiment, the storage system can autonomously control the operation of garbage collection based on the drive lifespan. As a result, a storage system with high I / O performance can be realized by proactively performing garbage collection within a range where the degree of wear on the drive lifespan can be kept constant.

[0116] In the above example, the balanced mode is specified by the user. In another example, the CPU 24 may change the GC operation mode from the lifespan focused mode to the balanced mode when the predicted remaining life of the drive in the lifespan focused mode exceeds the lifespan of the specified drive and the difference exceeds a threshold value.

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

[0118] 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, or a recording medium such as an IC card or SD card.

[0119] 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]

[0120] 100 Storage Systems 11 Storage devices 22 Storage Controller 24 CPU 29 Drive 60 Pool Page 70 203 Page Management Table 204 RAID configuration management table 205 Pool Management Table 1101 Operation mode selection screen

Claims

1. A storage device that manages data stored in a storage drive in multiple logical hierarchies, comprising: a host interface for communicating with a host; a processor; The plurality of logical hierarchies includes an append hierarchy, The processor, writing user data received via the host interface to a data-writable free area in the additional layer; selecting a garbage collection operation mode for a first logic area in the appending tier from a plurality of operation modes including a first operation mode and a second operation mode; the execution conditions for garbage collection in the first operating mode include: the capacity of the free space in the appending tier being less than a threshold; the amount of garbage, which is updated invalid data in the first logic area, being equal to or greater than a threshold; and the amount of processing resources of the processor allocated to the garbage collection being less than a threshold. a condition for executing the garbage collection in the second operation mode includes that an amount of garbage in the first logic area is equal to or greater than a threshold, and an amount of processing resources of the processor allocated to the garbage collection is less than a threshold; The garbage collection selects valid data before the update from the first logical area, copies it to another logical area in the appending tier, and frees up the first logical area.

2. 2. The storage device according to claim 1, A storage device, wherein the processor selects the garbage collection operation mode according to durability determined based on a specification of a storage drive that provides the first logical area.

3. 3. The storage device according to claim 2, A storage device, wherein the processor determines durability of the storage drive that provides the first logical area based on a total amount of data that can be written to the storage drive.

4. 2. The storage device according to claim 1, The processor adjusts the threshold value of the amount of processing resources of the processor to be allocated to the garbage collection based on the amount of free space in the append tier.

5. 2. The storage device according to claim 1, The processor selects the garbage collection operation mode in response to a command from an external device.

6. 6. The storage device according to claim 5, The processor receives the designation from the external device for each of the append tiers included in the plurality of logical tiers.

7. 6. The storage device according to claim 5, The storage device, wherein the processor receives the designation from the external device for each RAID group of the storage drives.

8. 2. The storage device according to claim 1, the plurality of operation modes includes a third operation mode, and a garbage collection execution condition of the third operation mode includes an amount of garbage in the first logic area being equal to or greater than a threshold; A storage device, wherein in the third operating mode, the processor determines a threshold value for the amount of garbage in the first logical area based on a remaining life of a storage drive that provides the first logical area.

9. 9. The storage device according to claim 8, A storage device, wherein the remaining life is determined based on an amount of data already written to the storage drive and a total amount of data that can be written to the storage drive.

10. 1. A method for controlling garbage collection in a storage device, comprising: The storage device manages data stored in a storage drive in a plurality of logical hierarchies; The plurality of logical hierarchies includes an append hierarchy, The method comprises: the storage device writes the received user data to a data writable free area in the appending layer; the storage device selects a garbage collection operation mode for the first logical area in the appending tier from a plurality of operation modes including a first operation mode and a second operation mode; the execution conditions for garbage collection in the first operating mode include: a capacity of free space in the appending tier being less than a threshold; an amount of garbage, which is updated invalid data in the first logic area, being equal to or greater than a threshold; and an amount of processing resources of a processor to be allocated to the garbage collection being less than a threshold; a condition for executing the garbage collection in the second operation mode includes that an amount of garbage in the first logic area is equal to or greater than a threshold, and an amount of processing resources of the processor allocated to the garbage collection is less than a threshold; The garbage collection selects valid data before the update from the first logical area and copies it to another logical area in the append hierarchy, thereby freeing up the first logical area.

Images