JP6716757B2 - 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.

Types of SSD include small-capacity/high-speed SSD such as single-level cell (SLC)-SSD, multi-level cell (MLC)-SSD, and large-capacity SSD such as triple-level cell (TLC)-SSD.

Usually, in a data center, these plural kinds of SSDs are selectively used according to the application.

U.S. Pat. No. 8621328

However, using a dedicated SSD for each data type is a factor that increases the TCO (Total Cost of Ownership) of the data center.

The problem to be solved by the present invention is to provide a memory system useful for storing various types of data.

According to an embodiment, a memory system includes a non-volatile memory including a plurality of physical blocks, and a controller configured to manage a plurality of namespaces for logically dividing the non-volatile memory into a plurality of areas. And. The controller receives a first request from a host device requesting creation of a first namespace. The first request specifies both the number of logical addresses for the first namespace and the amount of physical resources to reserve for the first namespace, the amount of physical resources for the first namespace. Indicates the number of physical blocks to be reserved or the number of physical blocks to be reserved for the overprovision area of the first name space. When the controller creates the first namespace and the amount of the physical resource designated by the first request indicates the number of physical blocks to be reserved for the first namespace, the first The number of physical blocks specified by the request is allocated to the first namespace, and the number of logical addresses specified by the first request is mapped from the capacity of the number of physical blocks specified by the first request. The remaining capacity less the capacity of the user area is allocated as an overprovision area of the first namespace, and the amount of the physical resource designated by the first request is the overprovision area of the first namespace. When indicating the number of physical blocks to be reserved for use, the number of physical blocks designated by the first request is allocated as an overprovision area of the first namespace. The controller writes the write data associated with the ID of the first namespace into the first area of the non-volatile memory corresponding to the first namespace.

3 is a block diagram showing a configuration example of a memory system according to an embodiment. FIG. FIG. 3 is a diagram for explaining the relationship between a normal tiered storage system and a single tiered storage system. FIG. 3 is a diagram for explaining a plurality of layers (tiers) set in the memory system of the same embodiment. FIG. 3 is an exemplary view for explaining a relationship between a plurality of areas in the memory system of the same embodiment and data written in these areas. FIG. 3 is an exemplary view for explaining namespace management of the memory system of the same embodiment. FIG. 5 is an exemplary view for explaining an extended namespace management command applied to the memory system of the same embodiment. FIG. 4 is an exemplary view showing a sequence of physical resource allocation processing executed by the memory system of the embodiment. 6 is an exemplary flowchart showing a procedure of physical resource allocation processing executed by the memory system of the embodiment. 6 is an exemplary flowchart showing the procedure of a write command transmission process executed by a host connected to the memory system of the embodiment. FIG. 4 is an exemplary view for explaining a write command applied to the memory system of the same embodiment. FIG. 3 is a diagram showing a processing sequence of a write operation executed by the memory system of the same embodiment. FIG. 6 is an exemplary view for explaining a garbage collection operation and a copy destination free block allocation operation, which are executed by the memory system of the same embodiment. FIG. 6 is an exemplary view for explaining a write data amount counting process executed by the memory system of the embodiment. 6 is an exemplary flowchart showing a procedure of write data amount counting processing executed by the memory system of the embodiment. 6 is an exemplary flowchart showing the procedure of a write amplification (WA) calculation process executed by the memory system of the embodiment. FIG. 6 is a diagram showing an example of return data transmitted from the memory system of the embodiment to the host. 6 is an exemplary flowchart showing a procedure of counter reset processing executed by the memory system of the embodiment. FIG. 6 is a view showing an extended garbage collection control command applied to the memory system of the same embodiment. 5 is an exemplary flowchart showing a procedure of a garbage collection operation executed by the memory system of the same embodiment. FIG. 5 is an exemplary view for explaining a process of controlling the ratio of the endurance code and the ECC, which is executed by the memory system of the same embodiment. FIG. 6 is an exemplary view for explaining an encoding process and a decoding process executed by the memory system of the same embodiment. 3 is a block diagram showing a configuration example of an endurance code encoder in the memory system of the same embodiment. FIG. 6 is an exemplary flowchart showing the procedure of an encoding process executed by the memory system of the same embodiment. 6 is an exemplary flowchart showing the procedure of a write control process executed by the memory system of the embodiment. FIG. 3 is a diagram showing a configuration of a flash array applied to the memory system of the same embodiment. The figure which shows the structure of the flash array storage of the same embodiment. The figure which shows another structure of the flash array storage of the same embodiment. FIG. 3 is an exemplary view for explaining the relationship between the total capacity of each SSD in the flash array storage of the embodiment and the amount of physical resources to be assigned to a tier. FIG. 6 is a diagram for explaining a write operation of the flash array storage of the same embodiment. The block diagram which shows the structural example of the host of the same embodiment. 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 interfaces for interconnecting the host 2 and SSD 3, 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 (physical blocks) B0 to Bm-1. The physical blocks B0 to Bm-1 function as erase units. The physical block is sometimes referred to as a “block” or an “erase block”.

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

The controller 4 is electrically coupled 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 relationship between a logical block address (LBA) and a physical address, and (2) hiding 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 performed using the look-up table (LUT) 33. The physical address corresponding to a certain LBA indicates the storage position in the NAND memory 5 where the data of this LBA is written. The physical address includes a physical page address and a physical block address. Physical page addresses are assigned to all pages, and physical block addresses are assigned to all physical 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, and the like. Wear leveling is an operation for leveling the program/erase count of each physical block.

