Memory System

Abstract

A memory system capable of improving I / O performance is realized. When a controller receives from a host a write request specifying a first identifier that specifies a write destination superblock among a plurality of superblocks and a first logical address, the controller determines a first location in the first superblock that corresponds to the first identifier and writes data that corresponds to the first logical address to the first location in the first superblock. The controller updates a first table corresponding to the first superblock among a plurality of superblock logical-to-physical address translation tables so that the physical address in the first superblock that corresponds to the first location is mapped to the first logical address.

Description

[Technical field]

[0001] SUMMARY OF THE DISCLOSURE The present invention relates to a technique for controlling a non-volatile memory. [Background technology]

[0002] In recent years, memory systems equipped with nonvolatile memories have become widespread.

[0003] One such memory system is known as a solid-state drive (SSD) based on NAND flash technology.

[0004] SSDs are also used as storage in data center servers. High I / O performance is required for storage used in host computers such as servers. For this reason, new interfaces between hosts and storage have recently begun to be proposed. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Yiying Zhang et al., "De-indirection for flash-based SSDs with nameless writes." FAST. 2012, [online], [Retrieved September 13, 2017], Internet<URL: https: / / www.usenix.org / system / files / conference / fast12 / zhang.pdf > Summary of the Invention [Problem to be solved by the invention]

[0006] However, since the control of NAND flash memory is generally complex, when realizing a new interface to improve I / O performance, it is necessary to consider an appropriate division of roles between the host and the storage (memory system).

[0007] An object of the present invention is to provide a memory system and a control method that can improve I / O performance. [Means for solving the problem]

[0008] According to an embodiment, a memory system connectable to a host is complex The memory device includes a NAND flash memory including a number of blocks, and a controller electrically connected to the NAND flash memory. The theory Each address Tobu A mapping between each of the plurality of in-lock physical addresses is Nobu Each of the locks Nobu For each lock, multiple Nobu and managing the plurality of logical-physical address conversion tables in the lock. Nobu Write destination of the lock Nobu When a write request specifying a first identifier and a first logical address that specifies a lock is received from the host, Nobu determining a first location within the lock and storing data corresponding to the first logical address in the first block; Nobu writes the first location of the lock, and Nobu The plurality of locks are arranged so that an in-lock physical address is mapped to the first logical address. Nobu The first address conversion table in the lock Nobu The first table corresponding to the lock is updated. [Brief description of the drawings]

[0009] [Figure 1] FIG. 2 is a block diagram showing the relationship between a host and a memory system (flash storage device) according to an embodiment. [Diagram 2] 1A and 1B are diagrams for explaining the division of roles between a conventional SSD and a host, and the division of roles between a flash storage device and a host in the embodiment. [Diagram 3] FIG. 1 is a block diagram showing an example of the configuration of a computer system in which data transfer between multiple hosts and multiple flash storage devices is performed via a network device. [Figure 4] FIG. 2 is a block diagram showing an example of the configuration of a memory system according to the embodiment. [Diagram 5] 2 is a block diagram showing the relationship between a NAND interface and multiple NAND flash memory dies provided in the memory system of the embodiment. [Figure 6] FIG. 13 is a diagram showing an example of the configuration of a superblock constructed by a set of multiple blocks. [Figure 7] 4 is a diagram for explaining a block level address translation table managed by the host and an intra-block address translation table managed by the memory system of the embodiment. [Figure 8] 4 is a diagram for explaining a write command applied to the memory system of the embodiment. [Figure 9] 4 is a diagram for explaining a Trim command applied to the memory system of the embodiment. [Figure 10] FIG. 2 is a diagram for explaining a block number and an offset that represent a physical address. [Figure 11] FIG. 4 is a diagram for explaining a write operation executed in response to a write command. [Figure 12] 11A and 11B are diagrams for explaining a write operation that skips a defective page. [Figure 13] 11A and 11B are diagrams for explaining another example of a write operation that skips a bad page. [Figure 14] 1A and 1B are diagrams for explaining an operation of writing a pair of a logical address and data to a page in a block. [Figure 15]13 is a diagram for explaining an operation of writing data to a user data area of ​​a page in a block and writing the logical address of this data to a redundant area of ​​this page. [Figure 16] FIG. 13 is a diagram for explaining the relationship between block numbers and offsets when superblocks are used. [Figure 17] 11 is a diagram for explaining a maximum block number get command applied to the memory system of the embodiment. [Figure 18] FIG. 13 is a diagram for explaining a response to a maximum block number get command. [Figure 19] 4 is a diagram for explaining a block size get command applied to the memory system of the embodiment. [Figure 20] FIG. 13 is a diagram for explaining a response to a block size get command. [Figure 21] 4 is a diagram for explaining a block allocate command applied to the memory system of the embodiment. [Figure 22] FIG. 13 is a diagram for explaining a response to a block allocate command. [Diagram 23] 11 is a sequence chart showing a block information acquisition process executed by the host and the memory system of the embodiment. [Figure 24] 11 is a sequence chart showing a sequence of a write process executed by a host and the memory system of the embodiment. [Diagram 25] 11A and 11B are diagrams showing a data update operation for writing update data for data that has already been written; [Figure 26] 13 is a diagram for explaining an intra-block LUT for block number BLK#1 managed by the memory system of the embodiment. [Figure 27] 4 is a diagram for explaining an operation of updating a block management table managed by the memory system of the embodiment. [Figure 28] 11A and 11B are diagrams for explaining an operation of updating a block level LUT managed by a host. [Figure 29]13 is a diagram for explaining an operation of updating an intra-block LUT and a block management table in response to a notification from a host indicating a block number and a physical address corresponding to data to be invalidated. [Diagram 30] 4 is a diagram for explaining a read command applied to the memory system of the embodiment. [Diagram 31] FIG. 4 is a sequence chart for explaining a read operation executed by the memory system of the embodiment. [Diagram 32] 4A and 4B are diagrams for explaining garbage collection (GC) control commands applied to the memory system of the embodiment. [Diagram 33] 11A and 11B are diagrams for explaining a GC callback command applied to the memory system of the embodiment. [Diagram 34] 4 is a sequence chart showing the procedure of a garbage collection (GC) operation performed by the host and the memory system of the embodiment. [Diagram 35] FIG. 13 is a diagram for explaining an operation of copying all valid data in multiple GC source blocks to multiple GC destination blocks. [Diagram 36] FIG. 1 is a diagram for explaining an example of a data copy operation executed for garbage collection (GC). [Figure 37] 37 is a diagram for explaining the contents of the intra-block LUT of the GC destination block that is updated based on the result of the data copy operation of FIG. 36. [Figure 38] 37 is a diagram for explaining the contents of the intra-block LUT of the GC source block that is updated based on the result of the data copy operation of FIG. 36. [Figure 39] 37 is a diagram for explaining the contents of the host's block-level LUT that are updated based on the results of the data copy operation of FIG. 36. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment will be described with reference to the drawings.

[0011] First, with reference to FIG. 1, the configuration of a computer system including a memory system according to one embodiment will be described.

[0012] The memory system is a semiconductor storage device configured to write data to and read data from a non-volatile memory. The memory system is implemented as a flash storage device 3 based on NAND flash technology.

[0013] This computer system may include a host (host device) 2 and a plurality of flash storage devices 3. The host 2 may be a server configured to use a flash array constituted by the plurality of flash storage devices 3 as storage. The host (server) 2 and the plurality of flash storage devices 3 are interconnected (internal interconnection) via an interface 50. As the interface 50 for this internal interconnection, PCI Express (PCIe) (registered trademark), NVM Express (NVMe) (registered trademark), Ethernet (registered trademark), NVMe over Fabrics (NVMeOF), etc. may be used, but are not limited to these.

