JP6545876B2 - Memory system - Google Patents

Description

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

  BACKGROUND In recent years, memory systems provided with non-volatile memories are widely used.

  As one of such memory systems, a NAND flash technology based solid state drive (SSD) is known. SSDs are used as main storage for various computers due to their low power consumption and high performance.

  The types of SSDs include small capacity and high speed SSDs such as Single Level Cell (SLC) -SSD, Multi Level Cell (MLC) -SSD, and Large Capacity SSDs such as Triple Level Cell (TLC) -SSD.

  Usually, in the data center, these multiple types of SSDs are selectively used according to the application.

U.S. Pat. No. 8,621,328

  However, using a dedicated type of SSD for each data type is a factor that increases the total cost of ownership (TCO) of the data center.

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

  According to an embodiment, a memory system comprises a non-volatile memory comprising a plurality of physical blocks and a controller. The controller creates the first namespace and the second namespace based on the first namespace creation request and the second namespace creation request received from the host device. The controller corresponds to the first namespace according to an amount of data written by the host device to the area of the non-volatile memory corresponding to the first namespace and a garbage collection operation of the first namespace. The write amplification of the first namespace is calculated by counting the amount of data written to the non-volatile memory area. The controller corresponds to the second namespace according to an amount of data written by the host device to the area of the nonvolatile memory corresponding to the second namespace and a garbage collection operation of the second namespace. The write amplification of the second namespace is calculated by counting the amount of data written to the non-volatile memory area. The controller provides the host device with write amplification corresponding to the first namespace and the second namespace, respectively.

