JP6721765B2 - Memory system and control method - Google Patents

Description

Embodiments of the present invention relate to a technique for controlling a non-volatile memory.

In recent years, a memory system including a non-volatile memory has become widespread.

A NAND flash technology based solid state drive (SSD) is known as one of such memory systems.

SSDs are used as main storages in various computers due to their low power consumption and high performance.

International Publication No. 2012/020544

By the way, the data written in the SSD by the host may have data locality that a part of the data is frequently rewritten and the remaining part is not rewritten frequently.

Such data locality may increase the write amplification of the SSD and consequently affect the performance and life of the SSD.

The problem to be solved by the present invention is to provide a memory system and a control method capable of suppressing an increase in write amplification due to data locality.

According to an embodiment, a memory system comprises a non-volatile memory and a controller electrically connected to the non-volatile memory and configured to perform a garbage collection operation of the non-volatile memory. The controller selects a first block and a second block, each of which has a first garbage collection count, as a garbage collection target block. The first number of garbage collections indicates the number of times the data in each of the first block and the second block has been copied by a past garbage collection operation. The controller copies valid data in the first block and valid data in the second block to a third block which is a free block. The controller selects a fourth block and a fifth block, each of which has a second garbage collection count, as garbage collection target blocks. The second number of garbage collections indicates the number of times the data in each of the fourth block and the fifth block has been copied by a past garbage collection operation. The controller copies valid data in the fourth block and valid data in the fifth block to a sixth block which is a free block. When the controller invalidates a part of the data of each of the third block and the sixth block, and the first garbage collection count is the same as the second garbage collection count, The third block and the sixth block are selected as garbage collection target blocks, and the valid data in the third block and the valid data in the sixth block are converted into a seventh block which is a free block. make a copy.

3 is a block diagram illustrating a configuration example of a memory system according to an embodiment. FIG. FIG. 4 is an exemplary view for explaining a garbage collection count management operation and a garbage collection operation executed by the memory system of the same embodiment. FIG. 6 is a diagram illustrating an example of a garbage collection (GC) number management list used in the memory system of the same embodiment. FIG. 6 is a view for explaining a garbage collection target block selecting operation executed by the memory system of the embodiment based on the garbage collection count management list. FIG. 3 is a diagram illustrating a garbage collection operation executed by the memory system of the same embodiment. FIG. 3 is a diagram illustrating an example of a plurality of types of data written in the memory system of the same embodiment. The figure explaining the example of the relationship between the frequency of garbage collection and the ratio of the amount of data between multiple types of data. 6 is an exemplary flowchart illustrating a procedure of a garbage collection operation executed by the memory system of the same embodiment. FIG. 6 is a diagram illustrating a garbage collection operation including a process of merging valid data of two block groups having different garbage collection times, which is executed by the memory system of the embodiment. 5 is an exemplary flowchart illustrating a procedure of a garbage collection operation including a process of merging valid data of two block groups having different garbage collection times, which is executed by the memory system of the same embodiment. The figure explaining the operation|movement which permits a merge process only to the block group more than a specific garbage collection frequency. 6 is a flowchart illustrating a procedure of a garbage collection operation including an operation of permitting a merge process only to a block group having a specific garbage collection count or more. FIG. 6 is a view for explaining an operation of sequentially allocating free blocks for writing data from a host, which is executed by the memory system of the same embodiment. FIG. 3 is an exemplary view for explaining an example of a block use order management list used by the memory system of the same embodiment. FIG. 6 is a diagram for explaining a cumulative data write amount calculation operation executed by the memory system of the embodiment when a write to the same LBA is requested. FIG. 5 is an exemplary view for explaining a processing sequence of cumulative data write amount response processing executed by the memory system of the embodiment. 6 is an exemplary flowchart illustrating a procedure of cumulative data write amount response processing executed by the memory system of the embodiment. FIG. 8 is an exemplary view for explaining another processing sequence of the cumulative data write amount response processing executed by the memory system of the embodiment. 9 is a flowchart illustrating another procedure of cumulative data write amount response processing executed by the memory system of the embodiment. FIG. 3 is an exemplary view for explaining an example of a lookup table used in the memory system of the same embodiment. 6 is a flowchart for explaining a procedure of time lapse response processing executed by the memory system of the embodiment when a write to the same LBA is requested. 9 is an exemplary flowchart illustrating an example of a procedure of processing executed by a host based on cumulative data write amount/time lapse information received from the memory system of the embodiment. FIG. 3 is a block diagram illustrating a configuration example of a host. FIG. 3 is a diagram showing a configuration example of a computer including a memory system and a host of the same embodiment.

Hereinafter, embodiments will be described with reference to the drawings.
First, the configuration of an information processing system 1 including a memory system according to an embodiment will be described with reference to FIG.

This memory system is a semiconductor storage device configured to write data to a non-volatile memory and read data from the non-volatile memory. This memory system is realized, for example, as a solid state drive (SSD) 3 based on NAND flash technology.

The information processing system 1 includes a host (host device) 2 and an SSD 3. The host 2 is an information processing device such as a server or a personal computer.

The SSD 3 can be used as a main storage of the information processing device that functions as the host 2. The SSD 3 may be built in the information processing device, or may be connected to the information processing device via a cable or a network.

As an interface for connecting the host 2 and the SSD 3 to each other, SCSI, Serial Attached SCSI (SAS), ATA, Serial ATA (SATA), PCI Express (PCIe), Ethernet (registered trademark), Fiber channel, etc. are used. obtain.

The SSD 3 includes a controller 4, a non-volatile memory (NAND memory) 5, and a DRAM 6. The NAND memory 5 may include, but is not limited to, a plurality of NAND flash memory chips.

The NAND memory 5 includes a large number of NAND blocks (blocks) B0 to Bm-1. The blocks B0 to Bm-1 function as erase units. Blocks are sometimes referred to as "physical blocks" or "erase blocks."

The blocks B0 to Bm-1 include many pages (physical pages). That is, each of the blocks B0 to Bm-1 includes pages P0 to Pn-1. In the NAND memory 5, data read and data write are executed in page units. Data is erased in block units.

The controller 4 is electrically connected to the NAND memory 5 which is a non-volatile memory via a NAND interface 13 such as Toggle and ONFI. The controller 4 may function as a flash translation layer (FTL) configured to perform data management of the NAND memory 5 and block management of the NAND memory 5.

The data management includes (1) management of mapping information indicating a correspondence between a logical block address (LBA) and a physical address, and (2) concealment of read/write in page units and erase operation in block units. Processing, etc. are included. The management of the mapping between the LBA and the physical address is executed by using a look-up table (LUT) 33 that functions as a logical-physical address conversion table. The lookup table (LUT) 33 manages the mapping between the LBA and the physical address in a predetermined management size unit. Most of the write commands from the host 2 request writing of 4 Kbytes of data. Therefore, the lookup table (LUT) 33 may manage the mapping between the LBA and the physical address in units of 4 Kbytes, for example. The physical address corresponding to a certain LBA indicates the physical storage position in the NAND memory 5 in which the data of this LBA is written. The physical address includes a physical block address and a physical page address. Physical page addresses are assigned to all pages, and physical block addresses are assigned to all blocks.

Data can be written to the page only once per erase cycle.

Therefore, the controller 4 maps a write (overwrite) to the same LBA to another page on the NAND memory 5. That is, the controller 4 writes data to this other page. Then, the controller 4 updates the lookup table (LUT) 33 to associate this LBA with this other page and invalidates the original page (that is, the old data with which this LBA was associated).

Block management includes bad block management, wear leveling, garbage collection operation, and the like. Wear leveling is an operation for leveling the program/erase count of each physical block.

The garbage collection operation is an operation for creating a free space in the NAND memory 5. In this garbage collection operation, in order to increase the number of free blocks in the NAND memory 5, all valid data in some blocks in which valid data and invalid data are mixed are copied to another block (copy destination free block). .. Then, the garbage collection operation updates the look-up table (LUT) 33 to map each LBA of the copied valid data to the correct physical address. By copying the valid data to another block, the block regarded as the invalid data is released as a free block. This allows this block to be reused after being erased.