[0014] A typical example of a server that functions as host 2 is a server in a data center.

[0015] In the case where the host 2 is realized by a server in a data center, the host (server) 2 may be connected to a plurality of end user terminals (clients) 61 via a network 51. The host 2 can provide various services to these end user terminals 61.

[0016] Examples of services that can be provided by the host (server) 2 include (1) Platform as a Service (PaaS), which provides a system operating platform to each client (each end-user terminal 61), and (2) Infrastructure as a Service (IaaS), which provides infrastructure such as a virtual server to each client (each end-user terminal 61).

[0017] A number of virtual machines may be executed on this physical server functioning as the host (server) 2. Each of these virtual machines running on the host (server) 2 can function as a virtual server configured to provide various services to a number of corresponding clients (end-user terminals 61).

[0018] The host (server) 2 includes a storage management function for managing a plurality of flash storage devices 3 that constitute a flash array, and a front-end function for providing various services, including storage access, to each of the end-user terminals 61.

[0019] In conventional SSDs, the block / page hierarchical structure of NAND flash memory is hidden by the flash translation layer (FTL) in the SSD. In other words, the FTL of conventional SSDs has the following functions: (1) a function to manage mapping between each logical address and each physical address of NAND flash memory using a lookup table that functions as a logical-physical address translation table, (2) a function to hide page-based read / write and block-based erase operations, and (3) a function to perform garbage collection (GC) of NAND flash memory. The mapping between each logical address and the physical address of NAND flash memory is invisible to the host. The block / page structure of NAND flash memory is also invisible to the host.

[0020] On the other hand, a kind of address conversion (application level address conversion) may also be performed in the host. This address conversion uses an application level address conversion table to manage the mapping between each application level logical address and each logical address for the SSD. Also, in order to eliminate fragmentation that occurs in the logical address space for the SSD, a kind of GC (application level GC) is performed in the host to change the data arrangement in this logical address space.

[0021] However, in a redundant configuration in which the host and SSD each have an address translation table (the SSD has a lookup table that functions as a logical-physical address translation table, and the host has an application-level address translation table), huge memory resources are consumed to hold these address translation tables. Furthermore, the double address translation, which includes the host-side address translation and the SSD-side address translation, is also a factor that reduces I / O performance.

[0022] Furthermore, application-level GC on the host side increases the amount of data written to the SSD by several times (e.g., twice) the amount of actual user data. This increase in the amount of data written, combined with the write amplification of the SSD, reduces the storage performance of the entire system and shortens the lifespan of the SSD.

[0023] To solve these problems, one possible solution would be to move all of the FTL functions of conventional SSDs to the host.

[0024] However, to implement this measure, it is necessary for the host to directly handle the blocks and pages of the NAND flash memory. In the NAND flash memory, there is a page write order constraint, so it is difficult for the host to directly handle the pages. In addition, in the NAND flash memory, a block may contain a defective page (bad page). It is even more difficult for the host to handle the bad page.

[0025] Thus, in this embodiment, the role of FTL is shared between the host 2 and the flash storage device 3. Generally speaking, the host 2 executes block-level FTL to allocate blocks, and the flash storage device 3 executes intra-block FTL to allocate pages within a block.

[0026] The host 2 manages a block level lookup table (block level LUT), which is a block level address conversion table for managing the mapping between each logical address and each block number, and the flash storage device 3 manages an intra-block lookup table (intra-block LUT), which is a page level address conversion table for managing the mapping between each logical address and each block's intra-block physical address.

[0027] When data needs to be written to the flash storage device 3, the host 2 selects a block number (or requests the flash storage device 3 to allocate a free block) and sends a write request (write command) to the flash storage device 3 specifying the logical address and the block number of the selected block (or the block number of an allocated block notified by the flash storage device 3). The flash storage device 3 writes the data from the host 2 to the block corresponding to the block number specified in the write request (write command). In this case, the flash storage device 3 determines a write destination location within this block, and writes the data from the host 2 to this write destination location.

[0028] The block-level FTL of the host 2 has a function for executing storage services, a wear control function, a function for realizing high availability, a de-duplication function for preventing multiple duplicate data portions having the same contents from being stored in storage, a garbage collection (GC) block selection function, a QoS control function, and the like. The QoS control function includes a function for determining the access unit for each QoS domain (or for each block). The access unit indicates the minimum data size (grain) that the host 2 can write / read. The flash storage device 3 supports single or multiple access units (grain), and when the flash storage device 3 supports multiple access units, the host 2 can instruct the flash storage device 3 which access unit to use for each QoS domain (or for each block).

[0029] The QoS control function also includes a function for preventing performance interference between QoS domains as much as possible. This function is basically a function for maintaining stable latency.

[0030] On the other hand, the intra-block FTL of the flash storage device 3 has a GC execution function in addition to a function of allocating pages in a block. The GC execution function copies valid data in a source block (GC source block) selected by the host 2 to a destination block (GC destination block) selected by the host 2. The intra-block FTL of the flash storage device 3 determines a position (destination position) in the GC destination block to which the valid data should be written, and copies the valid data in the GC source block to the destination position in the GC destination block.

[0031] FIG. 2 shows the division of roles between a conventional SSD and a host, and the division of roles between a flash storage device 3 and a host 2 in this embodiment.

[0032] The left part of FIG. 2 shows the hierarchical structure of the entire computer system including a conventional SSD and a host that executes a virtual disk service.

[0033] A host (server) executes a virtual machine service 101 for providing a plurality of virtual machines to a plurality of end users. In each virtual machine on the virtual machine service 101, an operating system and a user application 102 used by a corresponding end user are executed.

[0034] Furthermore, in the host (server), a plurality of virtual disk services 103 corresponding to a plurality of user applications 102 are executed. Each virtual disk service 103 allocates a part of the capacity of the storage resource in the conventional SSD as a storage resource (virtual disk) for the corresponding user application 102. In each virtual disk service 103, an application level address translation is also executed, which converts an application level logical address into a logical address for the SSD, using an application level address translation table. Furthermore, in the host, an application level GC 104 is also executed.

[0035] The transmission of a command from the host (server) to the conventional SSD and the return of a command completion response from the conventional SSD to the host (server) are performed via an I / O queue 200 present in each of the host (server) and the conventional SSD.

[0036] The conventional SSD includes a write buffer (WB) 301, a lookup table (LUT) 302, a garbage collection function 303, and a NAND type flash memory (NAND flash array) 304. The conventional SSD manages only one lookup table (LUT) 302, and the resources of the NAND type flash memory (NAND flash array) 304 are shared by multiple virtual disk services 103.

[0037] In this configuration, write amplification increases due to overlapping GC including the application level GC 104 under the virtual disk service 103 and the garbage collection function 303 (LUT level GC) in the conventional SSD. Also, in the conventional SSD, an increase in the amount of data written from one end user or one virtual disk service 103 increases the frequency of GC, which may cause a noisy neighbor problem in which the I / O performance for other end users or other virtual disk services 103 deteriorates.

[0038] In addition, the existence of overlapping resources, including the application level address translation table in each virtual disk service and the LUT 302 in a conventional SSD, consumes a lot of memory resources.

[0039] The right part of FIG. 2 shows the hierarchical structure of the entire computer system including the flash storage device 3 and the host 2 of this embodiment.

[0040] A virtual machine service 401 for providing a plurality of virtual machines to a plurality of end users is executed in a host (server) 2. In each virtual machine on the virtual machine service 401, an operating system and a user application 402 used by a corresponding end user are executed.