Garbage collection 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 target blocks in which valid data and invalid data are mixed are copied to another block (for example, 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 (size: 512 bytes, for example). Serial numbers start from zero. The controller 4 of the SSD 3 writes the write data specified by the starting logical address (Starting LBA) in the write command and the transfer length to the physical page of the physical 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 corresponding to the physical storage location where the data is written.

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, extended namespace management command, extended garbage collection control 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 of the leading logical block 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 of the leading logical block and the transfer length (the number of logical blocks).

The extended namespace management command is an extended command of the ordinary namespace management command.

Generally, the host software can specify only the number of logical block addresses (LBA) for the namespace, and specify the number of physical blocks (nonvolatile memory capacity) that should be actually allocated for this namespace. I can't. That is, typically the size of a namespace is based on the number of LBAs requested in the create namespace operation. In a normal SSD, the number of physical blocks allocated for this namespace is determined by the controller in the SSD. For example, if the size corresponding to the number of LBAs requested for the namespace is 90 Mbytes and the capacity of one physical block is 100 Mbytes, a normal SSD controller will allocate one physical block to this name. May be allocated for space. Alternatively, if the size corresponding to the number of LBAs requested for the namespace is 120 Mbytes and the capacity of one physical block is 100 Mbytes, a normal SSD controller will use two physical blocks for this name. May be allocated for space. However, in such an SSD-dependent physical block allocation method, the host software cannot request the SSD to create each namespace having different characteristics (durability).

The extended namespace management command can specify not only the number of logical block addresses (LBA) for a namespace to SSD3 but also the number of physical blocks to be allocated for this namespace to SSD3. it can. That is, the extended namespace management command includes a parameter indicating the amount of physical resources (the number of physical blocks) to be reserved for the namespace to be created. The extended namespace management command allows host 2 (host software) to reserve an appropriate number of physical blocks for the workload in host 2 for each namespace. In general, the more physical blocks allocated to a namespace, the more durable that namespace can be. Therefore, the host software can create each namespace with different characteristics (durability) by using the extended namespace management command.

The extended garbage collection control command is an extended command of the host initiated garbage collection command for controlling the garbage collection operation of the SSD 3 by the host 2. The extended garbage collection control command can specify to SSD3 the namespace to be the target of garbage collection. That is, the extended garbage collection control command includes a parameter indicating the target namespace in which garbage collection should be performed.

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 layer processing.

The FTL layer process and the command process may be controlled by the firmware executed by the CPU 12. This firmware causes the CPU 12 to function as the namespace control unit 21, the write amplification calculation unit 22, the garbage collection operation control unit 23, and the consumption/retention control unit 24.

The namespace control unit 21 has a multi-namespace management function for managing a plurality of namespaces. The name space corresponds to a kind of area in the NAND memory 5 which is a non-volatile memory. The namespace control unit 21 creates a plurality of namespaces based on a request from the host 2 to create each namespace. In other words, the namespace control unit 21 logically divides the NAND memory 5 into a plurality of areas (namespaces) based on a request from the host 2 to create each namespace. Host 2 can request SSD 3 to create each namespace using the extended namespace management command described above. The name space control unit 21 allocates the number of physical blocks designated by the host 2 to these individual areas (name spaces). These plural areas (name spaces) are used to respectively store plural kinds of data having different update frequencies.

For example, frequently updated type data (Hot data) is written to a specific area for storing Hot data. Hot data is sometimes called dynamic data. The data of a type with a low update frequency (Cold data) is written in a specific different area (tier) for storing the Cold data. Cold data may also be referred to as non-dynamic data or static data.

That is, although the SSD 3 is physically one storage device, a plurality of areas in the SSD 3 function as different tier storages.

The plurality of areas are respectively associated with the plurality of namespaces. As a result, the host software can easily associate the Hot data with the ID of a specific namespace and the Cold data with the ID of another specific namespace to easily determine the area (tier) to which these data are to be written. Can be specified.

If the Hot data and the Cold data are mixed in the same physical block, the write amplification may increase significantly.

This is because, in a physical block in which Hot data and Cold data are mixed, only a part of the data in the physical block is invalidated at an early timing by updating the Hot data, while the remaining data section ( This is because the Cold data) may be maintained in the valid state 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 garbage collection or the like.

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

If the physical block was filled with only Hot data, it is highly possible that all the data in this block will be invalidated at a relatively fast timing by updating those data. Therefore, this block can be reused only by erasing it without performing garbage collection.

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

In this embodiment, a plurality of types of data having different update frequencies are written in different areas (different namespaces). For example, Hot data is written in an area associated with a specific namespace (NS#1), and Cold data is written in another area associated with another specific namespace (NS#n). It Therefore, it is possible to prevent a situation in which Hot data and Cold data are mixed in the same physical block. This makes it possible to reduce the frequency with which garbage collection operations are performed, which in turn can reduce write amplification.

Further, in the present embodiment, the namespace control unit 21 sets a desired number of physical blocks for each area (namespace) based on a request from the host 2 that specifies the number of physical blocks to be secured for each namespace. Individually assigned to.

For example, when the host 2 wants to create a new namespace, the host 2 sends an extended namespace management command including a parameter indicating the number of physical blocks to be reserved for the target namespace to the SSD 3. The namespace control unit 21 creates a namespace (NS#1) and allocates the number of physical blocks designated by the parameter to this namespace (the area associated with this namespace).

The host 2 repeatedly sends the extended namespace management command to the SSD 3 while changing the value of the parameter indicating the number of physical blocks to be reserved for the target namespace. As a result, a plurality of namespaces (areas) are created, and the NAND memory 5 is logically divided into these plurality of areas.

Therefore, the physical resources (the number of physical blocks) of the NAND memory 5 are optimized for a plurality of areas (a plurality of tiers) based on the size of each area (the number of LBAs) and the durability to be set for each area. Can be distributed to

The write amplification calculation unit 22 calculates not the write amplification of the entire SSD 3, but the write amplification of each namespace (individual area). Accordingly, the write amplification calculation unit 22 can provide the host 2 with the write amplification corresponding to each name space (each area).

The garbage collection operation control unit 23 executes a garbage collection operation in namespace units (area units), and thereby prevents Hot data and Cold data from being mixed in the same physical block. More specifically, when the garbage collection operation control unit 23 receives the extended garbage collection control command from the host 2, the garbage collection operation control unit 23 determines that the physical space allocated to the target namespace specified by the extended garbage collection control command. A target physical block group for garbage collection is selected from the block group. Then, the garbage collection operation control unit 23 executes the garbage collection operation of copying the valid data from the target physical block group to the copy destination free block.

Further, the garbage collection operation control unit 23 manages the free block group created by the garbage collection operation executed for each namespace as a shared free block group shared by these namespaces. That is, these free block groups are shared between namespaces. The garbage collection operation control unit 23 selects the free block having the minimum program/erase count from the free block group. Then, the garbage collection operation control unit 23 allocates the selected free block as a copy destination free block of the area corresponding to the above-mentioned target namespace.

Normally, the number of program/erase times of the free block created by the garbage collection operation of the area for Cold data is much smaller than the number of program/erase of the free block created by the garbage collection operation of the area for Hot data. .. This is because, after a certain amount of Cold data is once written in the area for Cold data, this Cold data is often not updated or rarely updated. On the other hand, the number of program/erase times of the free block created by the garbage collection operation of the hot data area is usually relatively large. Therefore, the above-described operation of allocating the free block having the minimum program/erase count as the copy destination free block automatically changes the block used in the Cold data area to the Hot data area with a small program/erase count. To be assigned to.

The consumption/retention control unit 24 controls the ratio of the code for suppressing the consumption of the memory cell and the error correction code (ECC) to trade the reliability (data retention) and the durability (DWPD value). Take action to optimize off. As a result, the durability of the Hot data area can be enhanced, and the data retention (retention time of written data) of the Cold data area can be extended.

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 a 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. The lookup table 33 includes a plurality of lookup tables (LUT#1, LUT#2,...) Corresponding to a plurality of namespaces so that an independent garbage collection (GC) operation can be performed for each namespace. ).

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 42, and a file system 43.

As is generally known, the operating system 42 manages the host 2 as a whole, controls the hardware in the host 2, and executes controls for allowing an application to use the hardware and the SSD 3. The software is configured as follows.

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 42. 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 42.

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 13 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.

In this embodiment, the host 2 intelligently manages and controls the SSD 3 by using the above-mentioned extended namespace management command, extended garbage collection control command, and the like. For example, it is assumed that the hierarchy management unit 44 of the file system 43 needs to create a namespace (area) for Hot data and a namespace (area) for Cold data. The hierarchical management unit 44 sends an extended namespace management command including a parameter indicating the number of physical blocks to be assigned to the hot data namespace (area) to the SSD 3. When the response including the ID of this namespace is received from the SSD 3, the hierarchy management unit 44 manages the ID of this namespace as the namespace ID for Hot data. Next, the hierarchy management unit 44 sends an extended namespace management command including a parameter indicating the number of physical blocks to be allocated to the cold data namespace (area) to the SSD 3. When the response including the ID of this namespace is received from the SSD 3, the hierarchy management unit 44 manages the ID of this namespace as the namespace ID for Cold data.

When it is necessary to write certain Hot data to SSD3, the tier management unit 44 sends a write command including the namespace ID for Hot data to SSD3. When it is necessary to write certain Cold data to SSD3, the hierarchy management unit 44 sends a write command including the namespace ID for Cold data to SSD3.

When it is necessary to read a certain Hot data, the hierarchy management unit 44 sends a read command including the namespace ID for the Hot data to the SSD 3. When it is necessary to read certain Cold data, the hierarchy management unit 44 sends a read command including the namespace ID for Cold data to the SSD 3.

FIG. 2 shows the relationship between a normal tiered storage system and a single tiered storage system.

In the hierarchical storage system shown on the left side of FIG. 2, three types of SSDs are properly used according to the purpose. The SSD for the tier (T1) is a small capacity/high speed SSD. The small capacity/high speed SSD may be, for example, an SLC-SSD that stores 1-bit information per memory cell. Therefore, the SSD for the tier (T1) is a high-priced SSD.

The SSD for the tier (T1) is used as a storage for data that is frequently accessed (read/write), for example, frequently updated data. Examples of frequently accessed data include file system metadata. The metadata includes various management information such as a storage position of data in a file, a creation date and time of this data, a date and time when this data was updated, a date and time when this data was read. Therefore, the frequency of accessing the metadata (frequency of write access, frequency of read access) is very high. Therefore, the SSD for the tier (T1) used for storing the metadata requires high durability.

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. The SSD for the tier (T1) may be required to have a durability of DWPD=10.

The ratio of the capacity of the tier (T1) to the capacity of the entire tiered storage system is, for example, 1%. The size of the metadata is much smaller than the size of the file contents.

The SSD for the tier (T2) is a medium capacity SSD. The medium capacity SSD may be, for example, an MLC-SSD that stores 2 bits of information per memory cell. The SSD for the tier (T2) is used as a storage for data that is updated less frequently than metadata. DWPD=1 may be required for the SSD for the tier (T2). The ratio of the capacity of the tier (T2) to the capacity of the entire tiered storage system is, for example, 4%.

The SSD for the tier (T3) is a low-cost, large-capacity SSD. The large capacity SSD may be, for example, an MLC-SSD or a TLC-SSD. The SSD for the tier (T3) is used as a storage for data that is rarely updated. In the SSD for the tier (T3), the durability as low as DWPD=0.1 may be sufficient. The ratio of the capacity of the tier (T3) to the capacity of the entire tiered storage system is, for example, 95%.

The right part of FIG. 2 shows an example of a single tier storage system in which one SSD stores all data of three tiers T1 to T3. The DWPD required for the entire single tier storage system can be obtained as follows.

DWPD = (10 x 0.01) + (1 x 0.04) + (0.1 x 0.95) = 0.235
Therefore, if the single tier storage system is applied, the capacity required for the SSD is significantly increased, but the durability required for the SSD is reduced. The MLC-SSD or TLC-SSD is suitable for realizing a low-cost, large-capacity SSD. The write speed of MLC-SSD/TLC-SSD is slower than the write speed of SLC-SSD, but the read speed of MLC-SSD/TLC-SSD is similar to that of SLC-SSD. Therefore, even with a single-tier storage system that uses low-priced, large-capacity SSDs, by adding a function to optimize the durability relationship between multiple tiers, The same durability and performance can be obtained.

FIG. 3 shows an example of distribution of physical resources among a plurality of areas (name spaces) in the SSD 3 (SSD#1) of this embodiment.

The storage space of SSD#1 is, for example, areas 51, 52, 53, 54 for storing a plurality of types of data (Hot data, Warm data, Middle data, Cool data, Cold data) having different update frequencies, It is logically divided into 55.

The data is classified into five data groups (Hot data, Warm data, Middle data, Cool data, Cold data) according to the update frequency. The data update frequency decreases in the order of Hot data, Warm data, Middle data, Cool data, and Cold data. The Warm data, the Middle data, and the Cool data are data having an update frequency intermediate between the Hot data and the Cold data.

The area 51 is used as a hierarchical storage (tier #1) for storing Hot data. A namespace (NS#1) is associated with the area 51. The area 51 is used to store Hot data (active data) having a small capacity and a high update frequency. An example of the ratio of the capacity of the area 51 to the total capacity of the SSD #1 may be 1%. An example of DWPD required for area 51 may be 10.

The area 52 is used as a tiered storage (tier #2) for storing Warm data. A namespace (NS#2) is associated with the area 52. An example of the ratio of the capacity of the area 52 to the total capacity of the SSD #1 may be 2%. An example of DWPD required for region 52 may be three.

The area 53 is used as a hierarchical storage (tier#3) for storing Middle data. A namespace (NS#3) is associated with the area 53. An example of the ratio of the capacity of the area 53 to the total capacity of the SSD #1 may be 3%. The example of the DWPD required for the area 53 may be one.

The area 54 is used as a hierarchical storage (tier #4) for storing Cool data. A namespace (NS#4) is associated with the area 54. An example of the ratio of the capacity of the area 54 to the total capacity of the SSD #1 may be 14%. An example of DWPD required for region 54 may be 0.3.

The area 55 is used as a hierarchical storage (tier #n) for storing Cold data. A namespace (NS#n) is associated with the area 55. The area 55 is used for storing large capacity and low update frequency Cold data (inactive data). An example of the ratio of the capacity of the area 55 to the total capacity of the SSD#1 may be 80%. For example, the frequency of updating the area 55 is about 1/100 of the frequency of updating the area 51. Thus, the example DWPD required for region 55 may be 0.1.

In this way, the Hot data, Warm data, Middle data, Cool data, and Cold data are stored in different areas, respectively. Therefore, it is possible to prevent a situation in which data having different update frequencies, for example, Hot data and Cold data are mixed in the same block. As a result, the write amplification of the SSD 3 can be reduced.

When the physical resources are distributed to the plurality of areas 51 to 55 at the ratio shown in FIG. 3, the DWPD required for the entire SSD3 (SSD#1) can be obtained as follows.

DWPD = (10 x 0.01) + (3 x 0.02) + (1 x 0.03) + (0.3 x 0.14) + (0.1 x 0.8) = 0.312
This means that in principle, the SSD3 (SSD#1) logically divided into the areas 51 to 55 can be realized by a large-capacity, low-cost SSD.

In the present embodiment, as described above, the host 2 can specify the number of physical blocks to be reserved for each namespace, and the SSD 3 can specify the specified number of physical blocks in individual areas (tiers). Can be individually assigned to.

If multiple tiers are implemented by different SSDs, the individual tiers cannot be resized unless the SSDs themselves are replaced. In this embodiment, the same SSD is logically divided into a plurality of tiers (areas). Therefore, the size of each tier can be optimized according to the workload and the durability to be set for each tier (region).

That is, in this embodiment, how many physical blocks are allocated to the areas 51 to 55 can be determined for each area under the control of the host 2.

For example, the host software may request the SSD 3 to allocate a sufficient number of physical blocks for the hot data area 51 (tier #1), which exceeds the expected total amount of hot data (user data capacity). .. In response to this request, the controller 4 of the SSD 3 allocates a specified number of physical blocks dedicated to the Hot data area 51 (tier #1) to the Hot data area 51 (tier #1). assign. For example, if the expected total amount of Hot data (user data capacity) is 100 Gbytes, the host software may request allocation of physical blocks equal in number to 200 Gbytes. In this case, the controller 4 allocates the number of physical blocks corresponding to 200 Gbytes to the area 51 (tier#1). As a result, the number of physical blocks corresponding to twice the capacity of the user area of the area 51 (tier #1) is allocated for the area 51 (tier #1). The remaining 100 GB of physical resources obtained by subtracting the capacity of the user area from 200 GB functions as an over-provision area of the area 51 (tier #1).

Here, the over-provision area will be described.

Over-provisioning means allocating storage capacity in the SSD 3 which is not visible to the host 2 as an available user space (user accessible LBA space). A space to which a storage capacity that is invisible as a user-accessible LBA space is allocated to the host 2 is an overprovision area. By over-provisioning, a physical block group having a capacity exceeding the user accessible LBA space (capacity of user area) is allocated.

In a normal SSD, the host can specify the number of LBAs for a namespace, but not how many physical blocks should be allocated for this namespace. Also, normally, only one over provision area is set in one SSD.

On the other hand, in the present embodiment, the number of physical blocks designated by the host 2 can be assigned to each namespace (area), and as a result, an overprovision area having a desired capacity can be assigned to each area. Can be set individually.

For example, the total capacity of the area 51 (total NS#1 capacity) is determined by the total number of physical blocks allocated to the area 51. The area 51 includes a user area 51a and an over-provision area 51b. The remaining capacity obtained by subtracting the capacity of the user area 51a from the total capacity of the area 51 functions as the over-provision area 51b. The user area 51a is a physical block group assigned to the LBA. The existence of the over-provision area 51b improves the durability and performance of the user area 51a in the area 51.

For each of the other areas, the remaining capacity, which is the capacity determined by the total number of physical blocks allocated to this area minus the capacity of the user area in this area, functions as the over-provision area in this area. ..

Similar to the hot data area 51, the host software allocates physical blocks of a number exceeding the expected total amount of the warm data (user area capacity) to the warm data area 52 (tier #2). You may request SSD3. In response to this request, the controller 4 of the SSD 3 allocates the specified number of physical blocks dedicated to the Warm data area 52 to the Warm data area 52 (tier #2). For example, if the expected total amount of Warm data (user data capacity) is 200 Gbytes and the host software requests allocation of physical blocks of a number corresponding to 250 Gbytes, the controller 4 corresponds to 250 Gbytes. The number of physical blocks is allocated to the area 52 (tier #2). As a result, a physical resource 50 GB larger than the capacity of the user area of the area 52 (tier #2) is allocated to the area 52 (tier #2). The remaining 50 GB physical resource obtained by subtracting the capacity of the user area from the physical resource of 250 GB functions as an over-provision area of the area 52 (tier #2).

Similarly, the host software specifies the amount of physical blocks to allocate for each of all remaining areas.

For example, with respect to the area 55 (tier #n) for Cold data, the host software allocates the minimum number of physical blocks determined in consideration of the expected total amount of Cold data (capacity of user data) to SSD3. You may request. In response to this request, the controller 4 allocates the specified number of physical blocks dedicated to the cold data area 55 (tier #n) to this cold data area 55 (tier #n). For example, if the expected total amount of Cold data (capacity of user data) is 8000 Gbytes, and the host software requests allocation of physical blocks of the number corresponding to 8001 Gbytes, the controller 4 corresponds to 8001 Gbytes. The number of physical blocks is assigned to the area 55 (tier#n). As a result, a physical resource larger by 1 GB than the capacity of the user area of the area 55 (tier#n) is allocated to the area 55 (tier#n). The remaining 1 GB physical resource obtained by subtracting the user data capacity from the 8001 Gbyte physical resource functions as an over-provision area of the area 55 (tier #n).

In this way, the SSD 3 allocates the specified number of physical blocks to each area based on a request from the host 2 that specifies the number of physical blocks to be reserved for each namespace. As a result, the ratio of the capacity of the over-provision area to the capacity of the user area can be optimized for each individual area. For example, the number of physical blocks allocated to each area may be adjusted such that the higher the hierarchy, the larger the amount of overprovision area allocated. In this case, for example, the ratio of the capacity of the over-provision area in the area 55 to the capacity of the user area in the area 55 is more than the ratio of the capacity of the over-provision area in the area 51 to the capacity of the user area in the area 51. Also becomes smaller.

In the area 51, the write amplification of the area 51 can be efficiently reduced by utilizing the large-sized overprovision area. This is because even if the physical block group of the user area 51a of the area 51 is filled with 100 Mbytes of data and, as a result, each of these physical blocks does not include an available page without erasing the block, the physical blocks This is because the physical block group of the over-provision area 51b can be used for writing data instead of the block. Therefore, it is possible to sufficiently delay the timing at which the garbage collection operation of the area 51 is executed. As the data is written in the physical block group in the over-provision area 51b, the data in the physical block group in the user area 51a is invalidated by the update. A physical block with all data invalidated can be reused without its garbage collection. Therefore, since the write amplification of the area 51 can be efficiently reduced, the number of write/erase times of the physical block group of the area 51 can be suppressed low. This means that the durability of the region 51 can be improved.

Since the over-provision area of the area 55 is small, the write amplification of the area 55 increases. However, the update frequency of the Cold data area 55 is much lower than the update frequency of the Hot data area 51. For example, the update frequency of the Cold data area 55 is 1/100 of the update frequency of the Hot data area 51. That is, since the area 55 is rewritten only once while the area 51 is rewritten 100 times, the number of programs/erases of each physical block of the cold data area 55 is very small. Therefore, for the Cold data area 55, even if the write amplification is large, the program/erase count of the physical block group of the Cold data area 55 immediately reaches the upper limit value of the SSD3 program/erase count. It does not occur.

FIG. 4 shows the relationship between the plurality of areas 51 to 55 and the data written in these areas 51 to 55.

The NAND memory 5 is logically divided into areas 51 to 55 corresponding to the namespaces NS#1 to NS#5. Write data associated with the ID of the namespace NS#1 (NSID=1), that is, Hot data, is written in the area 51. Write data associated with the ID (NSID=2) of the namespace NS#2, that is, Warm data, is written in the area 52. Similarly, the write data associated with the ID (NSID=n) of the namespace NS#n, that is, the Cold data, is written in the area 55.

FIG. 5 shows namespace management by SSD3.

Here, it is assumed that a plurality of namespaces NS#1 to NS#n are created. A logical address space (LBA space) A1 of 0 to E0 is allocated to the name space NS#1. A logical address space (LBA space) A2 of 0 to E1 is allocated to the name space NS#2. Similarly, a logical address space (LBA space) An of 0 to En is allocated to the namespace NS#n.

In this embodiment, the lookup table LUT is divided for each namespace. That is, n lookup tables LUT#1 to LUT#n corresponding to the namespaces NS#1 to NS#n are managed by the controller 4 of the SSD 3.

The lookup table LUT#1 manages the mapping between the LBA space A1 of the namespace NS#1 and the physical address of the NAND memory 5. The lookup table LUT#2 manages the mapping between the LBA space A2 of the namespace NS#2 and the physical address of the NAND memory 5. The lookup table LUT#n manages the mapping between the LBA space An of the namespace NS#n and the physical address of the NAND memory 5.

The controller 14 can perform the garbage collection operation independently for each namespace (area) by using the lookup tables LUT#1 to LUT#n.

The management data 100 may hold information indicating the relationship between the namespaces NS#1 to NS#n and the number of physical blocks allocated to these namespaces NS#1 to NS#n.

In this embodiment, the free block generated by garbage collection can be shared between the namespaces NS#1 to NS#n.

FIG. 6 shows an extended namespace management command.

Extended namespace management commands are used for namespace management, including namespace creation and deletion. The extended namespace management command includes the following parameters.

(1) Creation/deletion (2) LBA range (3) Physical resource size (4) tier attribute (optional)
A value of 0h for the create/delete parameter requests SSD3 to create a namespace. The value 1h of the create/delete parameter requests SSD3 to delete the namespace. When requesting deletion of a namespace, a parameter indicating the ID of the namespace to be deleted is set in the extended namespace management command.

The LBA range parameter indicates the LBA range (LBA0 to n-1) of the namespace. This LBA range is mapped to the user area of this namespace.

The physical resource size parameter indicates the number of physical blocks to be reserved for the namespace.

In another embodiment, the extended namespace management command may include a parameter indicating the size of overprovision instead of the physical resource size parameter.

The overprovision size parameter indicates the number of physical blocks to be reserved for the overprovision area in the area associated with the namespace. If the extended namespace management command includes a parameter of size of overprovisioning, SSD3 creates the namespace and specifies by this parameter the overprovision area within the area associated with this namespace. A different number of physical blocks may be assigned.

The tier attribute parameter indicates the hierarchical attribute corresponding to this namespace. The relationship between the value of the tier attribute parameter and the tier attribute is as follows.

000: Hot
001: Warm
010: Middle
011: Cool
100: Cold
FIG. 7 shows a sequence of physical resource allocation processing executed by the host 2 and the SSD 3.

The host 2 sends an extended namespace management command requesting the creation of a namespace (area for Hot data) to the SSD 3. This extended namespace management command includes a physical resource size parameter that specifies the number of physical blocks to be reserved for the Hot data area. Since the capacity of one physical block in the SSD 3 is reported from the SSD 3 to the host 2, the host 2 can request the number of physical blocks suitable for the hot data area. In response to the reception of this extended namespace management command, the controller 4 of the SSD 3 creates a namespace (NS#1) and allocates a specified number of physical blocks to this namespace (NS#1) ( Step S11). The controller 4 sends a response indicating the completion of the command to the host 2. This response may include the ID of the created namespace.

The host 2 sends an extended name space management command requesting the creation of the next name space (area for Warm data) to the SSD 3. This extended namespace management command includes a physical resource size parameter that specifies the number of physical blocks that should be reserved for the Warm data area. In response to the reception of this extended namespace management command, the controller 4 of the SSD 3 creates a namespace (NS#2) and allocates a specified number of physical blocks to this namespace (NS#2) ( Step S12). The controller 4 sends a response indicating the completion of the command to the host 2. This response may include the ID of the created namespace.

Similarly, a namespace (area for Middle data) and a namespace (area for Cool data) are created.

Then, the host 2 sends to the SSD 3 an extended namespace management command requesting the creation of the next namespace (area for Cold data). This extended namespace management command includes a physical resource size parameter that specifies the number of physical blocks that should be reserved for the area for Cold data. In response to the reception of this extended namespace management command, the controller 4 of the SSD 3 creates a namespace (NS#n) and allocates a specified number of physical blocks to this namespace (NS#n) ( Step S13). The controller 4 sends a response indicating the completion of the command to the host 2. This response may include the ID of the created namespace.

In this way, by repeating the process of creating a namespace while allocating the designated number of physical blocks to the namespace, the NAND memory 5 is logically divided into a plurality of regions, and further, the designation is performed for each region. The allocated number of physical blocks is allocated.

The flowchart of FIG. 8 shows the procedure of the physical resource allocation processing executed by the SSD 3.

The controller 4 of the SSD 3 receives the extended namespace management command from the host 2 (step S21). The controller 4 determines whether or not the extended namespace management command requests the creation of a namespace based on the creation/deletion parameter in the extended namespace management command (step S22).

If the extended namespace management command requests the creation of a namespace (YES in step S22), the controller 4 can secure the number of physical blocks designated by the physical resource parameter in the extended namespace management command. Whether or not it is determined based on the number of remaining physical blocks in the free block group (step S23).

If the number of physical blocks is greater than or equal to the designated number (YES in step S23), the controller 4 creates a namespace and stores the designated number of physical blocks in the area associated with this namespace. Allocate (step S24). The controller 4 notifies the host 2 of the command completion (step S25).

If the number of remaining physical blocks is smaller than the designated number (NO in step S23), the controller 4 notifies the host 2 of an error (step S26). The host 2 that has reported the error may change the number of physical blocks to be secured. Alternatively, the host 2 notified of the error response may restart the process of creating each namespace while designating the number of physical blocks to be reserved for each namespace.

The flowchart of FIG. 9 shows the procedure of the write command transmission process executed by the host 2.

When a request to write data occurs (YES in step S31), the host 2 classifies the write data (data to be written) as Hot data, Warm data, Middle data, Cool data, or Cold data (step S31). S32). The host 2 classifies the write data (data to be written) as Hot data, Warm data, Middle data, Cool data, or Cold data according to the data type such as metadata or file content (content). Good.

If the write data is Hot data (YES in step S33), the host 2 sends a write command including the ID (NSID#1) of the namespace for Hot data to the SSD 3 (step S36).

If the write data is Warm data (YES in step S34), the host 2 sends a write command including the ID (NSID#2) of the namespace for Warm data to the SSD 3 (step S37).

If the write data is Cold data (YES in step S35), the host 2 sends a write command including the ID (NSID#n) of the cold data namespace to the SSD 3 (step S38).

FIG. 10 shows a write command.

The write command includes the following parameters.

(1) First LBA
(2) Number of logical blocks (3) Name space ID
The parameter of the head LBA indicates the head LBA of the data to be written.

The number of logical blocks parameter indicates the number of logical blocks (that is, the transfer length) corresponding to the data to be written.

The namespace ID parameter indicates the ID of the namespace in which the data should be written.

FIG. 11 shows a processing sequence of a write operation executed by the host 2 and SSD 3.

The host 2 sends a write command to SSD3 and sends write data to SSD3. The controller 4 of the SSD 3 writes the write data to the write buffer (WB) 31 (step S41), and notifies the host 2 of the response of command completion command completion. After that, the controller 4 writes the write data to an available block in the area associated with the namespace specified by the namespace ID in the write command (step S42).

FIG. 12 shows a garbage collection operation and a copy destination free block allocation operation executed by the SSD 3.

As described above, the garbage collection operation is executed for each namespace. In the garbage collection operation of the namespace (NS#1), the controller 4 of the SSD 3 extracts the target physical block for garbage collection from the physical blocks (active blocks) in the area 51 associated with the namespace (NS#1). select. For example, the controller 4 may refer to the lookup table LUT#1 to specify some upper physical blocks having the highest ratio of invalid data, and select the physical blocks as the target physical blocks for garbage collection. ..

The controller 4 manages a free block pool (free block list) 60 including a group of free blocks shared between namespaces. The controller 4 selects a free block having the minimum number of program/erase times from the free block group. The controller 4 allocates the selected free block to the namespace (NS#1) as the copy destination free block B1000. The controller 4 copies all valid data from the target physical block group for garbage collection (here, blocks B0 to B3) to the copy destination free block B1000. Then, the controller 4 updates the lookup table LUT#1 and maps the valid data to the copy destination free block B1000. The target physical block groups B0 to B3 for garbage collection are free blocks that do not include valid data. These free blocks are moved to the free block pool.

The garbage collection operation is similarly performed for the other namespaces (NS#2 to NS#n).

For example, in the garbage collection operation of the namespace (NS#n), the controller 4 selects the target physical block for garbage collection from the physical blocks (active blocks) in the area 55 associated with the namespace (NS#n). select. For example, the controller 4 may identify some upper physical blocks with the highest ratio of invalid data by referring to the lookup table LUT#n and select the physical blocks as the target physical blocks for garbage collection. ..

The controller 4 selects a free block having the minimum number of program/erase times from the free block group. The controller 4 allocates the selected free block to the namespace (NS#n) as the copy destination free block B1001. The controller 4 copies all valid data from the target physical block group (here, blocks B2000 to B2003) of the garbage collection to the copy destination free block B1001. Then, the controller 4 updates the lookup table LUT#n and maps the valid data to the copy destination free block B1001. The target physical block groups B2000 to B2003 for garbage collection are free blocks that do not include valid data. These free blocks are moved to the free block pool.

As described above, since the update frequency of the namespace (NS#n) is much lower than the update frequency of the namespace (NS#1), it is created by the garbage collection of the namespace (NS#n). The number of free block programs/erases is small. In the garbage collection operation of this embodiment, every time the garbage collection of the namespace (NS#1) is executed, the physical block used in the past in the namespace (NS#n) is renamed to the namespace (NS#1). ) Is allocated as a copy destination free block. Therefore, it is possible to effectively reuse the physical block used in the namespace (NS#n) and having a small number of programs/erases in the namespace (NS#1). As a result, the durability of the namespace (NS#1) can be improved.

Further, the controller 4 executes a wear leveling process of exchanging physical blocks between the namespace (NS#1) and the namespace (NS#n) in order to improve the durability of the namespace (NS#1). You can also do it. For example, the program/erase count of one of the physical blocks used in the namespace (NS#1) is the threshold count (the threshold count is set to a value smaller than the upper limit of the program/erase count). Controller 4, the controller 4 may replace the physical block with a physical block having the minimum program/erase count in the namespace (NS#n).

FIG. 13 shows a write data amount counting process executed by the SSD 3.

The controller 4 of the SSD 3 can calculate the write amplification for each namespace instead of the write amplification of the SSD 3 as a whole. To this end, the controller 4 uses two types of counters, a counter for counting the amount of data written by the host 2 and a counter for counting the amount of data written by the garbage collection operation, in the namespace. Prepare for each.

The counter 61 and the counter 62 are used to calculate the write amplification of the namespace (NS#1). The counter 61 counts the amount of data written by the host 2 to the namespace (NS#1), that is, the area 51. The counter 62 counts the amount of data written in the namespace (NS#1), that is, the area 51 by garbage collection of the namespace (NS#1).

The counter 63 and the counter 64 are used to calculate the write amplification of the namespace (NS#2). The counter 63 counts the amount of data written by the host 2 to the namespace (NS#2), that is, the area 52. The counter 64 counts the amount of data written in the namespace (NS#2), that is, the area 52, by garbage collection of the namespace (NS#2).

The counter 65 and the counter 66 are used to calculate the write amplification of the namespace (NS#n). The counter 65 counts the amount of data written by the host 2 to the namespace (NS#n), that is, the area 55. The counter 66 counts the amount of data written in the namespace (NS#n), that is, the area 55 by the garbage collection of the namespace (NS#n).

The flowchart of FIG. 14 shows the procedure of the write data amount counting process executed by the SSD 3.

When the controller 4 of the SSD 3 receives the write command from the host 2, the controller 4 determines the target namespace (area) to which the write data is to be written, based on the namespace ID included in the write command (step). S41 to S43). Then, the controller 4 writes the write data in the target namespace (area) and counts the amount of data to be written (steps S44 to S46).

For example, when the target namespace (area) is the namespace (NS#1) (YES in step S41), the controller 4 uses the counter 61 to store the data written in the namespace (NS#1). The amount is counted (step S44). In step S44, the current count value of the counter 61 may be increased by the transfer length of the write data.

If the target namespace (area) is the namespace (NS#2) (YES in step S42), the controller 4 uses the counter 63 to determine the amount of data written in the namespace (NS#2). Count (step S45). In step S45, the current count value of the counter 63 may be increased by the write data transfer length.

If the target namespace (area) is the namespace (NS#n) (YES in step S43), the controller 4 uses the counter 65 to determine the amount of data written in the namespace (NS#n). Count (step S46). In step S46, the current count value of the counter 65 may be increased by the transfer length of the write data.

When the garbage collection operation of the namespace (NS#1) is executed (YES in step S51), the controller 4 uses the counter 62 to write to the namespace (NS#1) by this garbage collection operation. The amount of data is counted (step S54). In step S54, the count value of the counter 62 may be increased by the total amount of all valid data in the target block group of the garbage collection operation.

When the garbage collection operation of the namespace (NS#2) is executed (YES in step S52), the controller 4 uses the counter 64 to write to the namespace (NS#2) by this garbage collection operation. The amount of data is counted (step S55). In step S55, the count value of the counter 64 may be increased by the total amount of all valid data in the target block group of the garbage collection operation.

When the garbage collection operation of the namespace (NS#n) is executed (YES in step S53), the controller 4 uses the counter 66 to write to the namespace (NS#n) by this garbage collection operation. The amount of data is counted (step S56). In step S56, the count value of the counter 66 may be increased by the total amount of all valid data in the target block group of the garbage collection operation.

The flowchart of FIG. 15 shows the procedure of the write amplification (WA) calculation process executed by the SSD 3.

The controller 4 of the SSD 3 acquires the amount of data (count value of the counter 61) written in the namespace (NS#1) by the host 2 (step S61). The controller 4 acquires the amount of data (count value of the counter 62) written in the namespace (NS#1) by the garbage collection operation of the namespace (NS#1) (step S62). The controller 4 calculates the write amplification of the namespace (NS#1) based on the count value of the counter 61 and the count value of the counter 62 (step S63). The write amplification (NS#1-WA) of the namespace (NS#1) is obtained as follows.

NS#1-WA=“count value of counter 61+count value of counter 62”/“count value of counter 61”
The controller 4 acquires the amount of data (count value of the counter 63) written in the namespace (NS#2) by the host 2 (step S64). The controller 4 acquires the amount of data (count value of the counter 64) written in the namespace (NS#2) by the garbage collection operation of the namespace (NS#2) (step S65). The controller 4 calculates the write amplification of the namespace (NS#2) based on the count value of the counter 63 and the count value of the counter 64 (step S66). The write amplification (NS#2-WA) of the namespace (NS#2) is obtained as follows.

NS#2-WA=“count value of counter 63+count value of counter 64”/“count value of counter 63”
The controller 4 acquires the amount of data (count value of the counter 65) written in the namespace (NS#n) by the host 2 (step S67). The controller 4 acquires the amount of data (count value of the counter 66) written in the namespace (NS#n) by the garbage collection operation of the namespace (NS#n) (step S68). The controller 4 calculates the write amplification of the namespace (NS#n) based on the count value of the counter 65 and the count value of the counter 66 (step S69). The write amplification (NS#n-WA) of the namespace (NS#n) is obtained as follows.

NS#n-WA=“count value of counter 65+count value of counter 66”/“count value of counter 65”
When a WA get command requesting write amplification for each namespace is received from the host 2 (YES in step S70), the controller 4 sends the return data shown in FIG. The write amplification of is notified to the host 2 (step S71).

The processes of steps S61 to S69 may be executed in response to the reception of the WA get command.

The flowchart of FIG. 17 shows the procedure of the counter reset process executed by the SSD 3.

This counter reset process is used to provide the host 2 with the write amplification of each namespace of the SSD 3 after a specific reset event such as a change in the setting of the SSD 3 has occurred. An example of changing the setting of the SSD 3 may be changing the setting of a certain namespace or deleting a certain namespace. Alternatively, an example of changing the setting of the SSD 3 may be changing the setting of the SSD 3 as a whole.

The SSD 3 executes counter reset processing in response to a request from the host 2.

This request may be a command requesting to reset the counter. In response to receiving this command, SSD3 may reset the counters 61 to 66 corresponding to all namespaces. If this command contains a namespace ID, SSD3 may only reset the two counters associated with the namespace corresponding to the namespace ID.

Alternatively, a control command for changing the setting of a certain namespace or the setting of the SSD 3 as a whole may be treated as this request. The change of the setting of a certain namespace may be the change of the size (LBA range) of this namespace or the change of the number of physical blocks for this namespace.

The procedure of the counter reset process will be described below by exemplifying, but not limited to, the case where the counter reset process is executed in response to a change in a certain namespace setting.

When the controller 4 receives from the host 2 a control command requesting to change the setting of the namespace, the controller 4 determines the target namespace of the setting change based on the namespace ID in the control command.

If the target namespace is the namespace (NS#1) (YES in step S81), the controller 4 changes the setting of the namespace (NS#1) according to the parameter in the control command (step S82). The controller 4 clears the count values of the counters 61 and 62 corresponding to the namespace (NS#1) to zero (step S83).

If the target namespace is the namespace (NS#2) (YES in step S84), the controller 4 changes the setting of the namespace (NS#2) according to the parameter in the control command (step S85). The controller 4 clears the count values of the counters 63 and 64 corresponding to the namespace (NS#2) to zero (step S86).

If the target namespace is the namespace (NS#n) (YES in step S87), the controller 4 changes the setting of the namespace (NS#n) according to the parameter in the control command (step S88). The controller 4 clears the count values of the counters 65 and 66 corresponding to the namespace (NS#n) to zero (step S89).

FIG. 18 shows an extended garbage collection (GC) control command.

As described above, the extended garbage collection (GC) control command is used by the host 2 as a host initiated garbage collection command for controlling the garbage collection operation of an arbitrary namespace of the SSD 3.

This extended garbage collection (GC) control command includes the following parameters.

(1) Name space ID
(2) Amount of free blocks (3) Timer The parameter of the namespace ID indicates the ID of the target namespace in which garbage collection should be executed.

The free block amount parameter indicates the amount of free blocks (for example, the number of free blocks) to be reserved for the target namespace.

The timer parameter specifies the maximum time for garbage collection operation.

The host 2 requests the SSD 3 to perform garbage collection of any namespace in the namespace (NS#1) to namespace (NS#n) by using the extended garbage collection (GC) control command. You can

For example, the host 2 may monitor the write amplification of each namespace (area) by periodically transmitting a WA Get command to the SSD 3. When the write amplification of a certain namespace (area) reaches the write amplification threshold value corresponding to this namespace, the host 2 sends an extended garbage collection (GC) control command including the namespace ID of this namespace. It may be sent to SSD3.

Alternatively, if the host 2 wants to write data to a certain namespace (area) with good latency, the host 2 may issue an extended garbage collection (GC) control command containing the namespace ID of this namespace. It may be sent to SSD3.

In response to receiving the extended garbage collection (GC) control command from the host 2, the controller 4 of the SSD 3 performs a garbage collection operation for reserving a specified amount of free space dedicated for the target namespace. Execute. The controller 4 ends the garbage collection operation at the time when the specified amount of free space is secured or when the maximum time elapses, whichever is earlier.

The flowchart of FIG. 19 shows the procedure of the garbage collection operation executed by the SSD 3.

When the controller 4 of the SSD 3 receives the extended garbage collection (GC) control command from the host 2 (YES in step S91), the controller 4 determines the target name specified by the namespace ID in the extended garbage collection (GC) control command. A space garbage collection operation is executed (step S92). In step S92, the controller 4 selects some physical blocks for garbage collection from the active block group of the target namespace, and copies the valid data of these physical blocks to the copy destination physical block.

The garbage collection operation is ended when the specified amount of free space is secured or when the maximum time elapses, whichever is earlier (steps S93 and S94).

FIG. 20 shows a process of controlling the ratio of the code for suppressing the consumption of the memory cell and the error correction code (ECC) according to the name space (area) where the data is to be written.

In this embodiment, the trade-off between reliability (data retention) and durability (DWPD value) is achieved by controlling the ratio of the code for suppressing the consumption of the memory cell and the error correction code (ECC). Optimized.

Here, the outline of the operation of encoding the write data using the code (coding) for suppressing the consumption of the memory cell per one writing will be described.

The controller 4 of the SSD 3 first encodes the write data using a code (coding) for suppressing the consumption of the memory cells, and writes the first encoded data (in FIG. 20, written as “endurance code”). Part)). This code is used to reduce the frequency of occurrence of a specific code (a high program level code corresponding to a high threshold voltage) that consumes the memory cell severely. Examples of this code (coding) include the above-mentioned endurance code (endurance coding).

For example, in the MLC, a memory cell corresponds to one of four levels (“E” level, “A” level, “B” level, “C” level) corresponding to 2 bits depending on a program ( Program level) is set. The "E" level is the erased state. The threshold voltage distribution of the memory cell becomes higher in the order of “E” level, “A” level, “B” level, and “C” level. The "C" level state is a state (program level) in which the memory cell is heavily consumed.

In encoding using a code for suppressing consumption of memory cells (coding), for example, a code corresponding to a specific level (for example, “C” level) in which consumption of memory cells is large is another code (for example, Two "B" levels may be converted into a long bit pattern corresponding to consecutive "BB".

Thus, in encoding, a specific code (bit pattern) that consumes a memory cell is replaced with another long code (bit pattern), so that the code word of write data is extended. Therefore, in encoding, the controller 4 may first losslessly compress the write data. Then, the controller 4 may replace each specific bit pattern in the compressed write data with another long bit pattern that consumes less memory cells.

The controller 4 adds an error correction code (ECC) to the first encoded data (“endurance code” in FIG. 20) obtained by encoding, and thereby adds the second encoded data (“endurance code” and “endurance code” in FIG. 20). Data including ECC") is generated, and this second encoded data is written to an available page in the physical block. Each page includes a data area and a redundant area. The bit length of the second encoded data matches the size of the page including the data area and the redundant area.

Further, the controller 4 automatically changes the ratio of the first encoded data and the error correction code (ECC) according to which area (name space) the write data is written to.

The longer the first endurance code, the less frequently a particular code that consumes memory cells is reduced. Therefore, the longer the first encoded data (endurance code), the more the consumption of the memory cell per write can be suppressed.

For example, when the write data is the write data to be written in the hot data area, the controller 4 further increases the durability of the hot data area (DWPD) by using the longer first encoded data and The ratio of the first coded data and the error correction code is controlled so that the second coded data including the combination of the short error correction codes is obtained. That is, in writing Hot data, an encoding method that prioritizes durability over reliability (data retention) is used.

On the other hand, when the write data is the write data to be written in the area for Cold data, the controller 4 shortens the first encoded data in order to extend the data retention of the data written in the area for Cold data. The ratio of the first coded data and the error correction code is controlled so that the second coded data including a longer combination of error correction codes can be obtained. That is, in writing Cold data, an encoding method that prioritizes reliability (data retention) over durability is used.

In the present embodiment, as shown in FIG. 20, the higher the rewrite frequency (update frequency), the shorter the ECC (bit length) of the namespace (area), and instead the first encoded data (endurance code). The bit length of becomes longer. Further, the smaller the rewriting frequency (update frequency) of the namespace (area), the longer the ECC bit length, and instead the shorter the bit length of the first encoded data (endurance code).

Since the number of correctable bits increases as the ECC bit length increases, reliability (data retention) is improved. Generally, the bit error rate increases with time. Therefore, increasing the number of correctable bits can improve data retention.

On the other hand, as described above, the longer the bit length of the endurance code, the more the wear of the memory cell group in the page can be suppressed, and the durability is improved.

FIG. 21 shows an encoding process and a decoding process executed by the SSD 3.

The controller 4 of the SSD 3 includes an endurance code encoder 91, an ECC encoder 92, an endurance code decoder 93, and an ECC decoder 94.

The ECC encoder 92 and the ECC decoder 94 respectively execute an ECC encoding process for generating an ECC and an ECC decoding process for error correction. In the ECC encoder 92, the systematic code is used to generate the ECC. Examples of systematic codes include Hamming codes, BHC codes, Reed-Solomon codes, and the like.

The endurance code encoder 91 and the endurance code decoder 93 execute an encoding process for suppressing consumption of the memory cells and a decoding process corresponding to this encoding process. In the endurance code encoder 91, an endurance code that is a non-systematic code is used to generate the first encoded data (endurance code). In the endurance code encoder 91, as described above, the specific code (for example, the bit pattern corresponding to the “C” level) that consumes the memory cell drastically corresponds to another long code (for example, “BB”). Long bit patterns, etc.). That is, this encoding process is a decompression process for decompressing the codeword.

FIG. 22 shows a configuration example of the endurance code encoder 91.

The endurance code encoder 91 includes an entropy analysis unit 911, a compression unit 912, a search unit 914, a replacement unit 915, a code length check unit 916, an output unit 917, and the like.

The entropy analysis unit 911 obtains the number of appearances (or the appearance probability) of each bit pattern that appears in the write data. The compression unit 912 generates a codebook 913 based on the analysis result of the entropy analysis unit 911, and uses the codebook 913 to reversibly compress the write data. The code book 913 shows the correspondence between each bit pattern appearing in the write data and the conversion code corresponding to these bit patterns. The compression unit 912 assigns a short conversion code to a bit pattern having a large number of appearances.

The search unit 914 searches for compressed data (compressed write data) from, for example, the most significant bit, in order to find a specific code that consumes memory cells severely. The specific code may be, for example, a bit pattern corresponding to the “C” level. The replacement unit 915 replaces the specific code searched by the search unit 914 with another long code (for example, a long bit pattern corresponding to “BB”). This converts a specific code in the compressed data into another long code that consumes less memory cells. The replacing unit 915 updates the codebook 913, thereby replacing the specific conversion code in the codebook 913 corresponding to the specific code described above with another long code described above.

The code length check unit 916 checks the code length (bit length) of the current compressed data. When the code length (bit length) of the current compressed data is shorter than a predetermined threshold value (target bit length), the search and replacement process is repeated. This optimizes the code length of the current compressed data.

The target bit length is adaptively changed according to the name space (area) in which the write data is to be written. Therefore, the bit length of the encoded data (endurance code) becomes longer as the namespace (area) having a higher rewriting frequency (update frequency). In other words, the bit length of the encoded data (endurance code) becomes shorter as the namespace (area) having a lower rewriting frequency (update frequency).

The output unit 917 outputs the compressed data having the optimized bit length as the first encoded data (endurance code). A codebook 913 may be added to the first encoded data.

The flowchart of FIG. 23 shows the procedure of the encoding process for suppressing the consumption of the memory cell.

The controller 4 obtains the number of appearances of some bit patterns in the write data, and sorts these bit patterns in descending order of the number of appearances (step S1). The controller 4 generates a codebook 913 including a conversion code for compressing each bit pattern based on the result of the entropy analysis, and losslessly compresses the write data using the codebook 913 (step S2).

The controller 4 generates encoded data by encoding this compressed data using a code for suppressing consumption of the memory cell.

In this case, the controller 4 first searches the compressed data for a specific code (specific bit pattern) that consumes memory cells (step S3). The controller 4 converts this searched code (bit pattern) into another long code (bit pattern) that consumes less memory cells (step S4). The controller 4 updates the conversion code in the codebook corresponding to this searched specific code (step S5).

The controller 4 determines whether the bit length of the current compressed data (encoded data) is longer than the target bit length (step S6). The target bit length is predetermined according to the name space (area) in which the data is to be written. For example, a long target bit length is used for data (Hot data) written in the namespace NS#1, and a short target bit length is used for data (Cold data) written in the namespace NS#n. ..

If the bit length of the current compressed data (encoded data) is shorter than the target bit length, the processes of steps S3 to S5 are executed again. The more the processes of steps S3 to S5 are repeated, the lower the frequency of appearance of a specific code (for example, a bit pattern corresponding to the "C" level) that consumes the memory cell severely can be reduced. As a result, the bit length of the encoded data becomes longer.

If the bit length of the current compressed data (encoded data) becomes longer than the target bit length (YES in step S6), the controller 4 adds a codebook to, for example, the end of the encoded data (step S7). ..

The flowchart of FIG. 24 shows the procedure of the write control process executed by the SSD 3.

The controller 4 of the SSD 3 determines which hierarchical attribute name space (area) the received write data should be written to, and according to the determination result, an encoding method for encoding the write data. To change. The change of the encoding method is performed by controlling the ratio between the endurance code and the ECC.

That is, when the controller 4 of the SSD 3 receives the write command from the host 2 (YES in step S101), the controller 4 determines the hierarchical attribute (Hot/Hot/Hot/) of the target namespace (area) designated by the namespace ID in the write command. Warm/Middle/Cool/Cold) is determined (step S102). The hierarchical attribute of the target namespace (area) may be determined based on the size of the over-provision area of the target namespace (area) (the ratio between the user area and the over-provision area, etc.). Alternatively, if the extended namespace management command requesting the creation of the target namespace includes the tier attribute parameter, the controller 4 sets the hierarchical attribute indicated by this tier attribute parameter as the hierarchical attribute of the target namespace. May be determined. Alternatively, the write command may include a parameter indicating the hierarchical attribute of the target namespace in addition to the ID of the target namespace.

For example, if the hierarchical attribute of the target namespace is Hot (YES in step S103), that is, if the write data is associated with the ID of the namespace NS#1, the controller 4 sets the ratio between the endurance code and the ECC. The write data is encoded using an encoding method that prioritizes reliability over reliability by controlling (step S104). According to the encoding method here, the write data is encoded into data including a combination of a longer endurance code and a shorter ECC. The controller 4 writes the encoded data to the usable page of the physical block in the area 51 (step S105).

For example, if the hierarchical attribute of the target namespace is Cold (YES in step S106), that is, if the write data is associated with the ID of the namespace NS#n, the controller 4 sets the ratio between the endurance code and the ECC. The write data is encoded by using an encoding method that prioritizes reliability over durability by controlling (step S107). According to the encoding method here, the write data is encoded into data including a combination of a shorter endurance code and a longer ECC. The controller 4 writes the encoded data to the usable page of the physical block in the area 55 (step S108).

FIG. 25 shows the configuration of the flash array storage of this embodiment.

This flash array storage is recognized by the host 2 as one storage device. This flash array storage includes a plurality of SSDs, that is, SSD#1, SSD#2, SSD#3,... SSD#n, which are striped in order to realize a large capacity and high speed.

Each of SSD#1, SSD#2, SSD#3,..., SSD#n includes a non-volatile memory. Further, each of SSD#1, SSD#2, SSD#3,... SSD#n has the same namespace management function as SSD3 of this embodiment.

In this flash array, the area 51 (NS#1) is arranged across SSD#1, SSD#2, SSD#3,..., SSD#n. In other words, the area 51 includes some physical blocks reserved for the SSD#1 namespace (NS#1) and some physical blocks reserved for the SSD#2 namespace (NS#1). And some physical blocks reserved for the SSD#3 namespace (NS#1) and some physical blocks reserved for the SSD#n namespace (NS#1).

The area 52 (NS#2) is also arranged across the SSD#1, SSD#2, SSD#3,..., SSD#n. In other words, the area 52 includes some physical blocks reserved for the SSD#1 namespace (NS#2) and some physical blocks reserved for the SSD#2 namespace (NS#2). And some physical blocks reserved for the SSD#3 namespace (NS#2) and some physical blocks reserved for the SSD#n namespace (NS#2).

The area 53 (NS#3) is also arranged across the SSD#1, SSD#2, SSD#3,..., SSD#n. That is, the area 53 includes some physical blocks reserved for the SSD#1 namespace (NS#3) and some physical blocks reserved for the SSD#2 namespace (NS#3). And some physical blocks reserved for the SSD#3 namespace (NS#3) and some physical blocks reserved for the SSD#n namespace (NS#3).

The area 54 (NS#4) is also arranged across the SSD#1, SSD#2, SSD#3,..., SSD#n. In other words, the area 54 includes some physical blocks reserved for the SSD#1 namespace (NS#4) and some physical blocks reserved for the SSD#2 namespace (NS#4). And some physical blocks reserved for the SSD#3 namespace (NS#4) and some physical blocks reserved for the SSD#n namespace (NS#4).

The area 55 (NS#n) is also arranged across the SSD#1, SSD#2, SSD#3,..., SSD#n. That is, the area 55 includes some physical blocks reserved for the SSD#1 namespace (NS#n) and some physical blocks reserved for the SSD#2 namespace (NS#n). And some physical blocks reserved for the SSD#3 namespace (NS#n) and some physical blocks reserved for the SSD#n namespace (NS#n).

FIG. 26 shows a hardware configuration of the flash array storage shown in FIG.

The flash array storage 80 includes a flash array controller 81 in addition to the SSD#1, SSD#2, SSD#3,... SSD#n described above. The flash array controller 81 is configured to execute striping control for distributing data to SSD#1, SSD#2, SSD#3,... SSD#n. For example, when writing data to the area 51 (NS#1), for example, the first 4 Kbytes of data D1 are written to the area in SSD#1 corresponding to NS#1 and the next 4 Kbytes of data are written. D2 is written in the area in SSD#2 corresponding to NS#1, the subsequent 4K-byte data D3 is written in the area in SSD#3 corresponding to NS#1, and the subsequent 4K-byte data Dn is written in NS#. 1 is written in the area in SSD#n corresponding to 1, and the subsequent 4 Kbytes of data Dn+1 is written in the area in SSD#1 corresponding to NS#1.

In this way, the write data is distributed to SSD#1, SSD#2, SSD#3,... SSD#n in units of a predetermined data size (4 Kbytes). For example, when the host 2 is requested to write 1 Mbyte of data to NS#1, the 1 Mbyte of data is divided into a plurality of data portions each having a predetermined data size (4 Kbytes). May be written in parallel to SSD#1, SSD#2, SSD#3,... SSD#n.

In this way, SSD#1, SSD#2, SSD#3,... SSD#n operate in parallel, so that the performance for data write can be improved.

The flash array controller 81 may be provided in the host 2 instead of in the flash array storage 80 as shown in FIG.

FIG. 28 shows the relationship between the capacity of each SSD in the flash array storage 80 and the ratio of the capacity allocated from these SSDs to a certain tier.

Here, tier #1 (NS#1) will be described as an example. The host 2 sends an extended namespace management command to the flash array controller 81, and reserves a number of physical blocks corresponding to 1% of the total capacity of the flash array storage 80 for the tier #1 (NS#1). Demand what it should do. The flash array controller 81 is a physical block to be reserved for tier#1 (NS#1) in each SSD based on the respective capacities of SSD#1, SSD#2, SSD#3,... SSD#n. Determine the number of.

Here, it is assumed that the capacity of SSD#1 is 100 GB, the capacity of SSD#2 is 200 GB, the capacity of SSD#3 is 1 TB, and the capacity of SSD#n is 100 GB.

The flash array controller 81 sends an extended name space management command to the SSD#1 to indicate that the number of physical blocks corresponding to 1% capacity (1 GB) of 100 GB should be reserved for the NS#1. To request. The flash array controller 81 sends an extended namespace management command to the SSD#2 to indicate that the number of physical blocks corresponding to 1% capacity (2 GB) of 200 GB should be reserved for the NS#1. To request. The flash array controller 81 sends an extended name space management command to the SSD#3 to indicate that the number of physical blocks equivalent to 1% of 1 TB (10 GB) should be reserved for the NS#1. To request. The flash array controller 81 sends an extended name space management command to the SSD#n to notify the SSD#n that a number of physical blocks corresponding to 1% capacity (1 GB) of 100 GB should be reserved for the NS#1. To request.

FIG. 29 shows an example of a write operation corresponding to the capacity allocation of FIG.

When data is written to the area 51 (NS#1) by striping control, for example, the first 4 Kbytes of data D1 is written to the area in SSD#1 corresponding to NS#1. The next 4 Kbytes of data D2 and the subsequent 4 Kbytes of data D3 are written to the area in SSD#2 corresponding to NS#1. Subsequent data D3 to D13 are written in the area in SSD#3 corresponding to NS#1. The subsequent 4 Kbytes of data D14 are written in the area in SSD#n corresponding to NS#1, and the subsequent 4 Kbytes of data D15 are written in the area in SSD#1 corresponding to NS#1.

FIG. 30 shows a hardware configuration example of an information processing device that functions as the host 2.

This information processing device is realized as a server computer or a personal computer. This information processing apparatus 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 file system 43 functions as the layer management unit 44 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).

In this information processing apparatus, the processor 101 executes the following processing under the control of the host software (application software layer 41, OS 42, and file system 43).

The processor 101 sends an extended namespace management command to the SSD3 to create a namespace NS#1 (area 51) for Hot data in the SSD3. The extended namespace management command includes a parameter indicating the number of physical blocks to be assigned to the hot data namespace NS#1 (area 51).

The processor 101 sends an extended namespace management command to the SSD3 to create a namespace NS#2 (area 52) for Warm data in the SSD3. The extended namespace management command includes a parameter indicating the number of physical blocks to be assigned to the namespace NS#2 (area 52) for Warm data.

Similarly, the processor 101 sends an extended namespace management command to the SSD3 to create a namespace NS#n (area 55) for Cold data in the SSD3. The extended name space management command includes a parameter indicating the number of physical blocks to be assigned to the cold name space NS#n (area 55).

The processor 101 manages the namespace ID of the namespace NS#1 as a namespace ID for Hot data, the namespace ID of the namespace NS#2 as a namespace ID for Warm data, and the namespace NS. The namespace ID of #n is managed as a namespace ID for Cold data.

When it is necessary to write certain Hot data to SSD3, the processor 101 sends a write command including the namespace ID of the namespace NS#1 to SSD3. When it is necessary to write certain Cold data to SSD3, the processor 101 sends a write command including the namespace ID of the namespace NS#n to SSD3.

FIG. 31 shows a configuration example of an information processing apparatus 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 strobe 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 this embodiment, a plurality of namespaces (areas) for storing a plurality of types of data are managed, and furthermore, the amount of physical resources to be secured (the number of physical blocks) is designated. Based on a request from the host 2 which is designated for each space, a designated number of physical blocks are individually allocated as physical resources for these namespaces. Therefore, it is possible to easily and optimally allocate the physical block group to the plurality of namespaces (areas) in consideration of the capacities and the update frequencies of the plurality of types of data. Therefore, durability suitable for the frequency of updating the data to be stored can be realized for each namespace (area), and write amplification of the namespace (area) for data that is frequently updated can be reduced. Therefore, the life of the SSD can be maximized.

In other words, according to the present embodiment, a large amount of over-provision area is reserved for a namespace (area) for data that is frequently updated, and a namespace for data that is frequently updated ( It is possible to flexibly perform control such as securing a small amount of over-provision area for the area. As a result, the write amplification of the namespace (area) for data that is frequently updated can be reduced, so that the life of the SSD can be maximized.

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), and ReRAM (Resistive Random).
The present invention can also be applied to various other non-volatile memories such as Access Memory) or FeRAM (Ferroelectric Random Access Memory).

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 modifications thereof are included in the scope and the gist of the invention, and are also included in the invention described in the claims and an equivalent range thereof.

2... Host, 3... SSD, 4... Controller, 5... NAND memory, 51, 52, 53, 54, 55... Area.

Claims (10)

A non-volatile memory including a plurality of physical blocks,
A controller configured to manage a plurality of namespaces for logically dividing the non-volatile memory into a plurality of areas,
The controller is
A first request is received from a host device requesting creation of a first namespace, the first request being the number of logical addresses for the first namespace and physical resources to be reserved for the first namespace. Of the physical resources, the physical resource quantity indicates the number of physical blocks to be reserved for the first namespace or the number of physical blocks to be reserved for the overprovision area of the first namespace. ,
Create the first namespace,
When the amount of the physical resource designated by the first request indicates the number of physical blocks to be reserved for the first namespace, the number of physical blocks designated by the first request is set to the first block. The remaining capacity, which is allocated to the namespace and is the capacity of the number of physical blocks designated by the first request, minus the capacity of the user area to which the number of logical addresses designated by the first request is mapped, is Assigned as the overprovision area of the first namespace,
When the amount of the physical resource designated by the first request indicates the number of physical blocks to be reserved for the over-provision area of the first namespace, the number of physical blocks designated by the first request is Allocate the block as the over-provision area of the first namespace,
A memory system configured to write write data associated with an ID of the first namespace to a first area of the non-volatile memory corresponding to the first namespace. The controller is
A second request is received from the host device requesting the creation of a second namespace, the second request being the number of logical addresses for the second namespace and the physical address to be reserved for the second namespace. Both of the resource amounts are specified, and the physical resource amount is the number of physical blocks to be reserved for the second namespace or the number of physical blocks to be reserved for the over-provision area of the second namespace. Shows,
Create the second namespace,
When the amount of the physical resource designated by the second request indicates the number of physical blocks to be reserved for the second namespace, the second number of physical blocks designated by the second request is used. The remaining capacity, which is assigned to the namespace and is the capacity of the number of physical blocks designated by the second request, minus the capacity of the user area to which the number of logical addresses designated by the second request is mapped, is Assigned as the overprovision area of the second namespace,
When the amount of the physical resource designated by the second request indicates the number of physical blocks to be reserved for the overprovision area of the second namespace, the number of physical blocks designated by the second request is Allocate the block as the over-provision area of the second namespace,
2. The memory system according to claim 1, wherein the write data associated with the ID of the second name space is configured to be written in a second area of the non-volatile memory corresponding to the second name space. The first namespace is used to store a first type of data and the second namespace is used to store a second type of data that has a lower update frequency than the first type of data. ,
The ratio of the capacity of the over-provision area for the second namespace to the capacity of the user area of the second namespace is determined to be the over-provision area for the first namespace with respect to the capacity of the user area of the first namespace. The memory system according to claim 2, wherein the memory system has a capacity ratio lower than that of the memory system. The controller is
When the first request or the second request is received, it is determined whether or not the number of physical blocks designated by the received request can be allocated, and valid data in the nonvolatile memory is not stored. Judge based on the number of physical blocks,
The memory system according to claim 2, wherein when the specified number of physical blocks cannot be allocated, an error response is notified to the host device. The controller is configured to perform striping control for distributing data to a plurality of storage devices each including a non-volatile memory,
The memory system according to claim 1 or 2, wherein each of the plurality of namespaces is arranged across the plurality of storage devices. A control method for controlling a nonvolatile memory including a plurality of physical blocks, comprising:
Managing a plurality of namespaces that logically divide the non-volatile memory into a plurality of areas;
Receiving a first request from a host device requesting creation of a first namespace, said first request should be reserved for the number of logical addresses for said first namespace and for said first namespace. Both physical resource quantities are specified, and the physical resource quantity is the number of physical blocks to be reserved for the first namespace or the number of physical blocks to be reserved for the overprovision area of the first namespace. Indicates
Creating the first namespace,
When the amount of the physical resource designated by the first request indicates the number of physical blocks to be reserved for the first namespace, the number of physical blocks designated by the first request is set to the first block. The remaining capacity, which is allocated to the namespace and is the capacity of the number of physical blocks designated by the first request, minus the capacity of the user area to which the number of logical addresses designated by the first request is mapped, is Allocating it as the overprovision area of the first namespace,
When the amount of the physical resource designated by the first request indicates the number of physical blocks to be reserved for the over-provision area of the first namespace, the number of physical blocks designated by the first request is Assigning a block as an over-provision area of the first namespace;
Writing the write data associated with the ID of the first namespace into the first area of the non-volatile memory corresponding to the first namespace. Receiving a second request from the host device requesting creation of a second namespace, the second request securing a number of logical addresses for the second namespace and the second namespace. Specifying both the amount of physical resources to be allocated, the amount of physical resources being the number of physical blocks to be reserved for the second namespace or the physical blocks to be reserved for the overprovision area of the second namespace. Shows the number,
Creating the second namespace,
When the amount of the physical resource designated by the second request indicates the number of physical blocks to be reserved for the second namespace, the second number of physical blocks designated by the second request is used. The remaining capacity, which is assigned to the namespace and is the capacity of the number of physical blocks designated by the second request, minus the capacity of the user area to which the number of logical addresses designated by the second request is mapped, is Allocating it as an over-provision area in the second namespace,
When the amount of the physical resource designated by the second request indicates the number of physical blocks to be reserved for the overprovision area of the second namespace, the number of physical blocks designated by the second request is Assigning a block as an over-provision area of the second namespace;
7. The control method according to claim 6, further comprising writing write data associated with an ID of the second namespace to a second area of the nonvolatile memory corresponding to the second namespace. The first namespace is used to store a first type of data and the second namespace is used to store a second type of data that has a lower update frequency than the first type of data. ,
The ratio of the capacity of the over-provision area for the second namespace to the capacity of the user area of the second namespace is determined to be the over-provision area for the first namespace with respect to the capacity of the user area of the first namespace. The control method according to claim 7, which is lower than the ratio of the capacities. When the first request or the second request is received, it is determined whether or not the number of physical blocks designated by the received request can be allocated, and valid data in the nonvolatile memory is not stored. Determination based on the number of physical blocks,
The control method according to claim 7, further comprising: notifying the host device of an error response when the specified number of physical blocks cannot be allocated. Further comprising executing striping control for distributing data to a plurality of storage devices each including a non-volatile memory,
The control method according to claim 6 or 7, wherein each of the plurality of namespaces is arranged across the plurality of storage devices.

Images