The host 2 sends a write command to the SSD 3. This write command includes the logical address (start logical address) of the write data (that is, the data to be written) and the transfer length. In this embodiment, LBA is used as the logical address, but in other embodiments the object ID may be used as the logical address. The LBA is represented by a serial number given to a logical sector (logical block). Serial numbers start from zero. The size of the logical sector is 512 bytes, for example.

The controller 4 of the SSD 3 writes the write data specified by the start logical address and the transfer length in the write command to the page of the block in the NAND memory 5. Further, the controller 4 updates the look-up table (LUT) 33 to map the LBA corresponding to the written data to the physical address indicating the physical storage position where the data is written.

More specifically, the controller 4 allocates one of the free blocks in the NAND memory 5 for writing data from the host 2. The allocated block is a write target block in which the data from the host 2 is to be written, and is also called a “write destination block” or an “input block”. The controller 4 sequentially writes the write data received from the host 2 to the available pages of the write target block (write destination block) while updating the lookup table (LUT) 33. When there are no available pages in the write destination block, the controller 4 allocates a new free block as the write destination block.

Next, the configuration of the controller 4 will be described.

The controller 4 includes a host interface 11, a CPU 12, a NAND interface 13, a DRAM interface 14, an SRAM 15, and the like. The CPU 12, NAND interface 13, DRAM interface 14, and SRAM 15 are interconnected via the bus 10.

The host interface 11 receives various commands (write command, read command, unmap (UNMAP) command, etc.) from the host 2.

The write command requests the SSD 3 to write the data designated by this write command. The write command includes the LBA (start LBA) of the first logical block to be written and the transfer length (the number of logical blocks). The read command requests the SSD 3 to read the data designated by this read command. The read command includes the LBA (starting LBA) of the first logical block to be read and the transfer length (the number of logical blocks).

The CPU 12 is a processor configured to control the host interface 11, the NAND interface 13, the DRAM interface 14, and the SRAM 15. The CPU 12 executes command processing for processing various commands from the host 2 and the like in addition to the above-described FTL processing.

For example, when the controller 4 receives a write command from the host 2, the controller 4 executes the following write operation under the control of the CPU 12 to write the write data designated by the write command into the NAND memory 5.

That is, the controller 4 writes the write data to the physical storage position (available page) of the current write destination block, updates the lookup table (LUT) 33, and sets the LBA (start LBA) included in the write command. The physical address of this physical storage location is mapped.

The FTL processing and the command processing may be controlled by the firmware executed by the CPU 12. This firmware causes the CPU 12 to function as a garbage collection (GC) number management unit 21, a garbage collection (GC) operation control unit 22, and an update frequency information response unit 23.

The data written to the SSD 3 by the host 2 may have data locality in which a part of the data is frequently rewritten and the remaining part is not frequently rewritten. In this case, for example, when the GC operation is executed by the normal GC algorithm of selecting some upper blocks having a large amount of invalid data as the GC target block, the update frequency increases as the GC operation is repeated many times. Data and data with low update frequency tend to be mixed in the same block. A mixture of data with a high update frequency and data with a low update frequency can be a factor that increases the write amplification of the SSD 3.

This is because, in a block in which data with a high update frequency (Hot data) and data with a low update frequency (Cold data) are mixed, only a part of the area in the block is invalidated by the update of the Hot data. On the other hand, the remaining area (Cold data) in this block is maintained in the valid state for a long time.

If the block is filled with only Hot data, all the data in this block is likely to be invalidated at a relatively fast timing by updating (rewriting) the data. Therefore, this block can be reused only by erasing it without performing a garbage collection operation.

On the other hand, if the block is filled with only Cold data, all the data in this block will remain valid for a long time. Therefore, this block is likely not to be subject to garbage collection operations for a long time.

Write amplification (WA) is defined as follows.

WA=“total amount of data written to SSD” / “total amount of data written to SSD from host”
The "total amount of data written to the SSD" corresponds to the sum of the total amount of data written to the SSD from the host and the total amount of data internally written to the SSD by a garbage collection operation or the like.

An increase in the write amplification (WA) causes an increase in the number of times of rewriting (program/erase number) of each block in the SSD 3. That is, the larger the write amplification (WA), the easier the program/erase count of the block reaches the upper limit of the program/erase count. As a result, the durability and life of the SSD 3 deteriorate.

In the present embodiment, in order to be able to separate data with a high update frequency and data with a low update frequency, a “GC function that considers the number of GC times of data in a block” and an “LBA-based update frequency notification function”. It has.

The garbage collection (GC) number management unit 21 and the garbage collection (GC) operation control unit 22 execute the "GC function in consideration of the number of GCs of data in a block". The “GC function considering the number of times of GC of data in a block” executes an improved garbage collection (GC) operation capable of suppressing an increase in write amplification of SSD3 due to data locality.

The garbage collection (GC) number management unit 21 manages the number of garbage collection (GC) for each block including the data written by the host 2. The GC count of a block indicates the number of times the data in this block has been copied by a garbage collection (GC) operation. That is, the GC count of a block indicates how many times the data in this block has been copied as valid data in the past.

For a block immediately after data is written by the host 2, that is, for a block whose data has never been collected (copied) by the GC, the GC count of this block is set to zero.

If some blocks whose GC count is zero are selected as GC target blocks (copy source blocks) and the valid data of these blocks are copied to the copy destination free block, the GC count management unit 21 Set the GC count of the first free block to 1. This is because the data in the copy destination free block is data that has been copied once from the GC target block (copy source block) as valid data.

By copying the valid data to the copy destination free block, each block regarded as invalid data (copy source block) becomes a free block. Since the free block does not contain data, it is not necessary to manage the GC count of this free block.

If some blocks (copy source blocks) having a GC count of 1 are selected as target blocks for garbage collection (GC), and valid data of these blocks are copied to a copy destination free block, the GC count management unit 21 Sets the number of GCs of this copy destination free block to 2. This is because the data in this copy destination free block is data that has been copied twice in the past as valid data.

In this way, the value of the number of GC times associated with a block indicates how many times the data in this block has been copied by the past GC operation, that is, how many times in the past the GC operation has performed on the data in this block. Indicates whether it has been executed.

The GC operation control unit 22 selects some blocks associated with the same GC count as target blocks for a garbage collection (GC) operation, and only valid data of blocks associated with the same GC count is used as the same copy destination block. Perform an improved GC operation of copying to.

For example, the GC operation control unit 22 selects some blocks as target blocks for GC from the block group associated with the same GC count (that is, a set of blocks having the same GC count). The GC operation control unit 22 copies the valid data in these blocks selected as the GC target block to the copy destination free block. Then, a value obtained by adding 1 to the GC count of these blocks selected as the GC target block is set as the GC count of this copy destination free block by the GC count management unit 21.

The “LBA-based update frequency notification function” notifies the host 2 of the write frequency to each LBA included in each write command, so that the host 2 can efficiently separate Hot data/Cold data. This is a function to assist.

The “LBA-based update frequency notification function” is executed by the update frequency information response unit 23.

When the update frequency information response unit 23 receives a write command including an LBA from the host 2, the update frequency information response unit 23 receives a value regarding the time elapsed from the last write to this LBA to the current write to this LBA, or the previous time to this LBA. The accumulated data write amount from the write to the LBA to the present write is notified to the host 2 as a response to the write command. This allows the host 2 to be notified of the actual update frequency (rewriting frequency) of the user data, so that the host 2 updates the user data with a plurality of types of data having different update frequencies, for example, frequently. The data can be categorized into data of a type (Hot data), data of a low update frequency (Cold data), and data of a type having an update frequency intermediate between Hot data and Cold data (Warm data). As a result, for example, the host 2 can execute processing for distributing these different types of data to different SSDs, if necessary.

Next, other components in the controller 4 will be described.

The NAND interface 13 is a NAND controller configured to control the NAND memory 5 under the control of the CPU 12.

The DRAM interface 14 is a DRAM controller configured to control the DRAM 6 under the control of the CPU 12.