[0041] Furthermore, in the host (server) 2, a plurality of I / O services 403 corresponding to a plurality of user applications 402 are executed. These I / O services 403 may include an LBA-based block I / O service, a key-value store service, and the like. Each I / O service 403 includes a block level LUT that manages mapping between each logical address and each block number of the flash storage device 3. Here, the logical address means an identifier that can identify the data to be accessed. This logical address may be a logical block address (LBA) that specifies a position in the logical address space, or may be a key (tag) of a key-value store, or may be a hash value of the key.

[0042] In an LBA-based block I / O service, a block level LUT may be used that manages the mapping between each logical address (LBA) and each block number of the flash storage device 3 .

[0043] In the key-value store service, a block-level LUT may be used that manages a mapping between each logical address (i.e., a key-like tag) and each block number in the flash storage device 3 where data corresponding to these logical addresses (i.e., the key-like tag) is stored. In this block-level LUT, a correspondence may be managed between a tag, a block number where the data identified by this tag is stored, and the data length of this data.

[0044] Each end user can choose which addressing method to use (LBA, key-value store, key, etc.).

[0045] Each of these block level LUTs does not convert each logical address from the user application 402 into a respective logical address for the flash storage device 3, but converts each logical address from the user application 402 into a respective block number for the flash storage device 3. In other words, each of these block level LUTs is a table in which a table for converting logical addresses for the flash storage device 3 into block numbers and an application level address conversion table are integrated (merged).

[0046] Each I / O service 403 also includes a GC block selection function, which can manage the amount of valid data in each block using a corresponding block-level LUT, thereby selecting a GC source block.

[0047] An I / O service 403 may exist for each of the above-mentioned QoS domains in the host (server) 2. The I / O service 403 belonging to a certain QoS domain manages mapping between each of the logical addresses used by the user applications 402 in the corresponding QoS domain and each of the block numbers of the block group belonging to the resource group assigned to the corresponding QoS domain.

[0048] The transmission of commands from the host (server) 2 to the flash storage device 3 and the return of responses such as command completion responses from the flash storage device 3 to the host (server) 2 are performed via I / O queues 500 present in both the host (server) 2 and the flash storage device 3. These I / O queues 500 may also be classified into multiple queue groups corresponding to multiple QoS domains.

[0049] The flash storage device 3 includes multiple write buffers (WB) 601 corresponding to multiple QoS domains, multiple intra-block LUTs 602 corresponding to multiple QoS domains, multiple garbage collection (GC) functions 603 corresponding to multiple QoS domains, and a NAND type flash memory (NAND flash array) 604.

[0050] In the configuration shown on the right side of FIG. 2, the upper hierarchical level (host 2) can recognize block boundaries, and therefore user data can be written to each block taking into consideration block boundaries / block sizes. In other words, the host 2 can recognize each block of the NAND type flash memory (NAND flash array) 604, and this allows control such as writing data to an entire block all at once, or invalidating all data in a block by deleting or updating it. As a result, it becomes possible to make it difficult for a situation to occur in which valid data and invalid data are mixed in a single block. Therefore, it is possible to reduce the frequency with which GC needs to be performed. By reducing the frequency of GC, write amplification is reduced, and the performance of the flash storage device 3 can be improved and the lifespan of the flash storage device 3 can be maximized. In this way, a configuration in which the upper hierarchical level (host 2) can recognize block numbers is useful.

[0051] On the other hand, due to page write order constraints, only one page per block can be written at present, so exposing the page number to the upper hierarchy is not as useful as exposing the block number to the upper hierarchy.

[0052] FIG. 3 shows a modification of the system configuration of FIG.

[0053] In FIG. 3, data transfer between multiple hosts 2A and multiple flash storage devices 3 is carried out via a network device (here, a network switch 1).

[0054] That is, in the computer system of FIG. 3, the storage management function of the server 2 of FIG. 1 is transferred to a manager 2B, and the front-end function of the server 2 is transferred to a plurality of hosts (hosts for end-user services) 2A.

[0055] The manager 2B manages a plurality of flash storage devices 3, and allocates storage resources of these flash storage devices 3 to each host (host for end user services) 2A in response to a request from each host (host for end user services) 2A.

[0056] Each host (host for end-user services) 2A is connected to one or more end-user terminals 61 via a network. Each host (host for end-user services) 2A manages the above-mentioned block level LUT. Each host (host for end-user services) 2A uses its own block level LUT to manage only the mapping between each logical address used by the corresponding end user and each block number of the resource assigned to itself. Therefore, this configuration makes it possible to easily scale out the system.

[0057] The block level FTL of each host 2A has a function for managing the block level LUT, a function for realizing high availability, a QoS control function, a GC block selection function, and the like.

[0058] The manager 2B is a dedicated device (computer) for managing multiple flash storage devices 3. The manager 2B has a global resource reservation function for reserving storage resources for the capacity requested by each host 2A. In addition, the manager 2B has a wear monitoring function for monitoring the degree of wear of each flash storage device 3, a NAND resource allocation function for allocating reserved storage resources (NAND resources) to each host 2A, a QoS control function, a global clock management function, and the like.

[0059] The FTL in a block of each flash storage device 3 has a function for managing a write buffer, a function for executing GC, and the like.

[0060] 3, the management of each flash storage device 3 is executed by the manager 2B, so that each host 2A only needs to execute the operation of sending an I / O request to one or more flash storage devices 3 assigned to it and the operation of receiving a response from the flash storage device 3. In other words, data transfer between the multiple hosts 2A and the multiple flash storage devices 3 is executed only via the switch 1, and the manager 2B is not involved in this data transfer. Also, as described above, the contents of the block level LUTs managed by each host 2A are independent of each other. Therefore, the number of hosts 2A can be easily increased, so that a scale-out type system configuration can be realized.

[0061] FIG. 4 shows an example of the configuration of the flash storage device 3.

[0062] The flash storage device 3 comprises a controller 4 and a non-volatile memory (NAND type flash memory) 5. The flash storage device 3 may also comprise a random access memory, for example a DRAM 6.

[0063] The NAND flash memory 5 includes a memory cell array including a plurality of memory cells arranged in a matrix. The NAND flash memory 5 may be a two-dimensional NAND flash memory or a three-dimensional NAND flash memory.

[0064] The memory cell array of the NAND flash memory 5 includes a plurality of blocks BLK0 to BLKm-1. Each of the blocks BLK0 to BLKm-1 is organized by a number of pages (here, pages P0 to Pn-1). The blocks BLK0 to BLKm-1 function as erase units. A block may also be referred to as an "erase block," a "physical block," or a "physical erase block." Each of the pages P0 to Pn-1 includes a plurality of memory cells connected to the same word line. The pages P0 to Pn-1 are the units of data write and read operations.

[0065] The controller 4 is electrically connected to a NAND flash memory 5, which is a non-volatile memory, via a NAND interface 13, such as Toggle or an Open NAND Flash Interface (ONFI). The controller 4 is a memory controller (control circuit) configured to control the NAND flash memory 5.

[0066] As shown in FIG. 5, the NAND flash memory 5 includes a plurality of NAND flash memory dies. Each NAND flash memory die is a non-volatile memory die including a memory cell array including a plurality of blocks BLK and a peripheral circuit for controlling the memory cell array. Each NAND flash memory die can operate independently. Therefore, the NAND flash memory die functions as a parallel operation unit. The NAND flash memory die is also called a "NAND flash memory chip" or a "non-volatile memory chip." FIG. 5 illustrates a case in which 16 channels Ch1, Ch2, ... Ch16 are connected to the NAND interface 13, and the same number of NAND flash memory dies (e.g., two dies per channel) are connected to each of these channels Ch1, Ch2, ... Ch16. Each channel includes a communication line (memory bus) for communicating with the corresponding NAND flash memory die.