FIG. 1 is a block diagram showing a configuration example of a memory system according to an embodiment. The figure for demonstrating the relationship between a normal tiered storage system and a single tiered storage system. FIG. 6 is a view for explaining a plurality of tiers (tiers) set in the memory system of the embodiment. FIG. 6 is a view for explaining the relationship between a plurality of areas in the memory system of the embodiment and data written to these areas. FIG. 6 is a diagram for explaining management of a namespace in the memory system of the embodiment. FIG. 8 is a diagram for explaining an extended namespace management command applied to the memory system of the embodiment. The figure which shows the sequence of the physical resource allocation process performed by the memory system of the embodiment. 6 is a flowchart showing a procedure of physical resource allocation processing executed by the memory system of the embodiment. 6 is a flowchart showing the procedure of write command transmission processing executed by the host connected to the memory system of the embodiment; FIG. 6 is a view for explaining a write command applied to the memory system of the embodiment. FIG. 7 is a view showing a processing sequence of a write operation executed by the memory system of the embodiment. FIG. 7 is a diagram for explaining the garbage collection operation and the copy destination free block allocation operation which are executed by the memory system of the embodiment. FIG. 8 is a view for explaining the write data amount counting process executed by the memory system of the embodiment. 6 is a flowchart showing the procedure of a write data amount counting process executed by the memory system of the embodiment. 6 is a flowchart showing the procedure of write amplification (WA) calculation processing executed by the memory system of the embodiment. FIG. 6 is a view showing an example of return data transmitted from the memory system of the embodiment to the host. 5 is a flowchart showing the procedure of a counter reset process executed by the memory system of the embodiment. The figure which shows the extended garbage collection control command applied to the memory system of the embodiment. The flowchart which shows the procedure of the garbage collection operation | movement performed by the memory system of the embodiment. The figure for demonstrating the process which controls the ratio of an endurance code and ECC which are performed by the memory system of the embodiment. FIG. 6 is a view for explaining the encoding process and the decoding process performed by the memory system of the embodiment. The block diagram showing the example of composition of the endurance code encoder in the memory system of the embodiment. 6 is a flowchart showing the procedure of encoding processing executed by the memory system of the embodiment. 6 is a flowchart showing the procedure of write control processing executed by the memory system of the embodiment. FIG. 2 is a view showing the configuration of a flash array applied to the memory system of the embodiment. FIG. 2 is a view showing the configuration of a flash array storage of the embodiment. The figure which shows another structure of flash array storage of the embodiment. The figure for demonstrating the relationship between the total capacity of each SSD in the flash array storage of the embodiment, and the quantity of the physical resource which should be allocated to a hierarchy. FIG. 7 is a diagram for explaining the write operation of the flash array storage of the embodiment. FIG. 2 is a block diagram showing an example of the configuration of a host according to the first embodiment. The figure which shows the structural example of the computer containing the memory system and host of the 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.

  The memory system is a semiconductor storage device configured to write data to non-volatile memory and read data from non-volatile memory. This memory system is implemented, 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 apparatus such as a server or a personal computer.

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

  As an interface for interconnecting the host 2 and the 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.

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

  Physical blocks B0 to Bm-1 include many 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 read and data write are executed page by page. Data erasure is performed in physical block units.

  The controller 4 is electrically coupled to a NAND memory 5 which is a non-volatile memory via a NAND interface 13 such as Toggle or 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.

  Data management includes (1) management of mapping information indicating a correspondence between a logical block address (LBA) and a physical address, and (2) concealing read / write in page units and erase operation in block units. Processing, etc. are included. Management of the mapping between LBA and physical addresses is performed using a look-up table (LUT) 33. The physical address corresponding to a certain LBA indicates the storage position in the NAND memory 5 to which the data of this LBA is written. Physical addresses include physical page addresses and physical block addresses. Physical page addresses are assigned to all pages, and physical block addresses are assigned to all physical blocks.

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

  Thus, the controller 4 maps the 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 look-up table (LUT) 33 to associate this LBA with this other page and invalidates the original page (that is, the old data to 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 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. A block in which only invalid data is copied by copying valid data to another block is released as a free block. This allows this block to be reused after erasure.

  The host 2 sends a write command to the SSD 3. The 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 a logical address, but in other embodiments, object ID may be used as a logical address. The LBA is represented by a serial number assigned to a logical sector (size: eg 512 bytes). Serial numbers start from zero. The controller 4 of the SSD 3 writes the write data specified by the starting logical address (Starting LBA) and the transfer length in the write command to the physical page of the physical block in the NAND memory 5. Furthermore, the controller 4 maps the LBA corresponding to the written data to the physical address corresponding to the physical storage position where the data is written by updating the look-up table (LUT) 33.

  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, the NAND interface 13, the DRAM interface 14, and the 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 specified 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 specified by this read command. The read command includes the LBA of the leading logical block and the transfer length (the number of logical blocks).

  Extended namespace management commands are extended commands of ordinary namespace management commands.

  Generally, host software can only specify the number of logical block addresses (LBA) for a namespace, and actually specify the number of physical blocks (nonvolatile memory capacity) to be allocated for this namespace. I can not do it. That is, normally, the size of the namespace is based on the number of LBA requested in the namespace creation 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 a namespace is 90 Mbytes and the capacity of one physical block is 100 Mbytes, the controller of a normal SSD will name one physical block with 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, the controller of a normal SSD will name two physical blocks May be allocated for space. However, in such an SSD-dependent physical block allocation method, host software can not request the SSD to create namespaces with different characteristics (durability).

  The extended namespace management command can not only specify the number of logical block addresses (LBA) for namespace for SSD 3 but also specify the number of physical blocks to be allocated for this namespace for SSD 3 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 enables host 2 (host software) to reserve a number of physical blocks suitable for the workload in host 2 for each namespace. Generally, as the number of physical blocks allocated to a namespace increases, the durability of that namespace can be improved. Thus, host software can create namespaces with different characteristics (durability) by using extended namespace management commands.

  The extended garbage collection control command is a host-initiated garbage collection command extension command for controlling the garbage collection operation of the SSD 3 by the host 2. The extended garbage collection control command can specify, for the SSD 3, a namespace to be subjected to garbage collection. That is, the extended garbage collection control command includes a parameter indicating a target namespace in which garbage collection is to 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 and the like for processing various commands from the host 2 in addition to the processing of the FTL layer described above.

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

  The namespace control unit 21 has a multi-namespace management function for managing a plurality of namespaces. The namespace corresponds to a type 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 the creation request of each namespace from the host 2. In other words, the namespace control unit 21 logically divides the NAND memory 5 into a plurality of areas (namespaces) based on the creation request of each namespace from the host 2. The host 2 can request the SSD 3 to create each of the namespaces using the extended namespace management command described above. The namespace control unit 21 assigns the physical blocks of the number specified by the host 2 to these individual areas (namespaces). These multiple areas (namespaces) are used to store multiple types of data having different update frequencies.

  For example, frequently updated types of data (Hot data) are written to specific areas for storing Hot data. Hot data may be referred to as dynamic data. Data with a low frequency of updating (Cold data) is written to a specific separate area (tier) for storing 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 (tier) storages.

  The plurality of areas are respectively associated with a plurality of namespaces. This makes it easy for the host software to associate the Hot data with the ID of a particular namespace and to associate the Cold data with an ID of another namespace, to facilitate the tiers in which these data should be written. It can be specified.

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

  This is because, in a physical block in which Hot data and Cold data are mixed, updating of the Hot data invalidates only part of the data in the physical block at an early timing, while the remaining data part in the physical block ( Cold data may be maintained in the valid state for a long time.

  The write amplification (WA) is defined as follows.

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

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

  If the physical block is filled with only Hot data, it is likely that all data in this block will be invalidated relatively quickly by updating the data. Therefore, this block can be reused only by erasing this block without performing garbage collection.

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

  In the present embodiment, multiple types of data having different update frequencies are written to different areas (different namespaces). For example, Hot data is written to an area associated with a particular namespace (NS # 1), and Cold data is written to another area associated with another particular namespace (NS # n). Ru. Therefore, it is possible to prevent the occurrence of a situation where 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 can result in reduced light amplification.

  Furthermore, in the present embodiment, the namespace control unit 21 sets a desired number of physical blocks in each area (namespace) based on a request from the host 2 for designating the number of physical blocks to be secured for each namespace. Assign individually to

  For example, when the host 2 wants to create a new namespace, the host 2 sends to the SSD 3 an extended namespace management command including a parameter indicating the number of physical blocks to be secured for the target namespace. The namespace control unit 21 creates a namespace (NS # 1), and assigns the number of physical blocks specified by the parameter to this namespace (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 secured for the target namespace. As a result, a plurality of namespaces (areas) are created, and the NAND memory 5 is logically divided into the 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 (the number of LBA) of the individual areas and the durability to be set in the respective areas. Can be allocated to

  The write amplification calculation unit 22 calculates not the write amplification of the entire SSD 3 but the write amplification of each name space (each area). Thereby, 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 the garbage collection operation in namespace units (area units), thereby preventing Hot data and Cold data from being mixed in the same physical block. More specifically, when the garbage collection operation control unit 23 receives an extended garbage collection control command from the host 2, the garbage collection operation control unit 23 determines the physical property assigned to the target namespace specified by the extended garbage collection control command. From the blocks, select the target physical blocks for garbage collection. Then, the garbage collection operation control unit 23 executes a garbage collection operation of copying the valid data from the target physical block group to the copy destination free block.

  Furthermore, the garbage collection operation control unit 23 manages free blocks created by the garbage collection operation executed for each namespace as shared free blocks shared by these namespaces. That is, these free blocks are shared among namespaces. The garbage collection operation control unit 23 selects the free block of 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.

  Generally, the number of free block program / erase times created by the area garbage collection operation for Cold data is far less than the number of program / erase times of the free block created by the area garbage collection operation for Hot data . This is because, once a certain amount of Cold data is once written in the area for Cold data, the Cold data is not updated frequently, or is updated infrequently in many cases. On the other hand, the number of program / erase times of free blocks created by the garbage collection operation of the area for Hot data is usually relatively large. Therefore, the above-mentioned operation of allocating the free block of the minimum program / erase count as the copy destination free block automatically makes the block with a small program / erase count used in the area for cold data into the area for hot data. Allow to assign to.

  The wear / retention control unit 24 trades between reliability (data retention) and durability (DWPD value) by controlling the ratio between a code for suppressing memory cell wear and an error correction code (ECC). Take action to optimize off. As a result, the durability of the area for Hot data can be improved, and data retention of the area for Cold data (retention time of written data) 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 to the NAND memory 5. In addition, the storage area of the DRAM 6 may be used as a GC buffer 32 for temporarily storing data moved during a garbage collection (GC) operation. Also, the storage area of the DRAM 6 may be used to store the above-described look-up table 33. The look-up table 33 includes a plurality of look-up tables (LUT # 1, LUT # 2, ...) respectively corresponding to a plurality of namespaces in order to be able to execute independent garbage collection (GC) operations for each namespace. It may be divided into.

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

  The host 2 is an information processing apparatus that executes various programs. The programs executed by the information processing apparatus 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 entire host 2 and controls the hardware in the host 2 and performs control to enable the application to use the hardware and the SSD 3 Is configured software.

  The file system 43 is used to control file operations (creation, storage, update, deletion, 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 application software layer 41. Examples of application software threads include client software, database software, virtual machines, etc.

  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 a 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 the present 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 (region) for Hot data and a namespace (region) for Cold data. The hierarchy management unit 44 sends, to the SSD 3, an extended namespace management command including a parameter indicating the number of physical blocks to be allocated to the namespace (area) for Hot data. When a 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 a namespace ID for Hot data. Next, the hierarchy management unit 44 sends to the SSD 3 an extended namespace management command including a parameter indicating the number of physical blocks to be allocated to the namespace (area) for Cold data. When a 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 a namespace ID for Cold data.

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

  When it is necessary to read certain Hot data, the hierarchy management unit 44 sends a read command including a namespace ID for 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 a namespace ID for Cold data to the SSD 3.

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

  In the tiered storage system shown in the left part of FIG. 2, three types of SSDs are used depending on applications. The SSD for 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 of information per memory cell. For this reason, the SSD for tier (T1) is a high price SSD.

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

  One of the indicators showing the durability of SSD is DWPD (Drive Write Per Day). For example, DWPD = 10 means that for SSDs having a total capacity of 1 Tbyte, writing of 10 Tbytes (= 10 × 1 T bytes) of data can be performed daily for five years. 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 contents of the file.

  The SSD for 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 tier (T2) is used as storage for data that is updated less frequently than metadata. DWPD = 1 may be required for SSDs for 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 tier (T3) is a low-cost, high-capacity SSD. This large capacity SSD may be, for example, MLC-SSD or TLC-SSD. The SSD for tier (T3) is used as storage of data that is rarely updated. In SSDs for tier (T3), durability as low as about 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 tiered storage system in which all data of three tiers T1 to T3 are stored in one SSD. The DWPD required for the entire single-tiered storage system can be determined as follows.

DWPD = (10 x 0.01) + (1 x 0.04) + (0.1 x 0.95) = 0.235
Thus, the application of a single tiered storage system significantly increases the capacity required for the SSD but reduces the durability required for the SSD. MLC-SSD or TLC-SSD is suitable for realizing low cost and high 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 comparable to that of SLC-SSD. Therefore, even with a single-tiered storage system that uses low-cost, high-capacity SSDs, it is almost equivalent to a tiered storage system by adding a function to optimize the durability relationship between multiple tiers. Equivalent durability and performance can be obtained.

  FIG. 3 shows an example of allocation of physical resources among a plurality of areas (namespaces) in the SSD 3 (SSD # 1) of the present embodiment.

  The storage space of the SSD # 1 includes, for example, areas 51, 52, 53, 54 for storing plural types of data (Hot data, Warm data, Middle data, Middle data, Cool data, Cold data) having different update frequencies, respectively. 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 frequency of the update. The data update frequency is reduced in the order of Hot data, Warm data, Middle data, Cool data, and Cold data. Warm data, middle data, and cool data are data having an update frequency intermediate between hot data and cold data.

  The area 51 is used as tiered 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) of small capacity and 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%. The example of the DWPD required for the area 51 may be ten.

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

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

  The area 54 is used as tiered storage (tier # 4) for storing the Cool data. The area 54 is associated with a namespace (NS # 4). 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 the DWPD required for the area 54 may be 0.3.

  The area 55 is used as tiered storage (tier # n) for storing Cold data. The area 55 is associated with a namespace (NS # n). The area 55 is used to store large capacity / 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 update of the area 55 is about 1/100 of the frequency of update of the area 51. Therefore, the example of the DWPD required for the area 55 may be 0.1.

  Thus, Hot data, Warm data, Middle data, Cool data, and Cold data are stored in different areas. Therefore, it is possible to prevent the occurrence of 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 physical resources are distributed to a plurality of areas 51 to 55 at a ratio as shown in FIG. 3, the DWPD required for the entire SSD 3 (SSD # 1) can be obtained as follows.

  DWPD = (10 × 0.01) + (3 × 0.02) + (1 × 0.03) + (0.3 × 0.14) + (0.1 × 0.8) = 0.312 In principle, this means that in regions 51 to 55 logically The divided SSD3 (SSD # 1) means that it can be realized by a large capacity / low priced SSD.

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

  If multiple tiers are realized by different SSDs, the size of each tier can not be changed unless the used SSD itself is replaced. In the present embodiment, the same single 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 in each tier (area).

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

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

  Here, the over-provisioning area will be described.

  Over-provisioning means allocating a storage capacity in the SSD 3 which is invisible to the host 2 as available user space (user accessible LBA space). A space to which a storage capacity invisible to the host 2 as a user accessible LBA space is allocated is an over-provisioned area. Over-provisioning allocates physical blocks having a capacity exceeding the user accessible LBA space (the capacity of the user area).

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

  On the other hand, in the present embodiment, the physical blocks of the number specified by the host 2 can be allocated to each name space (area), and as a result, the over-provisioning area of the desired capacity is formed for each area. It 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 presence of the over-provisioned area 51b improves the durability and performance of the user area 51a in the area 51.

  With respect to each of the other areas, the remaining capacity obtained by subtracting the capacity of the user area in this area from the capacity determined by the total number of physical blocks allocated to this area functions as an over-provisioned area in this area. .

  Similar to the area 51 for Hot data, the host software also allocates a number of physical blocks exceeding the expected total amount of Warm data (the capacity of the user area) for the area 52 (tier # 2) for Warm data. You may request SSD3. In response to this request, the controller 4 of the SSD 3 allocates a designated number of physical blocks dedicated to the area 52 for Warm data to the area 52 (tier # 2) for this Warm data. For example, if the expected total amount of Warm data (user data capacity) is 200 Gbytes and assignment of physical blocks corresponding to 250 Gbytes is requested by the host software, controller 4 corresponds to 250 Gbytes. The physical blocks of the number are allocated to the area 52 (tier # 2). As a result, a physical resource that is 50 GB larger than the capacity of the user area of area 52 (tier # 2) is allocated to area 52 (tier # 2). The remaining 50 GB of physical resources obtained by subtracting the capacity of the user area from the physical resources of 250 Gbytes function as an over-provision area of 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 regard to the area 55 (tier # n) for Cold data, the host software assigns to SSD 3 the allocation of the minimum number of physical blocks determined in consideration of the expected total amount of Cold data (capacity of user data). You may request it. In response to this request, the controller 4 allocates a designated number of physical blocks dedicated to the area 55 (tier # n) for cold data to the area 55 (tier # n) for cold data. For example, if the expected total amount of Cold data (user data capacity) is 8000 Gbytes, and the host software requires allocation of physical blocks corresponding to 8001 Gbytes, the controller 4 corresponds to 8001 Gbytes. The physical blocks of the number are allocated 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 of physical resources obtained by subtracting user data capacity from 8001 Gbytes of physical resources functions as an over-provisioning area of area 55 (tier # n).

  As described above, the SSD 3 assigns the designated number of physical blocks to each area based on the request from the host 2 that designates the number of physical blocks to be secured for each namespace. As a result, the ratio of the over-provisioned area capacity to the user area capacity 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 is, the more the over-provisioned area is allocated. In this case, for example, the ratio of the capacity of the over provisioned area in area 55 to the capacity of the user area in area 55 is calculated from the ratio of the capacity of the over provisioned area in area 51 to the capacity of the user area in area 51 Also becomes smaller.

  In the area 51, it is possible to effectively reduce the light amplification of the area 51 by utilizing the large size over-provision area. Because, even if the physical blocks of user area 51a of area 51 are filled with 100 M bytes of data, as a result, these physical blocks will not contain usable pages without erasing the blocks, This is because physical blocks in the over-provisioning area 51b can be used to write data instead of blocks. Therefore, the timing at which the garbage collection operation of the area 51 is performed can be sufficiently delayed. As data is written to the physical blocks in the over-provisioning area 51b, the data in the physical blocks in the user area 51a is invalidated by the update. Physical blocks for which all data has been invalidated can be reused without its garbage collection. Therefore, since the write amplification in the area 51 can be efficiently reduced, the number of write / erase times of the physical block group in the area 51 can be suppressed low. This means that the durability of the region 51 can be improved.

  Since the over-provisioning area of the area 55 is small, the light amplification of the area 55 is increased. However, the update frequency of the area 55 for Cold data is much lower than the update frequency of the area 51 for Hot data. For example, the update frequency of the area 55 for Cold data is 1/100 of the update frequency of the area 51 for Hot data. That is, since the area 55 is rewritten only once while the area 51 is rewritten 100 times, the number of programming / erasing times of each physical block of the area 55 of Cold data is very small. Therefore, with regard to the area 55 of Cold data, even if the write amplification is large, the number of program / erase times of the physical block group of the area 55 of Cold data immediately reaches the program / erase times upper limit value of SSD3. There is no occurrence of the phenomenon of

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

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

  FIG. 5 shows namespace management by the SSD 3.

  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 assigned to the namespace NS # 1. A logical address space (LBA space) A2 of 0 to E1 is assigned to the namespace NS # 2. Similarly, logical address spaces (LBA spaces) An of 0 to En are assigned to the namespace NS # n.

  In the present embodiment, the lookup table LUT is divided for each namespace. That is, the 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 look-up 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 the namespaces NS # 1 to NS # n.

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

  FIG. 6 shows extended namespace management commands.

  Extended namespace management commands are used for namespace management, including creation and deletion of namespaces. Extended namespace management commands include the following parameters:

(1) Create / delete (2) LBA range (3) Physical resource size (4) tier attribute (optional)
The create / delete parameter value 0h requests the SSD 3 to create a namespace. The creation / deletion parameter value 1h requests the SSD 3 to delete the namespace. When deletion of a namespace is requested, 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 (LBA 0 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 over-provision size instead of the physical resource size parameter.

  The over-provision size parameter indicates the number of physical blocks to be reserved for the over-provisioned area in the area associated with the namespace. If the extended namespace management command includes an over-provisioned size parameter, then SSD3 creates a namespace and is specified by this parameter in the over-provisioned area within the area associated with this namespace. As many physical blocks may be allocated.

  The parameter of the tier attribute indicates the tier attribute corresponding to this namespace. The relationship between the value of the parameter of the tier attribute 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 to the SSD 3 an extended namespace management command requesting creation of a namespace (area for Hot data). This extended namespace management command includes a physical resource size parameter that specifies the number of physical blocks to be secured for the area for Hot data. 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 area for Hot data. 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 designated 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 namespace management command to the SSD 3 requesting creation of the next namespace (area for Warm data). This extended namespace management command includes a physical resource size parameter that specifies the number of physical blocks to be secured for the area for Warm data. 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 designated 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 an extended namespace management command to the SSD 3 requesting 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 to be secured 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 designated 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 manner, the process of creating the namespace is repeated while assigning the designated number of physical blocks to the namespace, whereby the NAND memory 5 is logically divided into a plurality of areas, and further designated for each area. The assigned number of physical blocks is allocated.

  The flowchart of FIG. 8 shows the procedure of 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 the extended namespace management command requests 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 creation of a namespace (YES in step S22), can the controller 4 secure the number of physical blocks specified by the physical resource parameter in the extended namespace management command? 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 equal to or greater than the designated number (YES in step S23), the controller 4 creates a namespace, and assigns the designated number of physical blocks to the area associated with this namespace. Allocate (step S24). The controller 4 notifies the host 2 of the completion of the command (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 an error may change the number of physical blocks to be secured. Alternatively, the host 2 notified of the error response may re-do the process of creating each namespace while specifying the number of physical blocks to be secured for each namespace.

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

  The host 2 classifies this write data (data to be written) as Hot data, Warm data, Middle data, Cool data, or Cold data when a request to write data occurs (YES in step S31) S32). The host 2 classifies write data (data to be written) as Hot data, Warm data, Middle data, Cool data, or Cold data according to data types such as metadata and file contents (content), for example. It is also 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 namespace for cold data 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 top LBA indicates the top LBA of the data to be written.

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

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

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

  The host 2 sends a write command to the SSD 3 and sends write data to the SSD 3. 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 the command completion command completion. Thereafter, 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 the garbage collection operation and the copy destination free block allocation operation performed by the SSD 3.

  As mentioned above, garbage collection operations are performed on a per namespace basis. In the garbage collection operation of the namespace (NS # 1), the controller 4 of the SSD 3 selects a target physical block for garbage collection from the physical block (active block) in the area 51 associated with the namespace (NS # 1). select. For example, the controller 4 may identify the upper few physical blocks having the largest ratio of invalid data by referring to the lookup table LUT # 1 and select this physical block as a target physical block for garbage collection. .

  The controller 4 manages a free block pool (free block list) 60 including free blocks shared among namespaces. The controller 4 selects the free block of the minimum program / erase count from the free block group. The controller 4 assigns the selected free block to the namespace (NS # 1) as a 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 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 contain 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 a target physical block of garbage collection from the physical block (active block) in the area 55 associated with the namespace (NS # n). select. For example, the controller 4 may identify the upper few physical blocks having the largest ratio of invalid data by referring to the lookup table LUT # n, and select this physical block as a target physical block for garbage collection. .

  The controller 4 selects the free block of the minimum program / erase count from the free block group. The controller 4 assigns 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 for garbage collection (here, blocks B2000 to B2003) to the copy destination free block B1001. Then, the controller 4 updates the lookup table LUT # n and maps 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 contain valid data. These free blocks are moved to the free block pool.

  As mentioned above, the frequency of updating namespace (NS # n) is much lower than the frequency of updating namespace (NS # 1), so it was created by garbage collection of namespace (NS # n) There are few program / erase times of free blocks. In the garbage collection operation of this embodiment, every time garbage collection of a namespace (NS # 1) is performed, a physical block used in the past in the namespace (NS # n) becomes a namespace (NS # 1). Is allocated as a copy destination free block of Therefore, it is possible to effectively reuse, in the namespace (NS # 1), physical blocks with a low program / erase count that have been used in the namespace (NS # n). As a result, the durability of the namespace (NS # 1) can be improved.

  Furthermore, 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 For example, the program / erase count of any physical block of physical blocks used in the namespace (NS # 1) is a threshold count (the threshold count is set to a value smaller than the upper limit of the program / erase count) When the controller 4 has reached, the physical block may be replaced with the physical block of the minimum program / erase count in the name space (NS # n).

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

  The controller 4 of the SSD 3 can calculate not the write amplification of the entire SSD 3 but the write amplification for each name space. For this purpose, the controller 4 has two kinds of counters, one for counting the amount of data written by the host 2 and the other for counting the amount of data written by the garbage collection operation. Prepare every time.

  The counters 61 and 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 to the namespace (NS # 1), that is, the area 51 by garbage collection of the namespace (NS # 1).

  The counters 63 and 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 to the namespace (NS # 2), that is, the area 52, by garbage collection of the namespace (NS # 2).

  The counters 65 and 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 to the namespace (NS # n), that is, the area 55, by 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 a write command from the host 2, the controller 4 determines a target namespace (area) in 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 to 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 a namespace (NS # 1) (YES in step S41), the controller 4 uses the counter 61 to write data 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 calculate the amount of data to be written to the namespace (NS # 2). It counts (step S45). In step S45, the current count value of the counter 63 may be increased by the transfer length of the write data.

  If the target namespace (area) is a namespace (NS # n) (YES in step S43), the controller 4 uses the counter 65 to calculate the amount of data to be written to the namespace (NS # n). It counts (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 is written to the namespace (NS # 1) by this garbage collection operation using the counter 62. 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 is written to the namespace (NS # 2) by this garbage collection operation using the counter 64. 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 is written to the namespace (NS # n) by this garbage collection operation using the counter 66. 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 to 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 to 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). 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 to 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). 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 to 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 to 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). 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 for requesting write amplification of each namespace is received from the host 2 (YES in step S70), the controller 4 sends the host 2 the return data shown in FIG. The host 2 is notified of the write amplification of (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 performed 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 the occurrence of a specific reset event such as the change of the setting of the SSD 3. An example of the change of the setting of the SSD 3 may be a change of the setting of a certain namespace or a deletion of a certain namespace. Alternatively, an example of changing the setting of the SSD 3 may be changing the setting of the entire SSD 3.

  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 the reception of this command, the SSD 3 may reset the counters 61 to 66 corresponding to all namespaces. If this command includes a namespace ID, the SSD 3 may reset only 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 entire SSD 3 may be treated as this request. The change of 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.

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

  When the controller 4 receives from the host 2 a control command requesting to change the setting of the namespace, the controller 4 determines a 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 parameters in the control command (step S82). The controller 4 clears the count values of the counters 61 and 62 corresponding to the name space (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 parameters 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 a namespace (NS # n) (YES in step S87), the controller 4 changes the setting of the namespace (NS # n) according to the parameters in the control command (step S88). The controller 4 clears the count values of the counters 65 and 66 corresponding to the name space (NS # n) to zero (step S89).

  FIG. 18 shows extended garbage collection (GC) control commands.

  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 any 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 namespace ID parameter indicates the ID of the target namespace for which garbage collection is to be performed.

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

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

  Host 2 requests SSD 3 to execute garbage collection of any namespace in namespace (NS # 1) to namespace (NS # n) by using extended garbage collection (GC) control command Can.

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

  Alternatively, when the host 2 desires to write data to a namespace (area) with good latency, the host 2 performs an extended garbage collection (GC) control command including the namespace ID of this namespace. It may be sent to the SSD 3.

  In response to receiving an extended garbage collection (GC) control command from host 2, controller 3 of SSD 3 performs a garbage collection operation to reserve a specified amount of free space for the target namespace. Run. The controller 4 ends the garbage collection operation when the designated 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 performed 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 S 91), the controller 4 selects the target name specified by the namespace ID in the extended garbage collection (GC) control command The space garbage collection operation is executed (step S92). In step S92, the controller 4 selects some physical blocks to be garbage collected from the active blocks in the target namespace, and copies valid data of these physical blocks to the copy destination physical block.

  The garbage collection operation is ended when the designated 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 a code for suppressing memory cell consumption to an error correction code (ECC) according to a name space (area) in which data is to be written.

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

  Here, an outline of an operation of encoding write data using a code (coding) for suppressing memory cell consumption per one write 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 cell, and the first coded data (written as "endurance code" in FIG. 20) Generate part). This code (coding) 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 memory cells heavily. As this code (coding), for example, there is the above-mentioned endurance code (endurance coding) or the like.

  For example, in the MLC, the memory cell is in a state corresponding to any one of four levels (“E” level, “A” level, “B” level, “C” level) corresponding to 2 bits by programming. Program level is set. The "E" level is in 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 state of "C" level is a state (program level) of causing the memory cell to be depleted.

  In encoding using a code (coding) for suppressing memory cell exhaustion, for example, a code corresponding to a specific level (for example, "C" level) where memory cell exhaustion is large is another code (for example, Two "B" levels may be converted to a long bit pattern corresponding to consecutive "B-B".

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

  The controller 4 adds an error correction code (ECC) to the first encoded data (“endurance code” in FIG. 20) obtained by the encoding, whereby the second encoded data (“endurance code” and “endurance code” in FIG. Data) and write the second encoded data 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.

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

  As the first encoded data (endurance code) is longer, the frequency of appearance of a specific code that consumes memory cells more and more is reduced. Therefore, the consumption of the memory cell per one write can be suppressed as the first encoded data (endurance code) becomes longer.

  For example, if the write data is write data to be written to the area for Hot data, the controller 4 may use the first encoded data longer than the longer first encoded data to enhance the durability (DWPD) of the area for Hot data. The ratio of the first encoded data to the error correction code is controlled to obtain second encoded data including a combination of short error correction codes. That is, in the writing of Hot data, an encoding method that prioritizes durability over reliability (data retention) is used.

  On the other hand, if the write data is the write data to be written to the area for Cold data, the controller 4 may make the first encoded data shorter to extend the data retention of the data to be written to the area for Cold data. The ratio of the first encoded data to the error correction code is controlled to obtain second encoded data including a combination of the second and the third error correction codes. That is, in the writing of Cold data, an encoding method is used in which reliability (data retention) is prioritized over durability.

  In the present embodiment, as shown in FIG. 20, as the name space (area) has a higher rewrite frequency (update frequency), the bit length of the ECC becomes shorter, and instead, the first encoded data (endurance code) Bit length of Further, as the name space (area) in which the rewrite frequency (update frequency) is lower, the bit length of the ECC becomes longer, and instead, the bit length of the first encoded data (endurance code) becomes shorter.

  As the ECC bit length increases, the number of correctable bits increases, and thus the reliability (data retention) is improved. Usually, the bit error rate increases with the passage of time. Thus, increasing the number of correctable bits can improve data retention.

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

  FIG. 21 shows the encoding process and the decoding process performed 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, a systematic code is used to generate an ECC. Examples of the systematic code include a Hamming code, a BHC code, a Reed Solomon code, and the like.

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

  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 appearing 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 losslessly compress the write data. The codebook 913 shows the correspondence between each bit pattern appearing in the write data and the conversion code corresponding to the bit pattern. The compression unit 912 assigns a short conversion code to a bit pattern with a high frequency of occurrence.

  The search unit 914 searches for compressed data (compressed write data), for example, from the most significant bit thereof, for a specific code that causes the memory cell to be heavily consumed. The specific code may be, for example, a bit pattern corresponding to the “C” level. The replacing unit 915 replaces the specific code searched by the searching unit 914 with another long code (for example, a long bit pattern corresponding to “BB”, etc.). As a result, a specific code in compressed data is converted to another long code that consumes less memory cells. The replacement unit 915 updates the codebook 913, thereby replacing the specific conversion code in the codebook 913 corresponding to the specific code described above with the other long code described above.

  The code length check unit 916 checks the code length (bit length) of the current compressed data. If the code length (bit length) of the current compressed data is shorter than a predetermined threshold (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 name space (area) has a higher rewrite frequency (update frequency). In other words, the bit length of the encoded data (endurance code) becomes shorter as the name space (area) has a lower rewrite frequency (update frequency).

  The output unit 917 outputs the compressed data of the optimized bit length as 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 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 the compressed data using a code for suppressing consumption of memory cells.

  In this case, the controller 4 first searches the compressed data for a specific code (specific bit pattern) that causes the memory cell to be consumed (step S3). The controller 4 converts the searched code (bit pattern) into another long code (bit pattern) with a small consumption of memory cells (step S4). The controller 4 updates the conversion code in the codebook corresponding to the searched specific code (step S5).

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

  If the bit length of the current compressed data (coded data) is shorter than the target bit length, the processes of steps S3 to S5 are performed again. The more frequently 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 more heavily. Accordingly, the bit length of the encoded data becomes longer.

  If the bit length of the current compressed data (coded 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 coded data (step S7) .

  The flowchart in 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 namespace (area) the write data to be received is the write data to be written, and the encoding method for encoding the write data according to the determination result Change The change of encoding method is implemented by controlling the ratio of endurance code to ECC.

  That is, when the controller 4 of the SSD 3 receives a write command from the host 2 (YES in step S101), the controller 4 determines the hierarchical attribute (Hot / Hot) of the target namespace (area) specified 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-provisioned area of the target namespace (area) (e.g., the ratio between the user area and the over-provisioned area). Alternatively, if the extended namespace management command which requested creation of the target namespace includes the tier attribute parameter, the controller 4 sets the hierarchical attribute indicated by the tier attribute parameter to the hierarchical attribute of the target namespace. It may be determined that Alternatively, the write command may include the 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 durability over reliability by control (step S104). According to the encoding method here, 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 available 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 of the endurance code to the ECC. The write data is encoded using an encoding method in which reliability is prioritized over durability by control (step S107). According to the encoding method herein, 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 available 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 as one storage device from the host 2. The flash array storage includes a plurality of SSDs, that is, SSD # 1, SSD # 2, SSD # 3,..., SSD # n, which are striping-controlled to realize large capacity and high speed.

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

  In the flash array, the area 51 (NS # 1) is disposed across the SSD # 1, the SSD # 2, the SSD # 3,..., The SSD # n. In other words, 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, the SSD # 2, the SSD # 3,..., The SSD # n. In other words, 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, the SSD # 2, the SSD # 3,..., The SSD # n. In other words, 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 disposed across the SSD # 1, the SSD # 2, the SSD # 3,..., The SSD # n. In other words, 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, the SSD # 2, the SSD # 3,..., The SSD # n. In other words, 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 the hardware configuration of the flash array storage of FIG.

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

  As described above, the write data is distributed to the SSDs # 1, SSDs # 2, SSDs # 3,..., SSDs #n in units of a predetermined data size (4 K bytes). For example, when the host 2 is required 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 K bytes), and these data portions May be written in parallel to SSD # 1, SSD # 2, SSD # 3,... SSD # n.

  As described above, since the SSD # 1, the SSD # 2, the SSD # 3,..., The SSD # n operate in parallel, the performance for data writing can be enhanced.

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

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

  Here, tier # 1 (NS # 1) will be described as an example. The host 2 sends an extended name space management command to the flash array controller 81 to reserve physical blocks corresponding to 1% of the total capacity of the entire flash array storage 80 for tier # 1 (NS # 1). Require to do things. The flash array controller 81 is a physical block to be secured for tier # 1 (NS # 1) in each SSD based on the capacity of each of SSD # 1, SSD # 2, SSD # 3, ... SSD # n. Determine the number of

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

  The flash array controller 81 sends an extended name space management command to the SSD # 1 and the SSD # 1 has the number of physical blocks equivalent to 100 GB of 1% capacity (1 GB) to be secured for NS # 1. To request. The flash array controller 81 sends an extended name space management command to the SSD # 2 to make it possible to reserve the physical blocks corresponding to 200 GB of 1% capacity (2 GB) for the NS # 1. To request. The flash array controller 81 sends an extended name space management command to the SSD # 3 to make it possible to reserve the physical blocks corresponding to the 1 TB capacity (1 GB of capacity (10 GB)) for the NS # 1 using the SSD # 3. To request. The flash array controller 81 sends an extended namespace management command to the SSD # n, and the SSD # n is to reserve the physical blocks of the number corresponding to one 100 GB capacity (1 GB) (1 GB). To request.

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

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

  FIG. 30 shows an example of the hardware configuration of the information processing apparatus functioning as the host 2.

  This information processing apparatus is realized as a server computer or a personal computer. The 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 the 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 random access memory such as DRAM. Programs executed by the processor 101 include the application software layer 41, the OS 42, and the file system 43 described above. The file system 43 functions as the hierarchy 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. The 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 communications with peripheral devices such as USB devices.

  The controller 107 is configured to execute communication with devices respectively connected to the plurality of connectors 107A. In the present embodiment, the plurality of SSDs 3 are respectively connected to the plurality of connectors 107A. 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 execute power management of the information processing apparatus. The EC 108 powers on and off the information processing apparatus according to the user's operation of the power switch. The EC 108 is implemented as a processing circuit such as a one-chip microcontroller. The EC 108 may incorporate a keyboard controller that controls an input device such as a keyboard (KB).

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

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

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

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

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

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

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

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

  The system board (motherboard) 202 is disposed in the housing 201. On the system board (motherboard) 202, various electronic components including a CPU 101, a memory 102, a network controller 105, and a controller 107 are mounted. 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 the amount of physical resources to be secured (the number of physical blocks) Based on the request from the host 2 designated for each space, the designated number of physical blocks are individually assigned as physical resources for these namespaces. Therefore, physical block groups can be easily and optimally allocated to a plurality of namespaces (areas) in consideration of the capacity and update frequency of each of a plurality of types of data. Therefore, the durability suitable for the update frequency of the data to be stored can be realized for each namespace (area), and the write amplification of the namespace (area) for the data with high update frequency can be reduced. As it can, it can realize the maximization of the life of the SSD.

  In other words, according to the present embodiment, a large amount of over-provisioned area is secured for a data space (area) for which the frequency of updating is high, or a name space for data for which the frequency of updating is low ( Control can be flexibly performed such as securing a small amount of over-provisioning area for the area). As a result, it is possible to reduce the write amplification of the name space (area) for the data that is frequently updated, so that the life of the SSD can be maximized.

  In the present embodiment, the NAND memory is illustrated as the non-volatile memory. However, the function of the present embodiment may be, for example, magnetoresistive random access memory (MRAM), phase change random access memory (PRAM), resistive random access memory (ReRAM), or other such as ferroelectric random access memory (FeRAM). It can be applied to various non-volatile memories.

  While certain embodiments of the present invention have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and the gist of the invention, and are included in the invention described in the claims and the equivalent scope thereof.

  2 ... host, 3 ... SSD, 4 ... controller, 5 ... NAND memory, 51, 52, 53, 54, 55 ... area.

Claims (8)

Non-volatile memory containing multiple physical blocks,
Equipped with a controller,
The controller
Creating a first namespace and a second namespace based on the first namespace creation request and the second namespace creation request received from the host device;
The amount of data written to the area of the non-volatile memory corresponding to the first namespace by the host device, and the non-volatile memory corresponding to the first namespace by the garbage collection operation of the first namespace Calculating the light amplification of the first namespace by counting the amount of data written to the area;
The amount of data written to the area of the non-volatile memory corresponding to the second namespace by the host device, and the non-volatile memory corresponding to the second namespace by the garbage collection operation of the second namespace Calculating the write amplification of the second namespace by counting the amount of data written to the area;
A memory system configured to provide the host device with write amplification corresponding respectively to the first namespace and the second namespace. The controller
The first namespace is created based on the first namespace creation request, and a first number of physical blocks specified by the first namespace creation request are assigned to the first namespace,
The second namespace is created based on a second namespace creation request received from the host device, and the second number of physical blocks specified by the second namespace creation request is The memory system of claim 1 configured to be assigned to two namespaces.   The controller writes write data associated with the ID of the first namespace to the area of the non-volatile memory corresponding to the first namespace, and writes data associated with the ID of the second namespace The memory system according to claim 1, wherein the memory system is configured to write in an area of the non-volatile memory corresponding to the second name space. The controller
Receiving from the host device a control command requesting start of garbage collection of a target namespace;
From the physical blocks for the target namespace, select the target physical blocks for garbage collection,
The memory system according to claim 1, wherein the memory system is configured to execute a garbage collection operation of copying valid data from the target physical block group to a copy destination free block. The controller
Manage free blocks created by garbage collection operations executed for each namespace as shared free blocks of the multiple namespaces,
Select the minimum number of program / erase free blocks from the free block group,
5. The memory system according to claim 4, wherein the selected free block is configured to be allocated as the copy destination free block of the area corresponding to the target namespace. The controller encodes write data using a first coding to suppress memory cell consumption to generate first coded data, and adds an error correction code to the first coded data. To generate second encoded data, and write the second encoded data to a physical block,
The memory system according to claim 1, wherein the controller is further configured to change a ratio between the first encoded data and the error correction code in accordance with a name space in which write data is to be written. . The controller
When the write data is write data to be written to the first namespace, second encoded data including first encoded data of a first length and an error correction code of a second length is Controlling a ratio between the first encoded data and the error correction code so as to be obtained;
When the write data is write data to be written to the second namespace, the first encoded data of a third length shorter than the first length and the fourth encoded data longer than the second length 7. A memory system according to claim 6, wherein the ratio of said first coded data to said error correction code is controlled to obtain second coded data including a length of an error correction code. . Non-volatile memory containing multiple physical blocks,
A plurality of namespaces for storing a plurality of types of data having different update frequencies, wherein the first namespace for storing a first type of data and an update frequency lower than that of the first type of data And a controller for managing a plurality of namespaces including at least a second namespace for storing the second type of data.
The controller
The first namespace is created based on a first namespace creation request received from a host device, and the first number of physical blocks specified by the first namespace creation request is the first Assign to a namespace,
The second namespace is created based on a second namespace creation request received from the host device, and the second number of physical blocks specified by the second namespace creation request is Assign to 2 namespaces,
Writing write data associated with the ID of the first namespace into the area of the non-volatile memory corresponding to the first namespace as the first type of data;
Writing write data associated with the ID of the second namespace into the area of the non-volatile memory corresponding to the second namespace as the second type of data;
The amount of data written to the area of the non-volatile memory corresponding to the first namespace by the host device, and the non-volatile memory corresponding to the first namespace by the garbage collection operation of the first namespace Calculating the light amplification of the first namespace by counting the amount of data written to the area;
The amount of data written to the area of the non-volatile memory corresponding to the second namespace by the host device, and the non-volatile memory corresponding to the second namespace by the garbage collection operation of the second namespace Calculating the write amplification of the second namespace by counting the amount of data written to the area;
A memory system configured to provide the host device with write amplification corresponding respectively to the first namespace and the second namespace.

Images