A part of the storage area of the DRAM 6 may be used as a write buffer (WB) 31 for temporarily storing data to be written in the NAND memory 5. Further, the storage area of the DRAM 6 may be used as the GC buffer 32 for temporarily storing the data moved during the garbage collection (GC) operation. Further, the storage area of the DRAM 6 may be used for storing the above-mentioned lookup table 33.

Further, the storage area of the DRAM 6 may be used as the GC count management list 34 and the block use order management list 35.

The GC count management list 34 is a list for holding the GC count for each block including data written by the host 2. The GC count management list 34 may be a table showing the correspondence between the block IDs (for example, physical block addresses) of the blocks and the GC counts of the data in these blocks.

Alternatively, the GC count management list 34 may be composed of a plurality of GC count lists for managing each block for each GC count (for example, GC count=0 to GC count=n). Here, n is the upper limit of the number of times of GC to be managed. For example, the GC count list with the GC count=0 holds a list of block IDs (eg, physical block addresses) of the blocks associated with the GC count of 0 times. The GC count list with the GC count=1 holds a list of block IDs (eg, physical block addresses) of the blocks associated with one GC count.

The block usage order management list 35 holds allocation numbers (sequential numbers) assigned to the blocks allocated for the write destination blocks. That is, the controller 4 gives a number (allocation number) indicating the allocation order to each block allocated as the write target block. The number may be a sequential number starting at 1. For example, the block first assigned to the write destination block is assigned the assignment number=1, the second block assigned to the write destination block is assigned the assignment number=2, and the third write destination block is assigned. An allocation number=3 is given to the block allocated for the block. As a result, it is possible to manage the block use history indicating which block is assigned as the write destination block and in what order. As the allocation number, the value of the counter that is incremented each time a new free block is allocated for the write destination block can be used.

The SSD 3 may also hold various other management information. An example of such management information may include a page management table holding valid/invalid flags corresponding to respective physical addresses. Each valid/invalid flag indicates whether the corresponding physical address (physical page) is valid or invalid. The physical page being valid means that the data in the physical page is valid data. The invalid physical page means that the data in the physical page is invalidated by updating (rewriting).

Next, the configuration of the host 2 will be described.

The host 2 is an information processing device that executes various programs. The programs executed by the information processing device include an application software layer 41, an operating system (OS) 42, and a file system 43.

As is generally known, an operating system (OS) 42 manages the entire host 2, controls hardware in the host 2, and controls for allowing an application to use the hardware and the SSD 3. Is software configured to perform.

The file system 43 is used to perform control for file operations (creating, saving, updating, deleting, etc.). For example, ZFS, Btrfs, XFS, ext4, NTFS, etc. may be used as the file system 43. Alternatively, a file object system (for example, Ceph Object Storage Daemon) or a Key Value Store System (for example, Rocks DB) may be used as the file system 43.

Various application software threads run on the application software layer 41. Examples of application software threads include client software, database software, virtual machines and the like.

When the application software layer 41 needs to send a request such as a read command or a write command to the SSD 3, the application software layer 41 sends the request to the OS 42. The OS 42 sends the request to the file system 43. The file system 43 translates the request into a command (read command, write command, etc.). The file system 43 sends the command to the SSD 3. When the response from the SSD 3 is received, the file system 43 sends the response to the OS 42. The OS 42 sends the response to the application software layer 41.

Next, with reference to FIGS. 2 to 12, details of the “GC function considering the number of times of GC of data in a block” will be described.

FIG. 2 shows the GC count management operation and the GC operation executed by the SSD 3.

The controller 4 of the SSD 3 allocates a certain free block as a block (write destination block) for writing data (write data) from the host 2, and the write data received from the host 2 can be used in this write destination block. Write to pages sequentially. When all pages of the current write destination block are filled with data, the controller 4 manages the current write destination block as an active block (block containing data). Further, the controller 4 allocates another free block as a new write destination block. In this way, in the SSD 3, the data (write data) received from the host 2 is sequentially written in the order of arrival from the first page to the last page of the current write destination block.

The blocks B11 to B17 in FIG. 2 are blocks immediately after the data is written by the host 2, that is, the data in the block has never been copied by the garbage collection (GC) operation. The number of GCs corresponding to these blocks B11 to B17 is 0.

Over time, some of the data in each of blocks B11-B17 may be invalidated by the rewriting. As a result, valid data and invalid data may be mixed in each of the blocks B11 to B17.

When the number of free blocks falls below the threshold number, the controller 4 starts the GC operation of creating free blocks from some blocks in which valid data and invalid data are mixed.

The controller 4 first selects some blocks in which valid data and invalid data are mixed as GC target blocks. In the selection of the GC target block, the controller 4 selects the block group associated with the same GC number of times as the GC target block, as described above. This block group may be, for example, a block group to which a block having the largest amount of invalid data belongs, that is, a set of blocks having the same GC count as the GC count of the block having the largest invalid data amount. In this case, the controller 4 may first select the block having the largest invalid data amount from the blocks including the data written by the host 2. Next, the controller 4 sets the block having the largest invalid data amount and one or more blocks associated with the same GC number as the GC number of the block having the largest invalid data amount as the target blocks of the garbage collection (GC) operation. May be selected as

The controller 4 copies valid data in some selected GC target blocks (several blocks associated with the same GC count) to a copy destination free block, and adds 1 to the GC counts of these GC target blocks. The value is set as the GC count of the copy destination free block. As a result, the value obtained by adding 1 to the GC count of the GC target block is carried over to the copy-destination free block. Therefore, the GC count of the copy-destination free block depends on how many times the data in the copy-destination free block was past by the GC operation. It can correctly represent whether it has been copied.

For example, if two blocks B11 and B12 associated with the same number of GCs are selected as GC target blocks and the valid data of these blocks B11 and B12 are copied to the copy destination free block B21, this copy destination free block B21. Is set to a value (here, 1) obtained by adding 1 to the number of GCs (here, 0) of the blocks B11 and B12.

Similarly, if three blocks B13, B14, B15 associated with the same number of GCs are selected as GC target blocks and valid data of these blocks B13, B14, B15 are copied to the copy destination free block B22, The number of GCs of the copy destination free block B22 is set to a value (here, 1) obtained by adding 1 to the number of GCs of the blocks B13, B14, and B15 (here, 0).

Similarly, if two blocks B16 and B17 associated with the same number of GCs are selected as GC target blocks and the valid data of these blocks B16 and B17 are copied to the copy destination free block B23, this copy destination free block. The GC number of B23 is set to a value (here, 1) obtained by adding 1 to the GC number of blocks B16 and B17 (here, 0).

Over time, some of the data in each of the blocks B21, B22, and B23 may be invalidated by the rewriting. As a result, valid data and invalid data may be mixed in each of the blocks B21, B22, and B23.

If two blocks B21 and B22 associated with the same GC count are selected as GC target blocks and the valid data of these blocks B21 and B22 are copied to the copy destination free block B31, the GC of this copy destination free block B31 is selected. The number of times is set to a value (here, 2) obtained by adding 1 to the number of GC times (here, 1) of the blocks B21 and B22.

As described above, in the present embodiment, the number of GCs managed for each block indicates the number of times the data in the block has been copied by the past GC operation. In order to manage this GC count correctly, the value obtained by adding 1 to the GC count of the GC target block is carried over to the data in the copy destination free block.

FIG. 3 shows an example of the GC count management list 34.

When the upper limit value n of the number of GCs to be managed is 10, for example, the GC number management list 34 may be composed of eleven GC number lists corresponding to GC number=0 to GC number=10, respectively.

The GC count list of GC count=0 indicates a list of block IDs (eg, physical block addresses) of the blocks associated with the GC count=0. The GC count list with the GC count=1 indicates a list of block IDs (eg, physical block addresses) of the blocks associated with the GC count=1. Similarly, the GC count list with the GC count=10 shows a list of block IDs (for example, physical block addresses) of the blocks associated with the GC count=10. Each GC count list may include, but is not limited to, only blocks in which valid data and invalid data are mixed.

FIG. 4 shows a GC target block selection operation executed by the controller 4.