[0067] The controller 4 controls the NAND flash memory dies #1 to #32 via channels Ch1, Ch2, ..., Ch16. The controller 4 can drive the channels Ch1, Ch2, ..., Ch16 simultaneously.

[0068] The 16 NAND flash memory dies #1 to #16 connected to the channels Ch1 to Ch16 may be organized as a first bank, and the remaining 16 NAND flash memory dies #17 to #32 connected to the channels Ch1 to Ch16 may be organized as a second bank. The bank functions as a unit for operating multiple memory modules in parallel by bank interleaving. In the configuration example of FIG. 5, a maximum of 32 NAND flash memory dies can be operated in parallel by 16 channels and bank interleaving using two banks.

[0069] In this embodiment, the controller 4 may manage a plurality of blocks (hereinafter referred to as superblocks), each of which is made up of a plurality of blocks BLK, and may execute an erase operation in units of superblocks.

[0070] Although not limited thereto, the superblock may include a total of 32 blocks BLK selected one by one from the NAND flash memory dies #1 to #32. Each of the NAND flash memory dies #1 to #32 may have a multi-plane configuration. For example, when each of the NAND flash memory dies #1 to #32 has a multi-plane configuration including two planes, one superblock may include a total of 64 blocks BLK selected one by one from the 64 planes corresponding to the NAND flash memory dies #1 to #32. FIG. 6 illustrates a case where one superblock SB is composed of a total of 32 blocks BLK (blocks BLK surrounded by a thick frame in FIG. 5) selected one by one from the NAND flash memory dies #1 to #32.

[0071] 4, the controller 4 includes a host interface 11, a CPU 12, a NAND interface 13, and a DRAM interface 14. The CPU 12, the NAND interface 13, and the DRAM interface 14 are interconnected via a bus 10.

[0072] The host interface 11 is a host interface circuit configured to execute communication with the host 2. The host interface 11 may be, for example, a PCIe controller (NVMe controller). The host interface 11 receives various requests (commands) from the host 2. These requests (commands) include a write request (write command), a read request (read command), and various other requests (commands).

[0073] The CPU 12 is a processor configured to control the host interface 11, the NAND interface 13, and the DRAM interface 14. In response to power-on of the flash storage device 3, the CPU 12 loads a control program (firmware) from the NAND flash memory 5 or a ROM (not shown) into the DRAM 6, and executes this firmware to perform various processes. The firmware may be loaded onto an SRAM (not shown) in the controller 4. The CPU 12 can execute command processing and the like for processing various commands from the host 2. The operation of the CPU 12 is controlled by the above-mentioned firmware executed by the CPU 12. A part or all of the command processing may be executed by dedicated hardware in the controller 4.

[0074] The CPU 12 can function as a write operation control unit 21, a read operation control unit 22, and a GC operation control unit 23. In the write operation control unit 21, the read operation control unit 22, and the GC operation control unit 23, an application program interface (API) is implemented to realize the system configuration shown in the right part of FIG.

[0075] The write operation control unit 21 receives a write request (write command) that specifies a block number and a logical address from the host 2. The logical address is an identifier that can identify the data (user data) to be written, and may be, for example, an LBA, or a tag such as a key of a key-value store, or a hash value of the key. The block number is an identifier that specifies the block to which this data should be written. As the block number, various values ​​that can uniquely identify any one of a plurality of blocks may be used. The block specified by the block number may be a physical block or the above-mentioned superblock. When receiving a write command, the write operation control unit 21 first determines a position (write destination position) in a block (write destination block) having the specified block number to which data from the host 2 should be written. Next, the write operation control unit 21 writes the data (write data) from the host 2 to the write destination position of the write destination block. In this case, the write operation control unit 21 can write not only the data from the host 2 but also both the data and the logical address of the data to the write destination block.

[0076] Then, the write operation control unit 21 updates the intra-block LUT 32 that manages the mapping between each logical address and each intra-block physical address of this block, and maps the intra-block physical address indicating the above-mentioned write destination position of this write destination block to the logical address of the write data.

[0077] In this case, the physical address within the block is represented by an offset within the block that indicates the write destination position within the write destination block.

[0078] In this case, the offset within the block indicates the offset from the beginning of the destination block to the destination position, that is, the offset of the destination position relative to the beginning of the destination block. The size of the offset from the beginning of the destination block to the destination position is indicated as a multiple of a granularity (Grain) having a size different from the page size. The granularity (Grain) is the access unit described above. The maximum value of the size of the granularity (Grain) is limited to the block size. In other words, the offset within the block indicates the offset from the beginning of the destination block to the destination position as a multiple of a granularity having a size different from the page size.

[0079] The grain may have a size smaller than the page size. For example, if the page size is 16K bytes, the grain may have a size of 4K bytes. In this case, a plurality of offset positions, each of which has a size of 4K bytes, are defined in one block. The intra-block offset corresponding to the first offset position in the block is, for example, 0, the intra-block offset corresponding to the next offset position in the block is, for example, 1, and the intra-block offset corresponding to the next offset position in the block is, for example, 2.

[0080] Alternatively, the grain may have a size larger than the page size. For example, the grain may be several times the size of the page size. If the page size is 16 Kbytes, the grain may be 32 Kbytes in size.

[0081] In this way, the write operation control unit 21 determines by itself the write destination position in a block having a block number from the host 2, and writes the write data from the host 2 to this write destination position in this block. Then, the write operation control unit 21 updates the intra-block LUT 32 corresponding to this block, and maps the intra-block physical address (intra-block offset) indicating the write destination position to the logical address of the write data. This allows the flash storage device 3 to have the host 2 handle the block numbers, while concealing page write order constraints, bad pages, page sizes, and the like.

[0082] As a result, the host 2 can recognize block boundaries but can manage which user data resides in which block number without being aware of page write order constraints, bad pages, or page sizes.

[0083] When the read operation control unit 22 receives a read request (read command) specifying a logical address and a block number from the host 2, the read operation control unit 22 uses this logical address to refer to the intra-block LUT 32 corresponding to the block having the block number specified by this read request. This allows the read operation control unit 22 to obtain the intra-block physical address (intra-block offset) of this block in which the data corresponding to this logical address is stored. Then, the read operation control unit 22 reads the data corresponding to this logical address from the NAND flash memory 5 based on the block number specified by the read request and the obtained intra-block physical address.

[0084] In this case, the block to be read is identified by a block number. The physical storage location of the read target in this block is identified by an offset within the block. To obtain the physical storage location of the read target, the read operation control unit 22 may first divide the offset within the block by a granularity number (here, 4) representing the page size, and then determine the quotient and remainder obtained by this division as the page number and the offset within the page of the read target, respectively.

[0085] When the GC operation control unit 23 receives from the host 2 a GC control command specifying a source block number (GC source block number) and a destination block number (GC destination block number) for garbage collection of the NAND flash memory 5, it selects a block having the specified source block number and a block having the specified destination block number as the source block (GC source block) and the destination block number (GC destination block) from multiple blocks in the NAND flash memory 5. The GC operation control unit 23 determines a destination position in the GC destination block to which valid data stored in the selected GC source block should be written, and copies the valid data to the destination position in the GC destination block.

[0086] Then, the GC operation control unit 23 updates the intra-block LUT corresponding to the GC source block and the intra-block LUT corresponding to the GC destination block so that the intra-block physical address (intra-block offset) mapped to the logical address of the valid data is changed from the intra-block physical address indicating the source position in the GC source block in which the valid data is stored to the intra-block physical address indicating the destination position in the GC destination block.