In the process of selecting the GC target block, the garbage collection operation control unit 22 of the controller 4 first selects the GC target block group from the plurality of block groups (the plurality of GC frequency lists) associated with different GC frequencies. May be selected. In FIG. 4, the block group with the number of GC=5 (block B2, block B5, block B11, block B21) is selected as the block group of the GC target, and further, some GCs are selected from the block group with the number of GC=5. The case where the target block is selected is illustrated.

In the process of selecting the GC target block, for example, first, a block that matches a predetermined condition may be selected as the first GC candidate. The block that meets the predetermined condition may be the block having the largest invalid data amount among the active blocks (the block including the data written by the host 2). In another embodiment, the block that meets the predetermined condition may be the oldest block among the active blocks. In the following, it is assumed that the block with the largest amount of invalid data is selected as the first GC candidate.

If the block having the largest amount of invalid data is the block B5, the controller 4 specifies the GC number list including the block B5 (here, the GC number list of GC number=5), and the GC number of GC=5. A block group (block B2, block B5, block B11, block B21) indicated by the number of times list is selected as a GC target block group, and some GC target blocks are selected from this GC target block group. For example, among these blocks B2, block B5, block B11, and block B21, some upper blocks having a large invalid data amount may be selected as the GC target block. In this case, for example, the block B5 and one or more upper blocks having the largest invalid data amount in the block B2, the block B11, and the block B21 may be selected as the GC target block.

FIG. 5 shows the GC operation performed by the controller 4.

The controller 4 manages a free block pool (free block list) 60 including all free blocks. The controller 4 selects one free block from these free blocks. The controller 4 allocates the selected free block as the copy destination free block B1000. The controller 4 copies all valid data from the GC target block (here, blocks B2, B5, and B11) having the same number of GCs to the copy destination free block B1000. Then, the controller 4 updates the lookup table 33 to map each LBA of valid data to each physical address of the copy destination free block B1000.

The GC count of the copy destination free block B1000 is set to the GC count (=5)+1 of the blocks B2, B5, and B11. The block B1000 is added to the GC count list with the GC count=6. The blocks B2, B5, and B11 are free blocks that do not include valid data. The blocks B2, B5, and B11 that have become free blocks are discarded from the GC count list of GC count=5.

FIG. 6 shows an example of plural kinds of data written in the SSD 3.

In FIG. 6, it is assumed that three types of data (data A, data B, data C) having different update frequencies are written to the SSD 3. The data storage area (LBA space) of the SSD 3 includes three spaces corresponding to the LBA groups A, B, and C.

The data A written in the LBA group A is data with a low update frequency, and the amount of the data A is the largest among the data A, B, and C. That is, LBA group A has the largest LBA range.

The data C written in the LBA group C is data with a high update frequency, and the amount of the data C is the smallest among the data A, B, and C. That is, LBA group C has the smallest LBA range.

The data B written in the LBA group B is data having an update frequency intermediate between the data A and the data C, and the amount of the data B is between the amount of the data A and the amount of the data C.

The ratio of the amount of data A to the total user capacity of the SSD 3 may be 50%, for example. The ratio of the amount of data B to the total user capacity of the SSD 3 may be 30%, for example. The ratio of the amount of data C to the total user capacity of the SSD 3 may be 20%, for example.

The update frequency of the data A, that is, the write frequency to the LBA group A may be 20%, for example. The update frequency of the data B, that is, the write frequency to the LBA group B may be 30%, for example. The update frequency of the data C, that is, the write frequency to the LBA group C may be 50%, for example.

In this case, for example, after the SSD 3 is filled with the data A, the data B, and the data C, a write command requesting a write to the data C (LBA group C) is issued once every two write commands. A write command is issued from the host 2 to the SSD 3, and once every 5 write commands, a write command requesting a write to the data A (LBA group A) is issued from the host 2 to the SSD 3. For example, the data C is updated at a high frequency of once (50%) for every two write commands.

When the data written in the SSD 3 has data locality as shown in FIG. 6, as shown in the lower part of FIG. 6, data A, data B, and data C are mixed in each write destination block.

In one write destination block, the ratio of the amount of data C to the capacity of the block is 50%, the ratio of the amount of data B to the capacity of the block is 30%, and the ratio of the amount of data A to the capacity of the block is 20%. ..

As described above, the amount of the data C is smaller than that of the data A and the data B, and the update frequency of the data C is higher than that of the data A and the data B. Therefore, most of the data C in each block is at a fast timing. High probability of being invalidated. On the other hand, the data A and the data B, especially the data A, have a high probability of being kept in the valid state for a long time.

Each block whose invalid data amount has increased due to the update (rewriting) of the data C becomes a GC target block, and valid data is copied from these blocks to the copy destination free block. In each GC target block, there is a high probability that most of the data C is invalidated and most of the data A and data B are maintained as valid data. Therefore, in the copy destination block, the amount of data A and the amount of data B increase compared to the GC target block, and instead, the amount of data C decreases compared to the GC target block.

In the present embodiment, since valid data in some blocks having the same number of GCs is copied to the copy destination free block, valid data in a block having a small number of GCs and valid data in a block having a large number of GCs are GC. The operation does not copy to the same copy destination free block. Therefore, as the number of GC times increases, the ratio of the amount of data A to the capacity of the block can be increased, whereby the data A (Cold data) can be separated from the data C (hot data).

FIG. 7 shows an example of the relationship between the number of GCs and the ratio of the amount of data among the data A, B, and C in each block.

In each block with the number of GC=0, the ratio of the amount of data C to the capacity of the block is 50%, the ratio of the amount of data B to the capacity of the block is 30%, and the ratio of the amount of data A to the capacity of the block is 20%. %.

The ratio of the amount of data C to the capacity of the block is quickly reduced by one or two GC operations. As the number of GCs increases, the ratio of the amount of data B to the capacity of the block also gradually decreases.

As described above, in the present embodiment, valid data in a block having a small number of GCs and valid data in a block having a large number of GCs are not copied to the same copy-destination free block. (1) A group containing almost only data A (for example, the number of GCs is about 7 to 10), (2) A group including only data A and data B and hardly containing data C (for example, the number of GCs is about 3 to 6). ), (3) It can be classified into a group including the data A, the data B, and the data C (for example, about 0 to 2 times of GC).

In other words, in the present embodiment, for blocks having the same GC number of times, the ratios of the amounts of data A, B, and C contained in those blocks can be made the same.

Therefore, the improved GC operation of this embodiment of copying the valid data in several blocks with the same number of GC times to the same copy-destination free block is effective even if the data written in SSD3 has high data locality. Even if there are, there are a group of blocks containing almost only data A, a group of blocks containing data A and data B and almost no data C, and a group of blocks containing data A, data B and data C. It is possible to make it possible to gradually separate Hot data and Cold data. As a result, an increase in write amplification of the SSD 3 can be suppressed.

The flowchart of FIG. 8 shows the procedure of the GC operation executed by the controller 4.

The controller 4 checks the number of remaining free blocks (step S11), and determines whether the number of remaining free blocks is equal to or less than the threshold th1 (step S12). This check may be performed on a regular basis. For example, the number of remaining free blocks may be checked when a new free block should be assigned as a write destination block.

If the number of remaining free blocks is equal to or smaller than the threshold value th1 (YES in step S12), the controller 4 first selects the first GC candidate from all active blocks. The first GC candidate may be the block with the maximum invalid data amount. In this case, the block with the maximum invalid data amount is selected as the first GC candidate from all active blocks (step S13). The controller 4 refers to the GC count management list 34, and a block group (first block group) associated with the same GC count as the GC count of the first GC candidate (here, for example, the block with the maximum invalid data amount). Is selected, and some GC target blocks are selected from the first block group (step S14). In step S14, the block group (first block group) indicated by the GC count list including the first GC candidate (for example, the block having the maximum invalid data amount) is selected, and some of the first block group are selected. GC target block is selected. In this case, the first GC candidate (for example, the block having the maximum invalid data amount) and one or more blocks included in the GC count list may be selected as the GC target block.

The controller 4 copies all the valid data in these selected GC target blocks to the copy destination free block (step S15). In step S15, valid data is read from each valid page in the selected GC target block, and the read valid data is written in each available page of the copy destination free block. In step S15, the controller 4 further updates the lookup table (LUT) 33 to associate the LBA of the copied valid data with the physical address of the copy destination free block, and also updates the page management table to update each The original page in the GC target block (that is, the old data with which this LBA was associated) is invalidated. In this case, the controller 4 may first obtain the physical address of the original page in which the copied valid data is stored by referring to the lookup table (LUT) 33, and then the page management table May be updated and the valid/invalid flag corresponding to this physical address may be set to a value indicating invalid.

After that, the controller 4 sets the number of GCs of the selected GC target block+1, that is, a value obtained by adding 1 to the number of GCs of the first block group as the number of GCs of the copy destination free block (step S16).

FIG. 9 shows a GC operation including a process of merging valid data of two block groups having different GC times.

For example, when the amount of valid data included in the block group (GC target block group) associated with the same GC count as the GC count of the block having the maximum invalid data amount is smaller than the threshold value, the controller 4 has a different GC count. A process of merging valid data of two block groups is executed. In this case, the controller 4 may select another block group having a GC number as close as possible to the GC number of the GC target block group.

For example, it is assumed that the block having the maximum invalid data amount is the block B300 and the number of GCs of the block B300 is 10. In this case, the controller 4 checks the total effective data amount of the block group included in the GC count management list with the GC count=10. For example, when the block included in the GC number management list with the GC number=10 is only the block B300, or the GC number management list with the GC number=10 includes two or three blocks. When the effective data amount of is very small, the controller 4 selects the block group in which the GC operation is to be executed together with the block group with the GC count=10.

In this case, the controller 4 has all the block groups having a GC number that is one or more times smaller than the GC number of the block B300 having the maximum invalid data amount (here, a block group having a GC number of 9, a block group having a GC number of 8, The block group having the maximum number of garbage collections may be selected from among the block group having the number of times 7 and the block group having the number of GC times 0).

The controller 4 first refers to the GC count management list with the GC count=9 to determine whether or not there is a block with the GC count=9. If the block with the GC count=9 does not exist, the controller 4 refers to the GC count management list with the GC count=8 to determine whether the block with the GC count=8 exists.

If there is no block with the number of GCs=9 and there is a block with the number of GCs=8, the controller 4 selects a block group with the number of GCs=8 (for example, blocks B41, B42, B43). Then, the controller 4 copies the valid data of the block B300 and the valid data of the block group having the GC count=8 to the copy destination free block. In this case, all the valid data of the blocks B41, B42, B43 do not necessarily have to be used, and the valid data in at least one block of the blocks B41, B42, B43 may be used.

The flowchart of FIG. 10 shows a procedure of a GC operation including a process of merging valid data of two block groups having different GC times.

The controller 4 checks the number of remaining free blocks (step S21), and determines whether the number of remaining free blocks is equal to or less than the threshold th1 (step S22). As mentioned above, this check may be performed on a regular basis.

If the number of remaining free blocks is equal to or smaller than the threshold value th1 (YES in step S22), the controller 4 first selects the first GC candidate from all active blocks. The first GC candidate may be the block with the maximum invalid data amount. In this case, the block having the maximum invalid data amount is selected as the first GC candidate from all active blocks (step S23). The controller 4 refers to the GC count management list 34, and a block group (first block group) associated with the same GC count as the GC count of the first GC candidate (here, for example, the block with the maximum invalid data amount). Is selected, and it is determined whether or not the total amount of valid data of this block group (first block group) is less than or equal to the threshold value th2 (step S24).

The value of the threshold value th2 may be fixed or may be a value that can be changed as necessary. The larger the threshold value th2, the easier the permission to execute the above-described merge process.

For example, the threshold th2 may be preset to a value indicating the capacity of one block in the SSD3. As a result, the merge process can be permitted only when the GC operation cannot be executed only by the block group associated with the same GC count as the GC count of the first GC candidate. Alternatively, the threshold value th2 may be set to a value that is an integral multiple of the capacity of one block in the SSD 3, for example, double.

If the total amount of valid data in the first block group is not equal to or smaller than the threshold value th2 (NO in step S24), the controller 4 selects some GC target blocks from the first block group (step S25). In step S25, these GC target blocks are selected from the first block group indicated by the GC count list including the first GC candidate (for example, the block having the maximum invalid data amount). In this case, the first GC candidate (for example, the block with the maximum invalid data amount) and another block included in the GC count list may be selected as the GC target block.

In step S25, the controller 4 copies all the valid data in the selected GC target block to the copy destination free block. In step S25, the controller 4 further updates the lookup table (LUT) 33 to associate the LBA of the copied valid data with the physical address of the copy-destination free block, and also to update the original page in each GC target block. Invalidate.

Thereafter, the controller 4 sets the number of GCs of the selected GC target block+1, that is, a value obtained by adding 1 to the number of GCs of the first block group as the number of GCs of the copy destination free block (step S26). ..

On the other hand, if the total amount of valid data in the first block group is less than or equal to the threshold value th2 (YES in step S24), the controller 4 is associated with the GC number that is one or more times less than the GC number in the first block group. Among all the block groups, a block group (second block group) associated with the maximum GC number is selected (step S27).

The controller 4 copies the valid data of the first block group and the valid data of the second block group to the copy destination free block (step S28). In step S28, the controller 4 further updates the look-up table (LUT) 33 to associate the LBA of the copied valid data with the physical address of the copy-destination free block, and also to update the original page in each GC target block. Invalidate.

The controller 4 sets the GC count of the second block group+1 as the GC count of the copy destination free block, or sets the GC count of the first block group+1 as the GC count of the copy destination free block (step S29). Alternatively, when the number of GC target blocks in the second block group is larger than the number of GC target blocks in the first block group, the GC count of the second block group+1 is set as the GC count of the copy destination free block. Alternatively, if the number of GC target blocks in the first block group is larger than the number of GC target blocks in the second block group, the number of GCs in the first block group+1 is the GC of the copy destination free block. It may be set as the number of times.

FIG. 11 shows an operation of permitting the merge process only to a block group having a specific GC count or more.

The valid data included in the block with a large number of GCs is highly likely to be data with a low update frequency (data A). However, since the data A is also rewritten at a rate of 20%, the invalid data amount may be large even for a block having a large number of GCs, for example, a block having a GC number=10. The valid data in a block with a large number of GCs is data that has never been updated (rewritten), that is, data that has been kept in a valid state for a long time. Therefore, there is a high probability that this valid data will not be updated in the future.

On the other hand, it is highly possible that data B or data C is included in a block with a small number of GCs. For such a block, there is a possibility that all the data in the block may be invalidated as time management progresses without immediately executing the GC operation of the block.

Therefore, by permitting the block group for which the merge processing is permitted only to the block group having the GC number of times equal to or larger than the merge permission threshold th3, it is possible to prevent the unnecessary copying from occurring and improve the efficiency of the GC. it can.

FIG. 11 exemplifies a case where the merge permission threshold th3 is set to the number of GCs=8.

In this case, if the number of GCs of the block group (first block group) associated with the same number of GCs as the first GC candidate is 8 or more, the merging process of the first block group and another block group is performed. Is allowed.

For example, a merge process of a block group with a GC count of 10 and another block group, and a merge process of a block group with a GC count of 9 and another block group are permitted. On the other hand, for example, the merge process of the block group having the number of GC=7 and another block group is prohibited.

The flowchart of FIG. 12 shows the procedure of the GC operation including the operation of permitting the merge process only to a block group having a specific GC number of times or more.

In the GC operation shown in the flowchart of FIG. 12, the processes of steps S30 to S33 are added to the process described in FIG. Below, the process of step S30-S33 is mainly demonstrated.

If the total amount of valid data in the first block group is equal to or smaller than the threshold value th2 (YES in step S24), the process of the controller 4 proceeds to step S30. In step S30, the controller 4 determines whether the number of GCs in the first block group is the merge permission threshold th3 or more.