[0087] Management of valid data / invalid data may be performed using a block management table 33. This block management table 33 may exist for each block, for example. In the block management table 33 corresponding to a certain block, a bitmap flag indicating the validity / invalidity of each piece of data in this block is stored. Here, valid data means data that is associated with a logical address as the latest data and has the possibility of being read by the host 2 later. Invalid data means data that has no possibility of being read by the host 2 any more. For example, data associated with a certain logical address is valid data, and data that is not associated with any logical address is invalid data.

[0088] As described above, the GC operation control unit 23 determines a position (destination position) in a destination block (GC destination block) to which valid data stored in a source block (GC source block) should be written, and copies the valid data to the determined position (destination position) in the destination block (GC destination block). In this case, the GC operation control unit 23 may copy both the valid data and the logical address of the valid data to the destination block (GC destination block).

[0089] In this embodiment, as described above, the write operation control unit 21 can write both the data (write data) from the host 2 and the logical address from the host 2 to the write destination block. Therefore, the GC operation control unit 23 can easily obtain the logical address of each data in the copy source block (GC source block) from this copy source block (GC source block), and can easily update the intra-block LUT corresponding to the copy source block and the intra-block LUT corresponding to the copy destination block.

[0090] The NAND interface 13 is a memory control circuit configured to control the NAND flash memory 5 under the control of the CPU 12. The DRAM interface 14 is a DRAM control circuit configured to control the DRAM 6 under the control of the CPU 12. A part of the storage area of ​​the DRAM 6 is used for storing a write buffer (WB) 31. Another part of the storage area of ​​the DRAM 6 is used for storing an intra-block LUT 32 and a block management table 32. The write buffer (WB) 31, intra-block LUT 32, and block management table 32 may be stored in an SRAM (not shown) in the controller 4.

[0091] FIG. 7 shows a block level LUT (block level address translation table) managed by the host 2 and an intra-block LUT (intra-block address translation table) managed by the flash storage device 3.

[0092] The block level LUT manages the mapping between each logical address and each block number corresponding to each of the multiple blocks in the flash storage device 3. This block level LUT is a table that converts a certain logical address into a certain block number BLK#.

[0093] In the flash storage device 3, a plurality of intra-block LUTs corresponding to a plurality of blocks are managed. Each intra-block LUT manages mapping between a logical address and an intra-block physical address (intra-block offset) in the corresponding block. Each intra-block LUT is a table that converts a certain logical address into a certain intra-block physical address (intra-block PBA). The intra-block physical address (intra-block PBA) is represented by an intra-block offset as described above.

[0094] The address translation is performed as follows:

[0095] For example, in a read operation, the host 2 uses a certain logical address (e.g., a certain LBA) to refer to the block level LUT and converts this logical address (LBA) into a block number BLK#. This logical address and block number BLK# are transmitted from the host 2 to the flash storage device 3. In this embodiment, rather than assigning a specific logical address range to each block, the logical address itself is transmitted from the host 2 to the flash storage device 3 together with the block number BLK# so that data corresponding to any logical address can be stored in any block.

[0096] In the flash storage device 3, the controller 4 selects an intra-block LUT corresponding to the block number BLK#. For example, if the block number BLK# from the host 2 indicates block number BLK#0, the intra-block LUT corresponding to block number BLK#0 is selected, if the block number BLK# from the host 2 indicates block number BLK#1, the intra-block LUT corresponding to block number BLK#1 is selected, and if the block number BLK# from the host 2 indicates block number BLK#2, the intra-block LUT corresponding to block number BLK#2 is selected.

[0097] The selected intra-block LUT is referenced by a logical address from the host 2. Then, the intra-block PBA corresponding to this logical address is obtained from the selected intra-block LUT.

[0098] FIG. 8 shows a write command applied to the flash storage device 3 .

[0099] The write command is a command that requests writing of data to the flash storage device 3. This write command may include a command ID, a block number BLK#, a logical address, a length, and the like.

[0100] The command ID is an ID (command code) that indicates that this command is a write command, and the write command includes a command ID for the write command.

[0101] The block number BLK# is an identifier (block address) that can uniquely identify the block in which data is to be written.

[0102] The logical address is an identifier for identifying the write data to be written. As described above, this logical address may be an LBA, a key of a key-value store, or a hash value of the key. If the logical address is an LBA, the logical address (start LBA) included in this write command indicates the logical location (first logical location) where the write data should be written.

[0103] The length indicates the length of the write data to be written. This length (data length) may be specified by the number of granularities (Grains), may be specified by the number of LBAs, or the size may be specified by bytes.

[0104] When a write command is received from the host 2, the controller 4 determines a write destination location within a block having a block number specified by the write command. This write destination location is determined taking into consideration page write order constraints, bad pages, etc. Then, the controller 4 writes the data from the host 2 to this write destination location within this block having the block number specified by the write command.

[0105] FIG. 8 shows the Trim command applied to the flash storage device 3.

[0106] This Trim command is a command that includes the block number of the block in which the data to be invalidated is stored and the logical address of this data. This Trim command includes a command ID, block number BLK#, logical address, and length.

[0107] The command ID is an ID (command code) that indicates that this command is a Trim command, and the Trim command includes a command ID for the Trim command.

[0108] The block number indicates the block in which the data to be invalidated is stored.

[0109] The logical address indicates the first logical location of the data to be invalidated.

[0110] The length indicates the length of the data to be invalidated. This length (data length) may be specified by the number of logical addresses, may be specified by the number of grains, or may be specified by bytes.

[0111] The controller 4 manages flags (bitmap flags) indicating whether each piece of data included in each of a plurality of blocks is valid / invalid, using the block management table 33. When a Trim command including a block number and logical address indicating a block in which data to be invalidated is stored is received from the host 2, the controller 4 updates the block management table 33 and changes the flag (bitmap flag) corresponding to the physical address in the block specified by the block number and logical address included in the Trim command to a value indicating invalid.

[0112] FIG. 10 shows an offset within a block that defines a physical address within a block.

[0113] The block number specifies one block BLK. Each block BLK includes multiple pages (here, page 0 to page n) as shown in FIG.

[0114] In the case where the page size (user data storage area of ​​each page) is 16 Kbytes and the grain size is 4 KB, this block BLK is logically divided into 4×(n+1) areas.

[0115] Offset +0 points to the first 4KB region of page 0, offset +1 points to the second 4KB region of page 0, offset +2 points to the third 4KB region of page 0, and offset +3 points to the fourth 4KB region of page 0.

[0116] Offset +4 points to the first 4KB region of page 1, offset +5 points to the second 4KB region of page 1, offset +6 points to the third 4KB region of page 1, and offset +7 points to the fourth 4KB region of page 1.

[0117] FIG. 11 shows a write operation performed in response to a write command.

[0118] Now, assume that block BLK#1 is assigned as the write destination block, and the controller 4 writes data to block BLK#1 in units of pages in the order of page 0, page 1, page 2, ..., page n.