If the GC count of the first block group is equal to or greater than the merge permission threshold th3 (YES in step S30), the controller 4 executes the merge process of steps S27 to S29 described in FIG.

On the other hand, if the number of GCs of the first block group (the number of GCs of the first GC candidate block) is smaller than the merge permission threshold th3 (NO in step S30), the controller 4 executes the merge process in steps S27 to S29. Is prohibited, and instead, the processes of steps S31 to S33 are executed.

In step S31, the controller 4 selects another block group different from the first block group as the GC target block group. For example, the controller 4 selects, as a new GC candidate, a block having the second largest amount of invalid data after the first GC candidate block, and the block group indicated by the GC count list including this new GC candidate is set to GC. You may select as a target block group.

Next, the controller 4 copies the valid data of the selected GC target block group to the copy destination free block (step S32) and adds 1 to the GC count of the copy target free block. The value is set (step S33).

If the first GC candidate block is associated with a GC count that is less than the merge allowance threshold th3, then this first GC candidate block is likely to contain frequently updated data. Therefore, the controller 4 may wait for all the valid data of this block to be invalidated without executing the GC for the first GC candidate block.

Next, details of the “LBA-based update frequency notification function” will be described with reference to FIGS. 13 to 22.

FIG. 13 shows an operation of sequentially allocating free blocks for writing data from the host 2.

The controller 4 assigns one of the free blocks indicated by the free block list 60 as the write destination block 62. In this case, the controller 4 updates the block usage order management list 35 and sets the allocation number (sequential number) of the block initially allocated as the write destination block 62 to 1. As shown in FIG. 14, the block use order management list 35 holds allocation numbers (sequential numbers) corresponding to the block addresses. These allocation numbers indicate the order relation of the blocks allocated to the write destination block 62. That is, the controller 4 assigns an allocation number indicating the allocation order to each block allocated as the write target block, and manages these allocation numbers using the block use order management list 35.

The controller 4 writes the write data received from the host 2 in the write buffer 31. After that, the controller 4 sequentially writes the write data in the write buffer 31 from the first page to the last page of the write destination block 62 while updating the look-up table (LUT) 33.

When there are no available pages in the write destination block 62, the controller 4 moves the write destination block 62 to the active block list 61 and allocates the free block in the free block list 60 as a new write destination block 62. In this case, the controller 4 updates the block use order management list 35 and sets the allocation number (sequential number) of this block allocated as the new write destination block 62 to 2.

If all the data in any block in the active block list 61 is invalidated by the update, this block is moved to the free block list 60.

If the number of free blocks in the free block list 60 drops below the threshold th1, then the above-described GC operation of creating free blocks is performed.

FIG. 15 shows a cumulative data write amount calculation operation executed when a write request to the same LBA is requested.

When the controller 4 receives a write command including a certain LBA from the host 2, the controller 4 notifies the host 2 of the accumulated data write amount from the previous write to this LBA as a response to this write command. The cumulative data write amount indicates the total amount of data written to the NAND memory 5 by the host 2 from the previous write to the same LBA as the received write command to the current write to the write command LBA. ..

The cumulative data write amount can be calculated, for example, from the following values.

(1) Capacity per block (2) Number of pages contained in the block (3) First physical storage position (old physical address) in the NAND memory 5 in which data was written by the previous write to the same LBA
(4) Second physical storage position (new physical address) in the NAND memory 5 in which data should be written by this write
(5) Allocated for writing data from the host 2 between the allocation of the block containing the first physical storage location (old physical address) and the allocation of the block containing the second physical storage location (new physical address) The number of blocks (1) to (4) is normal management information in the SSD 3, and is not prepared exclusively for calculating the cumulative data write amount. For example, the controller 4 can easily obtain the physical address mapped to the LBA in the received write command as the first physical storage location by referring to the lookup table (LUT) 33.

The “number of blocks” in (5) can be easily calculated, for example, from the allocation number given to the block containing the first physical storage location and the allocation number given to the block containing the second physical storage location. it can.

The allocation number (sequential number) is managed by the block usage order management list 35 of FIG. Since the management unit of these allocation numbers (sequential numbers) is a block unit, the capacity required to hold these allocation numbers can be small. Therefore, the cumulative data write amount can be acquired at low cost with almost no use of dedicated management information for the calculation.

FIG. 15 shows the cumulative data write amount calculation operation executed when a write command including the LBA 10 is received.

Here, it is assumed that data has already been written to page Px of block B51 by the previous write to LBA10, and that data should be written to page Py of the current write destination block B62 by this write to LBA10. Has been done. If the allocation number of the block B51 is 10 and the allocation number of the block B51 is 13, it can be seen that two write destination blocks (for example, the blocks B52 and B61) are allocated between the block 51 and the block B62. ..

The cumulative data write amount is given by d1+d2+d2+d3.

Here, d1 indicates the number of pages in the block B51 subsequent to the page Px, or the capacity corresponding to the number of these pages. d2 indicates the number of pages in one block or the capacity of one block. d3 indicates the number of pages in the block B62 preceding the page Py, or the capacity corresponding to the number of pages.

The accumulated write amount increases as the number of write commands received from the host 2 increases from the reception of the previous write command including the LBA 10 to the reception of the current write command including the LBA 10. Therefore, the above-mentioned cumulative data write amount can represent the update frequency of the data designated by the LBA 10, that is, the write frequency to the LBA 10.

Upon receiving the write command, the controller 4 may acquire (calculate) the cumulative data write amount by the following procedure.

First, the controller 4 refers to the look-up table (LUT) 33 to obtain the old physical address (here, PA1) mapped to the LBA (here, LBA10) included in the write command. Then, the controller 4 refers to the block use order management list 35, and allocates a block allocation number (here, 10) specified by the old physical address and a block specified by the new physical address (here, PA2). The number (13 here) is acquired. The controller 4 obtains d1 from the number of pages included in the block and the old physical address (PA1), and obtains d3 from the number of pages included in the block and the new physical address (PA2). Further, the controller 4 determines, from the difference between the allocation number (13) and the allocation number (10), from the allocation of the block specified by the old physical address to the allocation of the block specified by the new physical address. The total number of blocks (here, 2) assigned as the write destination block is obtained. This makes it possible to acquire (calculate) the cumulative data write amount (=d1+d2+d2+d3).

FIG. 16 shows a processing sequence of cumulative data write amount response processing.

Here, it is assumed that this processing sequence is applied to an NCQ (Native Command Queuing) system in which a write command and write data are divided.

The host 2 sends a write command including a start LBA indicating a certain LBA (=LBAx) to the SSD 3. In response to the reception of this write command, the controller 4 of the SSD 3 calculates the cumulative data write amount from the previous write to LBAx to the current write to LBAx (step S41), and calculates the calculated cumulative data write amount. A command authorization response including "" is transmitted to the host 2. The command permission response is a permission response indicating an acknowledgment (write command execution permission) for the received write command. By transmitting a permission response from the SSD 3 to the host 2, the transfer of the write data designated by this write command is started. The permission response may include a value that identifies a write command whose execution should be permitted. The cumulative data write amount may be represented by, for example, bytes or the number of logical blocks (logical sectors).

In response to the reception of the command permission response, the host 2 sends the write data to the SSD 3. The controller 4 of the SSD 3 writes the write data to the write buffer 31, writes the write data of the write buffer 31 to the write destination block (step S42), and sends a command completion response (response) to the host 2. A command completion response may be transmitted to the host 2 when the write data is written in the write buffer 31.

The host 2 can grasp the actual update frequency of the data of LBAx (the frequency of writing to LBAx) based on the cumulative data write amount included in the command permission response received from the SSD 3.

If the actual update frequency of the LBAx data is different from the expected update frequency of the LBAx data by the host 2, for example, the actual update frequency of the LBAx data is the LBAx data expected by the host 2. If the update frequency is higher than the update frequency, the host 2 may send an abort command for aborting the sent write command to the SSD 3, if necessary. In this case, the writing of the data designated by the write command is not executed.

The flowchart of FIG. 17 shows the procedure of the cumulative data write amount response process executed by the controller 4.

The controller 4 receives a write command including LBAx as a start LBA from the host 2 (step S51). The controller 4 uses the old physical address mapped to LBAx, the new physical address to be mapped to LBAx, the allocation number assigned to the block including the physical storage location specified by the old physical address, and the new physical address. The cumulative data write amount from the previous write to LBAx to the current write to LBAx based on the allocation number assigned to the block (current write destination block) including the physical storage location specified by Calculate (step S52). The controller 4 returns a permission response including the accumulated data write amount to the host 2 (step S53).

The controller 4 determines whether the write data corresponding to this write command or the abort command for aborting this write command is received from the host 2 (step S54).

If the write data is received, the controller 4 proceeds to step S55. In step S55, the controller 4 writes this write data in the write buffer 31, writes the write data in the write buffer 31 in the current write destination block, updates the lookup table (LUT) 33, and updates the LBAx with the new physical address. And the page management table is updated to invalidate the old physical address (old data).

After that, the controller 4 returns a command completion response to the host 2 (step S56).

As described above, the command completion response may be transmitted to the host 2 when the write data is written in the write buffer 31.

On the other hand, if the abort command is received, the controller 4 discards this write command (step S57).

FIG. 18 shows another processing sequence of the cumulative data write amount response processing.

The host 2 sends a write command including a certain LBA (=LBAx) as a start LBA to the SSD 3. In response to the reception of this write command, the controller 4 of the SSD 3 sends a command permission response to the host 2. In response to the reception of the command permission response, the host 2 sends the write data to the SSD 3. The write data is written in the write buffer 31. The controller 4 of the SSD 3 calculates the cumulative data write amount (step S58). The process of calculating the cumulative data write amount may be started in response to the reception of the write command.

After that, the controller 4 executes writing of write data to the write destination block (step S59), and transmits a command completion response including the calculated cumulative data write amount to the host 2.

As described above, when the write data is written in the write buffer 31, a command completion response including the accumulated data write amount may be transmitted to the host 2.

The flowchart of FIG. 19 shows another procedure of the cumulative data write amount response process.

The controller 4 receives a write command including LBAx as a start LBA from the host 2 (step S61). The controller 4 returns a permission response to the host 2 (step S62). The controller 4 receives the write data from the host 2 (step S63). The write data is written in the write buffer 31.

The controller 4 uses the old physical address mapped to LBAx, the new physical address to be mapped to LBAx, the allocation number assigned to the block including the physical storage location specified by the old physical address, and the new physical address. The cumulative data write amount from the previous write to LBAx to the current write to LBAx is calculated based on the allocation number assigned to the block (current write destination block) including the physical storage location specified by (Step S64). The controller 4 proceeds to step S65.

In step S65, the controller 4 writes the write data in the write buffer 31 to the current write destination block, updates the lookup table (LUT) 33 to map the new physical address to LBAx, and updates the page management table. Then, the old physical address (old data) is invalidated.

After that, the controller 4 returns a command completion response including the accumulated data write amount to the host 2 (step S66).

As described above, the command completion response may be transmitted to the host 2 when the write data is written in the write buffer 31.

Next, with reference to FIGS. 20 to 23, a process of notifying the host 2 of the elapsed time value from the previous write to the same LBA instead of the accumulated data write amount will be described.

This time elapsed value is information regarding the time elapsed from the previous write to the same LBA, and the example of the time elapsed value may be the time of the previous write to the same LBA or the previous time of the same LBA. It may be the time interval between the time of the write and the time of the current write to this same LBA.

FIG. 20 shows an example of a lookup table (LUT) 33 configured to manage the correspondence between the LBA, the physical address, and the last written time in a predetermined management unit such as 4 Kbytes. Show.

The lookup table (LUT) 33 includes a physical address storage area 33A and a time storage area 33B for each LBA. Each time storage area 33B is used to hold a value indicating the time when the writing to the corresponding LBA occurred, that is, a value indicating the time when the data of the corresponding LBA was written. The time stored in each time storage area 33B may be, for example, hour, minute, second.

When a write command including a certain LBA is received, the controller 4 registers the physical address in the physical address area 33A corresponding to this LBA, and the data specified by the write command in the time area 33B corresponding to this LBA. Register the time when (write data) was written. The physical address indicates the physical address of the physical storage location where the data designated by the write command is written. The written time may be the time when the write command is received, the time when the data designated by the write command is written in the write buffer 31, or the data designated by the write command. May be the time when the write-in block of the NAND memory 5 was written.

The flowchart of FIG. 21 shows the procedure of the time lapse response process executed by the controller 4.

Here, it is assumed that a command authorization response including a time elapsed value is transmitted to the host 2.

The controller 4 receives a write command including LBAx as a start LBA from the host 2 (step S71). The controller 4 refers to the look-up table (LUT) 33 to obtain the time of the previous write to LBAx, that is, the time when the data was written by the previous write command including LBAx (step S72). The controller 4 returns a permission response including a time elapsed value indicating the time of the previous write to LBAx to the host 2 (step S73). As described above, the elapsed time value is the time interval between the time of the previous write to LBAx and the time of the current write of LBAx, that is, the current time (the time of the current write to LBAx) to LBAx. It may be a value obtained by subtracting the time of the previous write.

The controller 4 determines whether the write data corresponding to this write command or the abort command for aborting this write command is received from the host 2 (step S74).

If the write data is received, the controller 4 proceeds to step S75. In step S75, the controller 4 writes this write data in the write buffer 31, writes the write data in the write buffer 31 in the current write destination block, updates the lookup table (LUT) 33, and updates the LBAx with the new physical address. And the new write time are mapped, and the page management table is updated to invalidate the old physical address (old data).

After that, the controller 4 returns a command completion response to the host 2 (step S76).

As described above, the command completion response may be transmitted to the host 2 when the write data is written in the write buffer 31.

On the other hand, if the abort command is received, the controller 4 discards this write command (step S77).

In the flowchart of FIG. 21, the case where the command permission response including the time elapsed value is transmitted to the host 2 has been described, but the command completion response including the time elapsed value may be transmitted to the host 2. The transmission of the command completion response including the elapsed time value can be executed by the same procedure as in FIGS. 18 and 19.

The flowchart of FIG. 22 shows a procedure of processing executed by the host 2 based on the accumulated data write amount/elapsed time value notified from the SSD 3.

The host 2 may classify the data into a plurality of types of data groups having different update frequencies based on the cumulative data write amount/elapsed time value notified from the SSD 3. For example, the file system 43 of the host 2 includes a data management unit, and this data management unit classifies the data into a plurality of types of data groups, and the data group is frequently updated (Hot data) and the frequency. It may be separated into a data group that is not updated (Cold data). If the update frequency of the data written in the SSD 3 is equal to or higher than a threshold value, the data management unit can recognize that this data is Hot data.

The data management unit may move the data recognized as Hot data from the SSD 3 to another storage device in order to make the update frequencies of the LBA ranges in the same SSD equal to the frequency of the same range as much as possible.

Alternatively, if the SSD 3 is realized as a high-priced SSD with high durability, the Hot data may be left in the SSD 3 and the Cold data may be moved from the SSD 3 to another storage device. Examples of high-endurance high-cost SSDs include SLC-SSDs that store 1 bit of information per memory cell.

DWPD (Drive Write Per Day) is one of the indicators showing the durability of SSD. For example, DWPD=10 means that for an SSD having a total capacity of 1 Tbyte, 10 Tbytes (=10×1 Tbyte) of data can be written every day for 5 years every day.

Hereinafter, an example of a procedure of processing for the former will be described.

The host 2 sends a write command including LBAx to the SSD 3 (step S81), and receives a response (permission response, command completion response) including the accumulated data write amount or the elapsed time value from the SSD 3 (step S82).