[0119] 11, it is assumed that a write command specifying a block number (=BLK#1), logical address (LBAx) and length (=4) is received from the host 2 when 16K bytes of data have already been written to page 0 of block BLK#1. The controller 4 determines page 1 of block BLK#1 as the write destination location, and writes the 16K bytes of write data received from the host 2 to page 1 of block BLK#1. The controller 4 then updates the intra-block LUT32 corresponding to block BLK#1, and maps offset+5, offset+6, offset+7 and offset+8 to LBAx, LBAx+1, LBAx+2 and LBAx+3, respectively.

[0120] FIG. 12 shows a write operation that skips a bad page.

[0121] 12, it is assumed that a write command specifying the block number (=BLK#1), logical address (LBAx+1) and length (=4) is received from the host 2 when data has already been written to page 0 and page 1 of block BLK#1. If page 2 of block BLK#1 is a defective page, the controller 4 determines page 3 of block BLK#1 as the write destination location and writes 16K bytes of write data received from the host 2 to page 3 of block BLK#1. Then, the controller 4 updates the intra-block LUT32 corresponding to block BLK#1, and maps offset+12, offset+13, offset+14 and offset+15 to LBAx+1, LBAx+2, LBAx+3 and LBAx+4, respectively.

[0122] FIG. 13 shows another example of a write operation that skips a bad page.

[0123] In FIG. 13, it is assumed that data is written across two pages sandwiching a defective page. It is assumed that data has already been written to page 0 and page 1 of block BLK#2, and that unwritten 8K-byte write data remains in the write buffer 31. In this state, if a write command specifying the block number (=BLK#2), logical address (LBAy), and length (=6) is received, the controller 4 prepares 16K-byte write data corresponding to the page size using the unwritten 8K-byte write data and the first 8K-byte write data in the 24K-byte write data newly received from the host 2. Then, the controller 4 writes the prepared 16K-byte write data to page 2 of block BLK#2.

[0124] If the next page 3 of block BLK#2 is a bad page, the controller 4 determines page 4 of block BLK#2 as the next write location and writes the remaining 16 KB of write data within the 24 KB of write data received from the host 2 to page 4 of block BLK#2.

[0125] Then, the controller 4 updates the intra-block LUT32 corresponding to block BLK#2 to map offset +10 and offset +11 to LBAy and LBAy+1, and map offset +16, offset +17, offset +18, and offset +19 to LBAy+2, LBAy+3, LBAy+4, and LBAy+5, respectively.

[0126] 14 and 15 show the operation of writing a pair of a logical address and data to a page in a block.

[0127] In each block, each page may include a user data area for storing user data and a redundant area for storing management data. The page size is 16KB+alpha.

[0128] The controller 4 writes both the 4KB user data and the logical address (e.g., LBA) corresponding to the 4KB user data to the destination block BLK. In this case, as shown in Fig. 14, four data sets each including an LBA and 4KB user data may be written to the same page. The offset within the block may indicate a set boundary.

[0129] Alternatively, as shown in FIG. 15, four 4 KB user data may be written to a user data area within a page, and four LBAs corresponding to these four 4 KB user data may be written to a redundant area within the page.

[0130] Figure 16 shows the relationship between block numbers and offsets (offsets within a block) in the case where superblocks are used. In the following, the offsets within a block are also referred to simply as offsets.

[0131] For the sake of simplicity, it is assumed here that one superblock SB#1 is made up of four blocks BLK#11, BLK#21, BLK#31, and BLK#41. The controller 4 writes data in the following order: page 0 of block BLK#11, page 0 of block BLK#21, page 0 of block BLK#31, page 0 of block BLK#41, page 1 of block BLK#11, page 1 of block BLK#21, page 1 of block BLK#31, page 1 of block BLK#41, and so on.

[0132] Offset +0 indicates the first 4KB region of page 0 of block BLK#11, offset +1 indicates the second 4KB region of page 0 of block BLK#11, offset +2 indicates the third 4KB region of page 0 of block BLK#11, and offset +3 indicates the fourth 4KB region of page 0 of block BLK#11.

[0133] Offset +4 indicates the first 4KB region of page 0 of block BLK#21, offset +5 indicates the second 4KB region of page 0 of block BLK#21, offset +6 indicates the third 4KB region of page 0 of block BLK#21, and offset +7 indicates the fourth 4KB region of page 0 of block BLK#21.

[0134] Similarly, offset +12 indicates the first 4KB region of page 0 of block BLK#41, offset +13 indicates the second 4KB region of page 0 of block BLK#41, offset +14 indicates the third 4KB region of page 0 of block BLK#41, and offset +15 indicates the fourth 4KB region of page 0 of block BLK#41.

[0135] Offset +16 indicates the first 4KB region of page 1 of block BLK#11, offset +17 indicates the second 4KB region of page 1 of block BLK#11, offset +18 indicates the third 4KB region of page 1 of block BLK#11, and offset +19 indicates the fourth 4KB region of page 1 of block BLK#11.

[0136] Offset +20 indicates the first 4KB region of page 1 of block BLK#21, offset +21 indicates the second 4KB region of page 1 of block BLK#21, offset +22 indicates the third 4KB region of page 1 of block BLK#21, and offset +23 indicates the fourth 4KB region of page 1 of block BLK#21.

[0137] Similarly, offset +28 indicates the first 4KB region of page 1 of block BLK#41, offset +29 indicates the second 4KB region of page 1 of block BLK#41, offset +30 indicates the third 4KB region of page 1 of block BLK#41, and offset +31 indicates the fourth 4KB region of page 1 of block BLK#41.

[0138] FIG. 17 shows a Get Maximum Block Number command applied to the flash storage device 3.

[0139] The get maximum block number command is a command for acquiring the maximum block number from the flash storage device 3. By sending the get maximum block number command to the flash storage device 3, the host 2 can recognize the maximum block number indicating the number of blocks included in the flash storage device 3. The get maximum block number command includes a command ID for the get maximum block number command, and does not include a parameter.

[0140] FIG. 18 shows a response to the Get Maximum Block Number command.

[0141] When the get maximum block number command is received from the host 2, the flash storage device 3 returns a response shown in Fig. 18 to the host 2. This response includes a parameter indicating the maximum block number (i.e., the total number of available blocks included in the flash storage device 3).

[0142] FIG. 19 shows a get block size command applied to the flash storage device 3.

[0143] The get block size command is a command for acquiring the block size from the flash storage device 3. The host 2 can recognize the block size of the NAND flash memory 5 included in the flash storage device 3 by sending the get block size command to the flash storage device 3.

[0144] In another embodiment, the get block size command may include a parameter specifying a block number. When the get block size command specifying a certain block number is received from the host 2, the flash storage device 3 returns the block size of the block having this block number to the host 2. This allows the host 2 to recognize the block size of each individual block even if the block sizes of the blocks included in the NAND flash memory 5 are not uniform.

[0145] FIG. 20 shows a response to the get block size command.

[0146] When the get block size command is received from the host 2, the flash storage device 3 returns the block size (the common block size for each block included in the NAND flash memory 5) to the host 2. In this case, if a block number is specified by the get block size command, the flash storage device 3 returns the block size of the block having this block number to the host 2, as described above.

[0147] FIG. 21 shows a block allocate command applied to the flash storage device 3.

[0148] The block allocate command is a command that requests allocation of a block (free block) to the flash storage device 3. By sending a block allocate command to the flash storage device 3, the host 2 requests the flash storage device 3 to allocate a free block, and can thereby obtain the block number (the block number of the allocated free block).

[0149] In the case where the flash storage device 3 manages the free blocks using a free block list and the host 2 does not manage the free blocks, the host 2 requests the flash storage device 3 to allocate a free block and thereby obtains a block number. On the other hand, in the case where the host 2 manages the free blocks, the host 2 can select one of the free blocks by itself, and therefore does not need to send a block allocate command to the flash storage device 3.

[0150] FIG. 22 shows a response to a block allocate command.

[0151] When the flash storage device 3 receives a block allocate command from the host 2, it selects a free block to be allocated to the host 2 from the free block list, and returns a response to the host 2 including the block number of the selected free block.

[0152] FIG. 23 shows a block information acquisition process executed by the host 2 and the flash storage device 3.

[0153] When the host 2 starts using the flash storage device 3, the host 2 first sends a get maximum block number command to the flash storage device 3. The controller of the flash storage device 3 returns the maximum block number to the host 2. The maximum block number indicates the total number of available blocks. Note that in the case where the above-mentioned super blocks are used, the maximum block number may also indicate the total number of available super blocks.

[0154] Next, the host 2 obtains the block size by transmitting a get block size command to the flash storage device 3. In this case, the host 2 may transmit a get block size command specifying block number 1, a get block size command specifying block number 2, a get block size command specifying block number 3, ... to the flash storage device 3, respectively, to obtain the block size of each of all blocks individually.

[0155] This block information acquisition process enables the host 2 to recognize the number of available blocks and the block size of each block.

[0156] FIG. 24 shows the sequence of a write operation performed by the host 2 and the flash storage device 3.

[0157] The host 2 first selects a block (free block) to be used for writing, or requests the flash storage device 3 to allocate a free block by sending a block allocate command to the flash storage device 3. Then, the host 2 sends a write command to the flash storage device 3, including the block number BLK# of the block selected by the host 2 (or the block number BLK# of a free block allocated by the flash storage device 3), a logical address (LBA), and a length (step S20).

[0158] When the controller 4 of the flash storage device 3 receives this write command, the controller 4 determines a destination position in the block having this block number BLK# (destination block BLK#) to which the write data from the host 2 should be written, and writes the write data to the destination position in the destination block BLK# (step S11). In step S11, the controller 4 may write both the logical address (here, LBA) and the write data to the destination block.

[0159] The controller 4 updates the intra-block LUT corresponding to the write destination block BLK#, and maps the offset (intra-block offset) indicating the write destination position to this logical address (step S12).

[0160] Next, the controller 4 updates the block management table 32 corresponding to the destination block BLK#, and changes the bitmap flag corresponding to the written data (i.e., the bitmap flag corresponding to the offset (offset within the block) to which this data was written) from 0 to 1 (step S13).

[0161] For example, assume that 16K byte update data with a starting LBA of LBAx is written to a physical memory location corresponding to offsets +4 to +7 of block BLK#1 as shown in Fig. 25. In this case, offsets +4 to +7 are mapped to LBAx to LBAx+3 in the intra-block LUT for block BLK#1 as shown in Fig. 26. Also, in the block management table for block BLK#1 as shown in Fig. 27, the bitmap flags corresponding to offsets +4 to +7 are changed from 0 to 1.

[0162] The controller 4 returns a response (success / failure) to this write command to the host 2 (step S14).

[0163] When the host 2 receives this response, the host 2 updates the block level LUT managed by the host 2, and maps the block number BLK# of the destination block BLK# to the logical address corresponding to the written write data (step S21). As shown in FIG. 28, the block level LUT includes a plurality of entries corresponding to a plurality of logical addresses (e.g., LBAs). An entry corresponding to a certain logical address (e.g., a certain LBA) stores the block number of the NAND flash memory 5 in which the data corresponding to this LBA is stored. As shown in FIG. 25, if 16K byte update data with a starting LBA of LBAx is written to block BLK#1, as shown in FIG. 28, the intra-block LUT is updated, and the block numbers corresponding to LBAx to LBAx+3 are changed from BLK#0 to BLK#1.

[0164] 24, the host 2 sends a Trim command to the flash storage device 3 to invalidate previous data that has become unnecessary due to the writing of the above-mentioned updated data. The controller 4 of the flash storage device 3 updates the block LUT and block management table in response to this Trim command (steps S15 and S16).

[0165] If the previous data is stored in block BLK#0 as shown in FIG. 25, a Trim command specifying the block number (=BLK#0), LBAx, and length (=4) is sent from the host 2 to the flash storage device 3 as shown in FIG. 29. In response to this Trim command, the controller 4 of the flash storage device 3 updates the intra-block LUT corresponding to BLK#0 to delete information indicating mapping between LBAx to LBAx+3 and offsets +1 to +3. In this case, the controller 4 may change these LBAx to LBAx+3 and offsets +1 to +3 to values ​​indicating invalidity (null). Furthermore, the controller 4 updates the block management table 32 corresponding to BLK#0 to change the bitmap flags corresponding to offsets +0 to +3 from 1 to 0.

[0166] FIG. 30 shows a read command applied to the flash storage device 3.

[0167] The read command is a command that requests the reading of data from the flash storage device 3. This read command includes a command ID, a block number BLK#, a logical address, a length, and a transfer destination pointer.

[0168] The command ID is an ID (command code) that indicates that this command is a read command, and the read command includes a command ID for the read command.

[0169] The block number BLK# indicates the block number of the block that the data to be read is stored in. The logical address is the logical address of the data to be read.

[0170] The length indicates the length of the data to be read. This data length may be indicated by the number of LBAs or the number of grains.

[0171] The destination pointer indicates the location in memory in the host 2 to which the read data should be transferred.

[0172] FIG. 31 shows the sequence of a read operation executed by the host 2 and the flash storage device 3.

[0173] The host 2 converts the logical address (LBA) included in the read request from the user application into a block number by referring to the LUT in the block managed by the host 2. Then, the host 2 transmits a read command to the flash storage device 3, which specifies the block number, LBA, and length.

[0174] When the controller 4 of the flash storage device 3 receives a read command from the host 2, the controller 4 selects an intra-block LUT corresponding to the block number specified by the read command, and acquires an offset (intra-block offset) corresponding to the LBA by referring to the selected intra-block LUT using the LBA in the read command (step S31). The controller 4 reads data corresponding to the LBA from the NAND flash memory 5 based on the block number specified by the read command and the acquired offset (intra-block offset) (step S32), and transmits the read data to the host 2.

[0175] FIG. 32 shows the GC control commands applied to the flash storage device 3.

[0176] The GC control command is used to notify the flash storage device 3 of the GC source block number and the GC destination block number. The host 2 manages the amount of valid data / invalid data of each block, and can select some blocks with a smaller amount of valid data as GC source blocks. The host 2 also manages a free block list, and can select some free blocks as GC destination blocks. This GC control command may include a command ID, a GC source block number, a GC destination block number, etc.

[0177] The command ID is an ID (command code) that indicates that this command is a GC control command, and the GC control command includes a command ID for the GC control command.

[0178] The GC source block number is a block number indicating a GC source block. The host 2 can specify which block should be the GC source block. The host 2 may set multiple GC source block numbers in one GC control command.

[0179] The GC destination block number is a block number indicating a GC destination block. The host 2 can specify which block should be the GC destination block. The host 2 can set multiple GC destination block numbers in one GC control command.

[0180] FIG. 33 shows the callback command for GC.

[0181] The callback command for GC is used to notify the host 2 of a list including multiple pairs of logical addresses (LBA) and destination block numbers. The logical address (LBA) included in a certain pair is the logical address of the valid data that has been copied. The destination block number included in this pair is the block number of the GC destination block to which this valid data has been copied. This callback command for GC may be sent from the flash storage device 3 to the host 2 only if multiple GC source block numbers and multiple destination block numbers are specified by the GC control command.

[0182] FIG. 28 shows the procedure of a garbage collection (GC) operation.

[0183] For example, when the number of remaining free blocks included in the free block list managed by the host 2 falls below a threshold, the host 2 selects a GC source block and a GC destination block, and sends a GC control command to the flash storage device 3 (step S41).

[0184] Upon receiving this GC control command, the controller 4 of the flash storage device 3 executes a data copy operation including an operation of determining a position (copy destination position) in the GC destination block to which the valid data in the GC source block should be written, and an operation of copying the valid data in the GC source block to the copy destination position in the GC destination block (step S51). In step S51, the data copy operation is repeatedly executed until copying of all valid data in the GC source block is completed. When multiple GC source blocks are specified by the GC control command, the data copy operation is repeatedly executed until copying of all valid data in all GC source blocks is completed.

[0185] Then, the controller 4 notifies the host 2 of a list including multiple pairs of logical addresses (LBA) and destination block numbers using a GC callback command (step S52), and updates the intra-block LUT corresponding to the GC source block and the intra-block LUT corresponding to the GC destination block so that the offset (intra-block offset) mapped to the logical address of the copied valid data is changed from the offset (intra-block offset) indicating the source position in the GC source block to the offset (intra-block offset) indicating the destination position in the GC destination block (step S53).

[0186] The host 2 updates the intra-block LUT based on the list notified by the flash storage device 3 (step S42).

[0187] FIG. 35 illustrates the operation of copying all valid data in multiple GC source blocks to multiple GC destination blocks.

[0188] Here, it is assumed that blocks BLK#1, BLK#2, and BLK#3 are designated as GC source blocks by the host 2, and blocks BLK#50 and BLK#51 are designated as GC destination blocks by the host 2. Valid data and invalid data are mixed in each of blocks BLK#1, BLK#2, and BLK#3.

[0189] First, all valid data in block BLK#1 is copied to block BLK#50. Next, some of all valid data in block BLK#2 is copied to the remaining free area in block BLK#50, and the remaining valid data in block BLK#2 is copied to block BLK#51. Then, all valid data in block BLK#3 is copied to block BLK#51.

[0190] The controller 4 may copy not only the valid data in each GC source block, but also both the valid data and the logical address corresponding to the valid data from the GC source block (copy source block) to the GC destination block (copy destination block). This makes it possible to hold pairs of data and logical addresses in the GC destination block (copy destination block).

[0191] FIG. 36 shows an example of the data copy operations performed for GC.

[0192] In Figure 36, it is assumed that valid data (LBA=10) stored at a position corresponding to offset +0 of the GC source block (here, block BLK#1) is copied to a position corresponding to offset +0 of the GC destination block (here, block BLK#50), and valid data (LBA=11) stored at a position corresponding to offset +1 of the GC source block (here, block BLK#1) is copied to a position corresponding to offset +1 of the GC destination block (here, block BLK#50).

[0193] In this case, the controller 4 updates the intrablock LUT corresponding to the block BLK#50 as shown in FIG. 37, and stores the pair of LBA10 and offset+0 and the pair of LBA11 and offset+1 in the intrablock LUT corresponding to the block BLK#50. As a result, offset+0 is mapped to LBA10, and offset+1 is mapped to LBA10. Furthermore, the controller 4 updates the intrablock LUT corresponding to the block BLK#10 as shown in FIG. 38, and deletes the pair of LBA10 and offset+0 and the pair of LBA11 and offset+1 from the intrablock LUT corresponding to the block BLK#1. Furthermore, the controller 4 notifies the host 2 of the pair of LBA10 and destination block number (BLK#50) and the pair of LBA11 and destination block number (BLK#50).

[0194] Based on this notification, host 2 updates the block level LUT as shown in FIG. 39, changing the block number mapped to LBA10 from BLK#1 to BLK#50, and also changes the block number mapped to LBA11 from BLK#1 to BLK#50.

[0195] As described above, according to this embodiment, when a write request specifying the first block number and the first logical address is received from the host 2, the controller 4 of the flash storage device 3 determines a position (write destination position) in the block (write destination block) having the first block number to which data from the host 2 should be written, writes the data from the host 2 to the write destination position of the write destination block, updates the intra-block LUT that manages the mapping between each logical address and each intra-block physical address (intra-block offset) of the write destination block, and maps the intra-block offset indicating the write destination position to the first logical address. Also, when a read request specifying the above-mentioned first block number and the above-mentioned first logical address is received from the host 2, the controller 4 uses the first logical address to refer to the intra-block LUT to obtain the intra-block physical address (intra-block offset) to which the data corresponding to the first logical address is written, and reads the data corresponding to the first logical address from the NAND flash memory 5 based on the first block number and the obtained intra-block physical address (intra-block offset).

[0196] Therefore, a configuration can be realized in which the host 2 handles the block number, and the flash storage device 3 determines the write destination position in the block having the block number specified by the host 2, taking into account page write order constraints / bad pages, etc. By the host 2 handling the block number, it is possible to realize merging of the application level address translation table of the upper layer (host 2) with the LUT level address translation table of the conventional SSD. In addition, the flash storage device 3 can control the NAND flash memory 5, taking into account the characteristics / constraints of the NAND flash memory 5. Furthermore, since the host 2 can recognize the block boundary, it is possible to write user data to each block, taking into account the block boundary / block size. This allows the host 2 to perform control such as invalidating data in the same block all at once by data update, etc., so that it is possible to reduce the frequency of GC execution. As a result, write amplification is reduced, and the performance of the flash storage device 3 is improved, and the life of the flash storage device 3 is maximized.

[0197] Therefore, an appropriate division of roles between the host 2 and the flash storage device 3 can be achieved, thereby improving the I / O performance of the entire system including the host 2 and the flash storage device 3.

[0198] Also, according to this embodiment, the controller 4 determines a destination location in the destination block to which valid data should be written, and copies the valid data to this destination location in the destination block. Therefore, the host 2 only needs to select a source block and a destination block. Also, since the application level GC can be merged with the GC of the flash storage device 3, write amplification can be significantly reduced.

[0199] The flash storage device 3 may be used as one of a plurality of flash storage devices 3 provided in a storage array. The storage array may be connected to an information processing device such as a server computer via a cable or a network. The storage array includes a controller that controls the plurality of flash storage devices 3 in the storage array. When the flash storage device 3 is applied to the storage array, the controller of the storage array may function as the host 2 for the flash storage device 3.

[0200] In the present embodiment, a NAND flash memory is exemplified as a nonvolatile memory. However, the function of the present embodiment can be applied to, for example, MRAM (Magnetoresistive Random Access Memory). Random Access Memory), PRAM (Phase change The present invention can also be applied to various other non-volatile memories such as Random Access Memory (RAM), Resistive Random Access Memory (ReRAM), or Ferroelectric Random Access Memory (FeRAM).

[0201] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0202] 2... host, 3... flash storage device, 4... controller, 5... NAND type flash memory, 21... write operation control unit, 22... read operation control unit, 23... GC operation control unit.

Claims

1. 1. A memory system connectable to a host, comprising: a NAND flash memory including a plurality of blocks; a controller electrically connected to the NAND flash memory; The controller: managing mapping between each of the logical addresses and each of the in-block physical addresses for each of the plurality of blocks by using each of a plurality of in-block logical-physical address conversion tables; when a write request is received from the host, the write request specifying a first identifier that specifies a write destination block among the plurality of blocks and a first logical address; determining a first location within a first block corresponding to the first identifier; writing data corresponding to the first logical address to the first location of the first block; and updating a first table corresponding to the first block among the plurality of intra-block logical-physical address conversion tables so that a first intra-block physical address corresponding to the first location is mapped to the first logical address. Memory system.

2. 2. The memory system of claim 1, wherein each of the plurality of blocks includes a plurality of pages, and the physical address within the first block is represented by a first intra-block offset indicating an offset from the beginning of the first block to the first position in a multiple of a granularity having a size different from a page size.

3. 2. The memory system of claim 1, wherein the controller is further configured to write the first logical address to the first block in response to the write request.

4. The controller: notifying the host of information indicating the number of the plurality of blocks when a first command requesting notification of a maximum block number is received from the host; 2. The memory system of claim 1, further configured to notify the host of information indicating the block size of each of the plurality of blocks when a second command requesting notification of a block size is received from the host.

5. 5. The memory system of claim 4, wherein the controller is further configured to, when the second command includes a second identifier, notify the host of a block size of a block corresponding to the second identifier included in the second command.

Images