The host 2 determines whether the update frequency of LBAx data (frequency of writing to LBAx) is equal to or higher than a predetermined upper limit frequency (threshold th4) based on the cumulative data write amount or the elapsed time value (step S83). ). For example, in the case where the cumulative data write amount is notified from the SSD 3, the host 2 may determine whether the cumulative data write amount is equal to or larger than the threshold data amount indicated by the threshold value th4. In the case where the SSD 3 is notified of the elapsed time value (the time of the previous write to the same LBA), the host 2 calculates the time interval by subtracting the time of the previous write from the current time, and this time interval is Alternatively, it may be determined whether the time is equal to or longer than the threshold time interval indicated by the threshold th4. Alternatively, the host 2 converts the cumulative data write amount or the elapsed time value into a ratio [percent] indicating how many times write access is performed to write to LBAx, and this time interval is You may determine whether it is more than the threshold time interval shown by threshold value th4.

If the update frequency of LBAx data (write frequency to LBAx) is greater than or equal to the threshold th4 (YES in step S83), the host 2 classifies the LBAx data into a high update frequency data group (Hot data) ( (Step S84), the data of LBAx is moved from SSD3 to another storage device (Step S85).

In step S84, if the response including the accumulated data write amount or the elapsed time value is the permission response to the write command, the host 2 may execute the process of aborting the write command.

FIG. 23 shows a hardware configuration example of the information processing apparatus that functions as the host 2.

This information processing apparatus is realized as a server computer or a personal computer. This information processing device includes a processor (CPU) 101, a main memory 102, a BIOS-ROM 103, a network controller 105, a peripheral interface controller 106, a controller 107, an embedded controller (EC) 108, and the like.

The processor 101 is a CPU configured to control the operation of each component of this information processing apparatus. The processor 101 executes various programs loaded into the main memory 102 from any one of the plurality of SSDs 3. The main memory 102 is composed of a random access memory such as DRAM. The program executed by the processor 101 includes the application software layer 41, the OS 42, and the file system 43 described above.

The processor 101 also executes a basic input/output system (BIOS) stored in the BIOS-ROM 103 which is a non-volatile memory. BIOS is a system program for hardware control.

The network controller 105 is a communication device such as a wired LAN controller or a wireless LAN controller. Peripheral interface controller 106 is configured to perform communication with peripheral devices such as USB devices.

The controller 107 is configured to perform communication with the devices respectively connected to the plurality of connectors 107A. In this embodiment, the plurality of SSDs 3 are connected to the plurality of connectors 107A, respectively. The controller 107 is a SAS expander, a PCIe switch, a PCIe expander, a flash array controller, a RAID controller, or the like.

The EC 108 functions as a system controller configured to perform power management of the information processing device. The EC 108 powers on and powers off the information processing device according to the operation of the power switch by the user. The EC 108 is realized as a processing circuit such as a one-chip microcontroller. The EC 108 may include a keyboard controller that controls an input device such as a keyboard (KB).

The process described in FIG. 22 is executed by the processor 101 under the control of the file system 43.

FIG. 24 shows a configuration example of an information processing device including a plurality of SSDs 3 and a host 2.

This information processing apparatus includes a thin box-shaped housing 201 that can be housed in a rack. A large number of SSDs 3 may be arranged in the housing 201. In this case, each SSD 3 may be removably inserted into a slot provided on the front surface 201A of the housing 201.

The system board (motherboard) 202 is arranged in the housing 201. Various electronic components including a CPU 101, a memory 102, a network controller 105, and a controller 107 are mounted on a system board (motherboard) 202. These electronic components function as the host 2.

As described above, according to the “GC function considering the number of GC times of data in a block” of the present embodiment, the data in the block is garbage collected (for each block including the data written by the host 2). The GC number indicating the number of times of copying by the (GC) operation is managed, and a plurality of blocks (first blocks) associated with the same GC number are selected as target blocks for the garbage collection (GC) operation. Then, the valid data in these first blocks is copied to the copy destination free block, and the value obtained by adding 1 to the GC count of these first blocks is set as the GC count of the copy destination free block. Therefore, it is possible to prevent the data having a high update frequency and the data having a low update frequency from being copied to the same block together by the GC operation. As a result, as the number of GCs increases, the ratio of the amount of data with a low update frequency to the capacity of the block can be increased, so that the data with a low update frequency can be separated from the data with a high update frequency. .. This means that it is possible to suppress an increase in the number of blocks in which a plurality of types of data having different update frequencies are mixed. Therefore, even if the data written in the SSD3 has a high data locality, it is possible to suppress an increase in the number of blocks in which data with a high update frequency and data with a low update frequency are mixed, and as a result, the SSD3's It is possible to suppress an increase in write amplification.

In addition, in the present embodiment, the NAND memory is illustrated as the nonvolatile memory. However, the functions of the present embodiment are, for example, MRAM (Magnetoresistive Random Access Memory), PRAM (Phase change Random Access Memory), ReRAM (Resistive Random Access Memory), or ReRAM (Resistive Random Access Memory). It can also be applied to various non-volatile memories.

Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are also included in the invention described in the claims and the scope of equivalents thereof.

2... Host, 3... SSD, 4... Controller, 5... NAND memory, 21... Garbage collection frequency management unit, 22... Garbage collection operation control unit, 23... Update frequency information response unit.

Claims (8)

A non-volatile memory including a plurality of blocks,
A controller electrically connected to the non-volatile memory and configured to perform a garbage collection operation of the non-volatile memory,
The controller is
A first block and a second block each having a first garbage collection frequency are selected as garbage collection target blocks, and the first garbage collection frequency is within each of the first block and the second block. Shows the number of times the data in was copied by a past garbage collection operation,
Copying valid data in the first block and valid data in the second block to a third block which is a free block,
A fourth block and a fifth block each having a second garbage collection number are selected as garbage collection target blocks, and the second garbage collection number is within each of the fourth block and the fifth block. Shows the number of times the data in was copied by a past garbage collection operation,
The valid data in the fourth block and the valid data in the fifth block are copied to a sixth block which is a free block,
When a part of the data of each of the third block and the sixth block is invalidated, and the first garbage collection count is the same as the second garbage collection count, the third block And the sixth block are selected as garbage collection target blocks, and the valid data in the third block and the valid data in the sixth block are copied to the seventh block which is a free block. The memory system that is configured. When the valid data in the first block and the valid data in the second block are copied to the third block, the garbage collection count of the third block is 1 in the first garbage collection count. The memory system according to claim 1, wherein the memory system is set to a value obtained by adding. When the valid data in the fourth block and the valid data in the fifth block are copied to the sixth block, the garbage collection count of the sixth block is 1 times the second garbage collection count. The memory system according to claim 1, wherein the memory system is set to a value obtained by adding. The memory system according to claim 1, wherein the controller is configured to execute the garbage collection operation when the number of remaining free blocks of the nonvolatile memory is equal to or less than a threshold value. A control method for controlling a non-volatile memory including a plurality of blocks, and performing a garbage collection operation of the non-volatile memory,
Selecting a first block and a second block, each of which has a first garbage collection count, as a garbage collection target block, and the first garbage collection count is the same as that of the first block and the second block. Shows the number of times the data in each has been copied by past garbage collection operations,
Copying valid data in the first block and valid data in the second block to a third block which is a free block;
Selecting a fourth block and a fifth block, each of which has a second garbage collection count, as garbage collection target blocks, and the second garbage collection count is the same as that of the fourth block and the fifth block. Shows the number of times the data in each was copied by past garbage collection operations,
Copying valid data in the fourth block and valid data in the fifth block to a sixth block which is a free block;
If a part of the data of each of the third block and the sixth block is invalidated, and the first garbage collection count is the same as the second garbage collection count, the third block And the sixth block are selected as garbage collection target blocks, and the valid data in the third block and the valid data in the sixth block are copied to a seventh block which is a free block. A control method comprising: When the valid data in the first block and the valid data in the second block are copied to the third block, the garbage collection count of the third block is 1 in the first garbage collection count. The control method according to claim 5, wherein the control method is set to a value obtained by adding When the valid data in the fourth block and the valid data in the fifth block are copied to the sixth block, the garbage collection count of the sixth block is 1 in the second garbage collection count. The control method according to claim 5, wherein the control method is set to a value obtained by adding The control method according to claim 5, wherein the garbage collection operation is executed when the number of remaining free blocks in the nonvolatile memory is equal to or less than a threshold value.

Images