Memory system and control method of controlling non-volatile memory

Abstract

The present invention relates to a memory system and a control method of controlling a nonvolatile memory. The present invention achieves a memory system capable of improving I / O performance. The memory system of an embodiment, when receiving a write request designating a logical address from a host, decides both a first block to which data from the host should be written and a first position of the first block, and writes the data from the host to the first position of the first block. The memory system notifies the host of the first logical address, a first block number designating the first block, and a first in-block offset, which is an offset from a front end of the first block to the first position expressed in multiples of a granularity having a size different from a page size.

Description

[0001] Information related to divisional application

[0002] This case is a divisional application. The parent application of this divisional application is the invention patent application filed on January 10, 2018, with application number 201810021746.9 and title "Memory System and Control Method for Controlling Non-volatile Memory".

[0003] [Related Applications]

[0004] This application claims priority to Japanese Patent Application No. 2017-181425 (filed on September 21, 2017), which is the basic application. This application includes all contents of the basic application by reference to it. Technical Field

[0005] The embodiments of the present invention relate to a memory system and a control method for controlling non-volatile memory. Background Technology

[0006] In recent years, memory systems with non-volatile memory have become widely used.

[0007] As one type of memory system, solid-state drives (SSDs) based on NAND (Not AND) flash memory technology are known.

[0008] SSDs are also used as storage in servers in data centers. High I / O (Input / Output) performance is required for storage in host computers like servers. Therefore, novel interfaces between the host and storage have recently begun to be proposed.

[0009] However, in general, because the control of NAND flash memory is relatively complex, when implementing novel interfaces to improve I / O performance, the appropriate allocation of roles between the host and the memory (memory system) must be considered. Summary of the Invention

[0010] This invention provides a memory system capable of improving I / O performance and a control method for controlling non-volatile memory.

[0011] According to an embodiment, a memory system connectable to a host includes: a non-volatile memory comprising multiple blocks, each containing multiple pages; and a controller electrically connected to the non-volatile memory and controlling the non-volatile memory. When the controller receives a write request specifying a first logical address from the host, it performs the following actions: determines both a first block of data to be written from the host and a first location of the first block; writes the data from the host to the first location of the first block; and notifies the host of the first logical address, the first block number of the first block, and the offset within the first block, wherein the offset within the first block is an offset from the front end of the first block to the first location that has a granularity different from the page size. When the controller performs useless information collection from the non-volatile memory, it performs the following actions: selects a source block and a target block for the useless information collection from the plurality of blocks, determines the second position of the target block to which the valid data stored in the source block should be written, copies the valid data to the second position of the target block, and notifies the host of the logical address of the valid data, specifies the second block number of the target block, and the offset within the second block, which is expressed as a multiple of the granularity, from the front end of the target block to the second position. Attached Figure Description

[0012] Figure 1 This is a block diagram illustrating the relationship between the host and the memory system (flash storage device) of the implementation method.

[0013] Figure 2 This diagram illustrates the interaction allocation between a conventional SSD and a host, and between the flash storage device and the host in this embodiment.

[0014] Figure 3 This is a block diagram illustrating an example of the configuration of a computer system that performs data transfer between multiple hosts and multiple flash storage devices via a network machine.

[0015] Figure 4 This is a block diagram illustrating an example configuration of the memory system in this embodiment.

[0016] Figure 5 This is a block diagram illustrating the relationship between the NAND interface of the memory system provided in this embodiment and multiple NAND flash memory chip blocks.

[0017] Figure 6 This is a diagram illustrating an example of the construction of a superblock, which is built from a collection of multiple blocks.

[0018] Figure 7This diagram illustrates the write commands applied to the memory system of this embodiment.

[0019] Figure 8 It is used to target Figure 7 The diagram illustrates the response to the write command.

[0020] Figure 9 This diagram illustrates the Trim command applied to the memory system of this embodiment.

[0021] Figure 10 It is used to... Figure 8 The diagram illustrates the block number and offset of the specified entity address contained in the response.

[0022] Figure 11 It is a diagram used to illustrate the relationship between the write action performed according to the write command and the return value contained in the response to the write command.

[0023] Figure 12 This diagram illustrates the write operation that skips bad pages.

[0024] Figure 13 This diagram illustrates another example of a write operation that skips bad pages.

[0025] Figure 14 It is a diagram used to illustrate the action of writing logical address and data pairs into pages within a block.

[0026] Figure 15 It is a diagram used to illustrate the action of writing data into the user data area of ​​a page within a block, and writing the logical address of that data into the redundant area of ​​that page.

[0027] Figure 16 It is a diagram used to illustrate the relationship between block number and offset when using superblocks.

[0028] Figure 17 It is a sequence diagram showing the order of write operations performed by the host and the memory system of this embodiment.

[0029] Figure 18 It is a diagram that represents the action of writing data update data to previously written data.

[0030] Figure 19 This diagram illustrates the operation of updating the block management table managed by the memory system using this implementation.

[0031] Figure 20 It is a diagram used to illustrate the action of updating the lookup table (logical entity address translation table) managed by the host.

[0032] Figure 21 This is a diagram used to illustrate the action of updating the block management table based on a notification from the host indicating the entity address corresponding to the data to be invalidated.

[0033] Figure 22 This diagram illustrates the read commands applied to the memory system of this embodiment.

[0034] Figure 23 This diagram illustrates the read operation performed by the memory system using this embodiment.

[0035] Figure 24 It is a diagram used to illustrate the action of reading data stored in different physical storage locations according to read commands from the host.

[0036] Figure 25 It is a sequence diagram showing the order of read processes performed by the host and the memory system of this embodiment.

[0037] Figure 26 This diagram illustrates the garbage collection (GC) control commands applied to the memory system of this embodiment.

[0038] Figure 27 This diagram illustrates the GC callback commands used in the memory system of this implementation.

[0039] Figure 28 This is a sequence diagram showing the program for garbage collection (GC) operations performed by the memory system using this implementation.

[0040] Figure 29 This is a diagram used to illustrate an example of a data copying action performed for garbage collection (GC).

[0041] Figure 30 It is used to base on Figure 29 The diagram illustrates the results of the data replication operation and the updated lookup table content on the host.

[0042] Figure 31 It is a diagram used to illustrate the relationship between the response to write commands and the callback processing of GC.

[0043] Figure 32 This is a diagram illustrating another example of the garbage collection (GC) control commands applied to the memory system of this embodiment.

[0044] Figure 33This diagram illustrates another example of the GC callback command used in the memory system of this implementation.

[0045] Figure 34 This diagram illustrates the write / read / GC operations performed by the memory system using this implementation.

[0046] Figure 35 This is a diagram illustrating an example of the structure of a block management table used to manage reference counting.

[0047] Figure 36 This diagram illustrates the repetitive commands applied to the memory system of this embodiment.

[0048] Figure 37 This is a diagram used to illustrate the Trim command, which reduces the reference count by 1.

[0049] Figure 38 This is a sequence diagram illustrating the reference count increment / decrement process performed by the host and the memory system of this embodiment. Detailed Implementation

[0050] Hereinafter, the embodiments will be described with reference to the accompanying drawings.

[0051] First, refer to Figure 1 The configuration of a computer system including a memory system according to one embodiment will be described.

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

[0053] The computer system may include a host (host device) 2 and multiple flash storage devices 3. The host 2 may be a server configured to use a flash array containing multiple flash storage devices 3 as memory. The host (server) 2 and the multiple flash storage devices 3 are interconnected (internal interconnection) via an interface 50. As the interface 50 for this internal interconnection, PCI Express (PCIe, Peripheral Component Interconnect Express) (registered trademark), NVM Express (NVMe, Non-Volatile Memory Express) (registered trademark), Ethernet (registered trademark), NVMe over Fabrics (NVMeOF), etc., may be used, but are not limited to these.

[0054] A typical example of a server functioning as host 2 is a server within a data center.

[0055] In an example where host 2 is implemented using a server within a data center, host 2 can be connected to multiple end-user terminals (user terminals) 61 via network 51. Host 2 is able to provide various services to these end-user terminals 61.

[0056] Examples of services that can be utilized by host (server) 2 include: (1) Platform as a Service (PaaS) that provides a system development platform to each user terminal (each end user terminal 61), and (2) Infrastructure as a Service (IaaS) that provides infrastructure such as virtual servers to each user terminal (each end user terminal 61).

[0057] Multiple virtual machines can run on the physical server that functions as host (server) 2. Each of these virtual machines running on host (server) 2 can function as a virtual server that provides various services to its corresponding number of client terminals (end-user terminals 61).

[0058] The host (server) 2 includes memory management functions for managing multiple flash storage devices 3 that constitute a flash array, and front-end functions for providing various services including memory access to end user terminals 61.

[0059] In existing SSDs, the block / page hierarchy of NAND flash memory is hidden using the Flash Translation Layer (FTL) within the SSD. That is, the existing SSD's FTL has the following functions: (1) using a lookup table that functions as a logical address translation table to manage the mapping between logical addresses and physical addresses of the NAND flash memory; (2) hiding page-based read / write operations and block-based delete operations; and (3) performing garbage collection (GC) of the NAND flash memory. The mapping between logical addresses and physical addresses of the NAND flash memory is not visible to the host. The block / page structure of the NAND flash memory is also not visible to the host.

[0060] On the other hand, there are cases where address translation (application-level address translation) is also performed on the host. This address translation uses an application-level address translation table to manage the mapping between logical addresses used by the application and logical addresses used by the SSD. In addition, on the host, a garbage collection (GC) (application-level GC) is also performed to change the data configuration in the logical address space to eliminate fragmentation generated in the logical address space of the SSD.

[0061] However, in a redundant configuration where both the host and SSD have address translation tables (the SSD has a lookup table that functions as a logical entity address translation table, and the host has an application-level address translation table), storing these address translation tables consumes enormous memory resources. Furthermore, the dual address translation, involving both host-side and SSD-side address translation, also contributes to reduced I / O performance.

[0062] Furthermore, application-level garbage collection (GC) on the host side becomes a factor that increases the amount of data written to the SSD by several times (e.g., twice) the amount of real-time user data. While this increase in data write volume does not increase the write amplification of the SSD, it reduces the overall storage performance of the system and also shortens the lifespan of the SSD.

[0063] To eliminate this problem, a solution has been proposed to transfer all the functions of the existing SSD's FTL to the host.

[0064] However, to implement this countermeasure, the host must directly process the blocks and pages of the NAND flash memory. The capacity of NAND flash memory increases with each generation, and consequently, the block / page size varies with each generation. Therefore, the possibility of using NAND flash memory with different block and page sizes in the host machine was considered. However, handling different block / page sizes is difficult for the host. Furthermore, assuming that an unpredictable number of bad pages may exist due to various manufacturing reasons, the number of usable pages within each block may differ, potentially resulting in different block sizes within each block of the NAND flash memory. This makes handling bad pages and uneven block sizes even more difficult for the host.

[0065] Therefore, in this embodiment, the FTL function is shared between host 2 and flash storage device 3. Host 2 manages the lookup table, which functions as a logical entity address translation table, but the selection of blocks to be written is performed by flash storage device 3, not host 2. Furthermore, GC is performed by flash storage device 3, not host 2. Hereinafter, the FTL function transferred to host 2 will be referred to as global FTL.

[0066] The global FTL of host 2 may have functions such as performing storage services, managing lookup tables (LUTs), wear control, achieving high availability, and preventing duplicate data from being stored in memory.

[0067] On the other hand, the flash storage device 3 is capable of performing low-level abstraction (LLA). LLA is a function of abstraction for NAND flash memory. LLA includes functions such as absorbing block size inhomogeneities, absorbing block / page structures, and auxiliary data configuration. The auxiliary data configuration functions include determining the source block and target block for copying useless information, notifying the upper level (host 2) of the copy target location of valid data, determining the write target location (block number, position within that block) of user data, and notifying the upper level (host 2) of the write target location (block number, position within that block) of the write already written user data. In addition, LLA has the function of performing garbage collection (GC). Furthermore, LLA also has QoS control functions for performing resource management of flash storage device 3 for each domain (QoS (Quality of Service) domain).

[0068] The QoS control function includes the ability to determine the access unit for each QoS domain (or each block). The access unit represents the minimum data size (Grain) that host 2 can write / read. Flash storage device 3 supports single or multiple access units (Grains), and when flash storage device 3 supports multiple access units, host 2 instructs flash storage device 3 on the access unit to be used for each QoS domain (or each block).

[0069] In addition, the QoS control function includes features to minimize performance interference between QoS domains. This function is essentially designed to maintain stable latency.

[0070] To achieve this functionality, the flash storage device 3 can classify the multiple blocks within the NAND flash memory into multiple groups, such that each block belongs to only one group. In this case, each group contains multiple blocks, but there are no cases where different groups share the same block. These multiple groups function as the multiple QoS domains.

[0071] Alternatively, the flash storage device 3 can classify the multiple NAND flash memory chip blocks within it into multiple groups (multiple QoS domains) such that each NAND flash memory chip block belongs to only one group (one QoS domain). In this case, each group (QoS domain) contains multiple chip blocks, but there is no situation where different QoS domains share the same chip block.

[0072] Figure 2 This indicates the interaction allocation between the existing SSD and the host, and the interaction allocation between the flash storage device 3 and the host 2 in this embodiment.

[0073] Figure 2The left side represents the overall hierarchical structure of a computer system, including existing SSDs and hosts that perform virtual disk services.

[0074] In the host (server), a virtual machine service 101 is executed to provide multiple virtual machines to multiple end users. In each virtual machine on the virtual machine service 101, an operating system and user application 102 used by the corresponding end user are executed.

[0075] Additionally, on the host (server), multiple virtual disk services 103 corresponding to multiple user applications 102 are executed. Each virtual disk service 103 allocates a portion of the storage capacity within an existing SSD as storage resources (virtual disks) for the corresponding user application 102. Within each virtual disk service 103, application-level address translation (APC) is also performed, using an application-level address translation table to convert application-level logical addresses to SSD logical addresses. Furthermore, on the host, application-level garbage collection (GC) 104 is also executed.

[0076] The sending of commands from the host (server) to the existing SSD and the return of the command completion response from the existing SSD to the host (server) are performed via the I / O queues 200 of the host (server) and the existing SSD, respectively.

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

[0078] In this configuration, write amplification increases due to the overlapping GC between the application-level GC 104 under virtual disk service 103 and the useless information collection function 303 (LUT-level GC) in the existing SSD. Furthermore, in existing SSDs, adjacency interference may occur, meaning that the increased GC frequency due to increased data writes from a particular end user or virtual disk service 103 leads to I / O performance degradation for other end users or other virtual disk services 103.

[0079] In addition, a large amount of storage resources are consumed due to the existence of duplicate resources, including application-level address translation tables in each virtual disk service and LUT302 in existing SSDs.

[0080] Figure 2 The right side represents the hierarchical structure of the computer system, which includes the flash storage device 3 and the host 2 in this embodiment.

[0081] On host (server) 2, virtual machine service 401 is executed to provide multiple virtual machines to multiple end users. In each virtual machine on virtual machine service 401, the operating system and user application 402 used by the corresponding end user are executed.

[0082] Additionally, in host (server) 2, multiple I / O services 403 corresponding to multiple user applications 402 are executed. These I / O services 403 may include block I / O services based on LBA (Logical Block Address), key-value storage services, etc. Each I / O service 403 includes a lookup table (LUT) that manages the mapping between each logical address and the physical address of the flash storage device 3. Here, a logical address means an identifier that can identify the data of the accessed object. This logical address can be a logical block address (LBA) specifying a location in the logical address space, or it can be a key (tag) of a key-value store.

[0083] In LBA-based block I / O services, LUTs mapping the logical addresses (LBAs) to the physical addresses of the flash storage device 3 can also be used.

[0084] In key-value storage services, a Levelly Unified Address (LUT) can also be used to map each logical address (i.e., a tag like a key) to a physical address of the flash storage device 3, which stores data corresponding to these logical addresses (i.e., tags like keys). This LUT can also manage the mapping between tags, the physical address of the data identified using those tags, and the data length of that data.

[0085] Each end user can choose the addressing method to use (LBA, key-value storage, etc.).

[0086] These LUTs do not translate the logical addresses from the user application 402 into individual logical addresses for each flash storage device 3, but rather translate the logical addresses from the user application 402 into physical addresses for each flash storage device 3. In other words, these LUTs are a combination of the table that translates the logical addresses of the flash storage device 3 into physical addresses and the application-level address translation table.

[0087] In host (server) 2, there is an I / O service 403 in each QoS domain. The I / O service 403 belonging to a certain QoS domain manages the mapping between its logical address and its physical address. The logical address is the logical address used by the user application 402 in the corresponding QoS domain, and the physical address is the physical address of the block group belonging to the resource group allocated to the corresponding QoS domain.

[0088] The transmission of commands from host (server) 2 to flash storage device 3 and the return of responses from flash storage device 3 to host (server) 2, are performed via I / O queues 500 existing in both host (server) 2 and flash storage device 3. These I / O queues 500 can also be classified into multiple queue groups corresponding to multiple QoS domains.

[0089] The flash storage device 3 includes multiple write buffers (WBs) 601 corresponding to multiple QoS domains, multiple garbage collection (GC) functions 602 corresponding to multiple QoS domains, and NAND flash memory (NAND flash array) 603.

[0090] In Figure 2 In the configuration shown on the right, the LUT302 in the existing SSD and the application-level address translation table are merged into a single LUT within the I / O service 403, thus reducing the amount of memory resources consumed by storing address translation information. Furthermore, the reduced number of address translation stages improves I / O performance.

[0091] Furthermore, instead of performing repetitive GC that includes application-level GC and LUT-level GC, the flash storage device 3 performs only data copying for GC (unified GC). Therefore, compared to configurations that perform repetitive GC, overall system write amplification can be significantly reduced. As a result, I / O performance is improved, and the lifespan of the flash storage device 3 is maximized.

[0092] Figure 3 express Figure 1 Examples of changes in the system composition.

[0093] exist Figure 3 In this process, data transfer between multiple hosts 2A and multiple flash storage devices 3 is performed via a network machine (here, network switch 1).

[0094] In other words, Figure 3 In the computer system, Figure 1 The storage management function of server 2 is transferred to manager 2B, and the front-end function of server 2 is transferred to multiple hosts (end-user service hosts) 2A.

[0095] Manager 2B manages multiple flash storage devices 3 and allocates storage resources of these flash storage devices 3 to each host (end-user service host) 2A according to the requests from each host (end-user service host) 2A.

[0096] Each host (end-user service host) 2A is connected to one or more end-user terminals 61 via a network. Each host (end-user service host) 2A manages a lookup table (LUT) that serves as the consolidated (merged) logical entity address translation table. Each host (end-user service host) 2A uses its own LUT and only manages the mapping between the logical addresses used by the corresponding end-users and the entity addresses of the resources allocated to it. Therefore, this configuration allows the system to be easily scaled horizontally.

[0097] Each host 2A's global FTL has functions such as managing lookup tables (LUTs), implementing high availability, deduplication, and QoS policy control.

[0098] Manager 2B is a dedicated device (computer) used to manage multiple flash storage devices 3. Manager 2B has a global resource reservation function that reserves storage resources of the capacity requested by each host 2A. Furthermore, Manager 2B has a wear monitoring function that monitors the consumption level of each flash storage device 3, a NAND resource allocation function that allocates reserved storage resources (NAND resources) to each host 2A, a QoS policy control function, and a global clock management function, etc.

[0099] Each flash storage device 3 has a local FTL. This local FTL is used to coordinate with the global FTL of each host 2A. The local FTL may include QoS control functions, functions for managing write buffers of each QoS domain, functions for performing GC data copying within or between QoS domains, LUT copying functions for recovery, functions for managing reference counts for deduplication, workload parsing functions, and housekeeping functions, etc.

[0100] according to Figure 3 In this system configuration, the management of each flash memory device 3 is performed using the manager 2B. Therefore, each host 2A only needs to perform actions such as sending I / O requests to one or more flash memory devices 3 assigned to it and receiving responses from the flash memory devices 3. In other words, data transfer between multiple hosts 2A and multiple flash memory devices 3 is performed only through switch 1, and the manager 2B is not involved in this data transfer. In addition, as mentioned above, the contents of the LUTs managed by each host 2A are independent of each other. Therefore, the number of hosts 2A can be easily increased, thus enabling a horizontally scalable system configuration.

[0101] Figure 4 This shows an example of the configuration of flash storage device 3.

[0102] The flash storage device 3 includes a controller 4 and non-volatile memory (NAND flash memory) 5. The flash storage device 3 may also include random access memory such as DRAM (Dynamic Random Access Memory) 6.

[0103] The NAND flash memory 5 includes a memory cell array containing multiple memory cells configured in a matrix. The NAND flash memory 5 can be a two-dimensional NAND flash memory or a three-dimensional NAND flash memory.

[0104] The NAND flash memory 5's cell array comprises multiple blocks BLK0 to BLKm-1. Each block BLK0 to BLKm-1 is composed of multiple pages (here, pages P0 to Pn-1). Blocks BLK0 to BLKm-1 function as deletion units. Blocks are sometimes also called "delete blocks," "physical blocks," or "physical delete blocks." Pages P0 to Pn-1 each contain multiple memory cells connected to the same word line. Pages P0 to Pn-1 are the units for data write and data read operations.

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

[0106] like Figure 5 As shown, the NAND flash memory 5 comprises multiple NAND flash memory chip blocks. Each NAND flash memory chip block is a non-volatile memory chip block including a memory cell array containing multiple blocks (BLKs) and peripheral circuitry controlling the memory cell array. Each NAND flash memory chip block can operate independently. Therefore, the NAND flash memory chip blocks function as parallel operating units. NAND flash memory chip blocks are also referred to as "NAND flash memory chips" or "non-volatile memory chips." Figure 5For example, the following scenario illustrates a NAND interface 13 connected to 16 channels Ch1, Ch2, ... Ch16, each of which is connected to the same number (e.g., 2 chips per channel) of NAND flash memory chips. Each channel contains a communication line (memory bus) for communicating with the corresponding NAND flash memory chip.

[0107] Controller 4 controls NAND flash memory chip blocks #1 to #32 via channels Ch1, Ch2, ... Ch16. Controller 4 can simultaneously drive channels Ch1, Ch2, ... Ch16.

[0108] Sixteen NAND flash memory chip blocks #1 to #16 connected to channels Ch1 to Ch16 can be configured into the first memory bank. Additionally, the remaining sixteen NAND flash memory chip blocks #17 to #32 connected to channels Ch1 to Ch16 can be configured into the second memory bank. The memory bank functions as a unit for enabling multiple memory modules to operate in parallel through memory bank cross-connection. Figure 5 In this configuration example, by using 16 channels and memory bank crossover with 2 memory banks, up to 32 NAND flash memory chip blocks can be connected in parallel.

[0109] In this embodiment, the controller 4 can manage multiple blocks (hereinafter referred to as super blocks) that each contain multiple blocks BLK, and can also perform deletion operations on a super block basis.

[0110] A superblock is not limited to this and can also contain 32 blocks (BLKs) selected from each of NAND flash memory chip blocks #1 to #32. Furthermore, each of the NAND flash memory chip blocks #1 to #32 can also have a multi-plane configuration. For example, when each of the NAND flash memory chip blocks #1 to #32 has a multi-plane configuration containing two planes, a superblock can contain 64 blocks (BLKs) selected from each of the 64 planes corresponding to the NAND flash memory chip blocks #1 to #32. Figure 6 In the example, a superblock SB contains 32 blocks BLK, each selected from NAND flash memory chip blocks #1 to #32. Figure 5 The case of a block (BLK) surrounded by a thick border.

[0111] like Figure 4 As shown, the controller 4 includes a host interface 11, a CPU 12, a NAND interface 13, and a DRAM interface 14. These CPU 12, NAND interface 13, and DRAM interface 14 are interconnected via a bus 10.

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

[0113] CPU 12 is a processor configured with a host interface 11, a NAND interface 13, and a DRAM interface 14. In response to power-on of the flash storage device 3, CPU 12 loads a control program (firmware) from the NAND flash memory 5 or a ROM (Read Only Memory) not shown into the DRAM 6, and then executes the firmware to perform various processes. Alternatively, the firmware can be loaded into an SRAM (Static Random Access Memory) not shown within the controller 4. CPU 12 can perform command processing, etc., to handle various commands from the host 2. The operation of CPU 12 is controlled by the firmware executed by CPU 12. Furthermore, some or all of the command processing can be executed using dedicated hardware within the controller 4.

[0114] CPU 12 functions as a write action control unit 21, a read action control unit 22, and a GC action control unit 23. These write action control units 21, read action control units 22, and GC action control units 23 are equipped with components for implementing… Figure 2 The system's application programming interface (API) is shown on the right.

[0115] The write action control unit 21 receives a write request (write command) from the host 2 for a specified logical address. The logical address is an identifier that can identify the data (user data) to be written; for example, it can be an LBA or a label like a key in key-value storage. When a write command is received, the write action control unit 21 first determines the block of data to be written from the host 2 (the write target block) and the location within that block (the write target location). Next, the write action control unit 21 writes the data from the host 2 (the write data) to the write target location of the write target block. In this case, the write action control unit 21 can not only write the data from the host 2, but also write both the data and its logical address to the write target block.

[0116] Then, the write operation control unit 21 sends back the specified logical address and the physical address (physical storage location) indicating the location in the NAND flash memory 5 where the data has been written (written data) to the host 2.

[0117] In this case, the entity address is represented using (1) the block number of the target block to be written to, and (2) the intra-block offset representing the write target location within the target block. The block number is an identifier that specifies the block to which data is being written. Various values ​​that can uniquely identify any one of multiple blocks can be used as the block number.

[0118] Intra-block offset represents the offset from the beginning of the target block to the target location, that is, the offset of the target location relative to the beginning of the target block. The size of this offset is expressed as a multiple of a granularity that is different from the page size. A granularity is the access unit. The maximum size of the granularity is limited to the block size. In other words, intra-block offset represents the offset from the beginning of the target block to the target location in a multiple of a granularity that is different from the page size.

[0119] Granularity can be smaller than the page size. For example, when the page size is 16KB, the granularity size can be 4KB. In this case, multiple offset positions, each 4KB in size, are specified within a given block. The intra-block offset corresponding to the initial offset position within the block is, for example, 0; the intra-block offset corresponding to the next offset position within the block is, for example, 1; and the intra-block offset corresponding to the next offset position after that is, for example, 2.

[0120] Alternatively, the granularity can also be larger than the page size. For example, the granularity can be several times the page size. When the page size is 16KB, the granularity can be 32KB.

[0121] In this way, the write operation control unit 21 automatically determines both the block to be written and the location within that block, and then notifies the host 2 of the block number and the offset within the block as the physical address representing the location where data (user data) from the host 2 has been written, instead of notifying the block number and page number. Therefore, the host 2 can write user data to the NAND flash memory 5 without being concerned about block size, page write order constraints, bad pages, page size, etc., and furthermore, it can map the physical address represented by the block number and the offset within the block to the logical address of the user data.

[0122] When the read operation control unit 22 receives a read request (read command) from the host 2 for a specified entity address (i.e., block number and intra-block offset), it reads data from the NAND flash memory 5 based on these block numbers and intra-block offsets. The block to be read is specified using the block number. The storage location of the entity to be read within that block is specified using the intra-block offset. By using the intra-block offset, the host 2 does not need to handle the different page sizes of each generation of the NAND flash memory.

[0123] In order to obtain the physical storage location of the object to be read, the read action control unit 22 first divides the offset within the block by the number representing the granularity of the page size (4 in this case), and then determines the page number and the offset within the page of the object to be read by the quotient and the remainder obtained by the division, respectively.

[0124] When performing useless information collection in the NAND flash memory 5, the GC action control unit 23 selects a source block (GC source block) and a target block (GC destination block) from multiple blocks within the NAND flash memory 5 for the useless information collection. In this case, the GC action control unit 23 typically selects multiple source blocks (GC source blocks) and one or more target blocks (GC destination blocks). The conditions (GC strategy) for selecting the source blocks (GC source blocks) can be specified by the host 2. For example, a GC strategy that prioritizes selecting the block with the least amount of valid data can be used, or other GC strategies can be used. In this way, the selection of the source blocks (GC source blocks) and target blocks (GC destination blocks) is not performed by the host 2 but by the controller 4 (GC action control unit 23) of the flash storage device 3. The controller 4 can also use a block management table to manage the amount of valid data in each block.

[0125] When the host 2 receives a command (GC control command) specifying the source group (source QoS domain) and target group (destination QoS domain) for collecting useless information, the GC action control unit 23 selects the source block for collecting useless information from the block group belonging to the source group and selects the target block for collecting useless information from the block group belonging to the target group.

[0126] The management of valid / invalid data can also be performed using block management table 32. This block management table 32 can exist, for example, in each block. In the block management table 32 corresponding to a particular block, bitmap flags indicating the validity / invalidity of the data within that block are stored. Here, valid data refers to data referenced from the LUT (i.e., data associated with a logical address as the latest data) and data that may subsequently be read from host 2. Invalid data refers to data that can no longer be read from host 2. For example, data associated with a logical address is valid data, and data not associated with any logical address is invalid data.

[0127] The GC action control unit 23 determines the location (replication target location) within the replication target block (GC destination block) where the valid data stored in the replication source block (GC source block) should be written, and copies the valid data to the determined location (replication target location) in the replication target block (GC destination block). In this case, the GC action control unit 23 can copy both the valid data and its logical address to the replication target block (GC destination block). The GC action control unit 23 can identify the valid data in the GC source block by referring to the block management table 32 corresponding to the replication source block (GC source block). Alternatively, in another embodiment, the host 2 can perform the management of valid / invalid data. In this case, the GC action control unit 23 can receive information from the host 2 indicating the validity / invalidity of each piece of data in the GC source block, and identify the valid data in the GC source block based on the received information.

[0128] Then, the GC action control unit 23 notifies the host 2 of the logical address of the valid data to be copied, the block number of the target block (GC destination block), and the intra-block offset, which represents the offset from the front end of the target block (GC destination block) to the target location in multiples of the granularity.

[0129] In this embodiment, as described above, the write action 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 target block. Therefore, the GC action control unit 23 can easily obtain the logical addresses of each data in the copy source block (GC source block) from the copy source block, and thus can easily notify the host 2 of the logical address of the valid data being copied.

[0130] NAND interface 13 is a memory control circuit configured to control NAND flash memory 5 under the control of CPU 12. DRAM interface 14 is a DRAM control circuit configured to control DRAM 6 under the control of CPU 12. A portion of the storage area of ​​DRAM 6 is used for storing write buffers (WBs) 31. Another portion of the storage area of ​​DRAM 6 is used for storing block management tables 32. Furthermore, these write buffers (WBs) 31 and block management tables 32 can also be stored in SRAM (not shown) within controller 4.

[0131] Figure 7 This indicates the write command applied to flash storage device 3.

[0132] A write command is a command that requests data to be written to the flash storage device 3. This write command may include a command ID (Identity), QoS domain ID, logical address, length, etc.

[0133] The command ID is the ID (command code) that indicates that the command is a write command. The write command contains the command ID used for writing.

[0134] A QoS domain ID is an identifier that uniquely identifies the QoS domain to which data should be written. A write command sent from host 2 based on a write request from a specific end user may contain a QoS domain ID specifying the QoS domain corresponding to that end user. A namespace ID can be considered a QoS domain ID.

[0135] A logical address is an identifier used to identify the data to be written. As mentioned above, this logical address can be either an LBA or a key in a key-value store. When the logical address is an LBA, the logical address (starting LBA) included in the write command indicates the logical location (initial logical location) where the data should be written.

[0136] The length indicates the length of the data to be written. This length (data length) can be specified by the number of grains, the number of LBAs, or its size in bytes.

[0137] As described above, controller 4 can classify the multiple blocks within NAND flash memory 5 into multiple groups (multiple QoS domains) such that each block within NAND flash memory 5 belongs to only one group. Then, controller 4 can manage the list of idle blocks (idle block pool) and the list of active blocks (active block pool) for each group (QoS domain).

[0138] The status of each block is roughly divided into active blocks that store valid data and idle blocks that do not store valid data. Active blocks are managed by an active block list. On the other hand, idle blocks are managed by an idle block list.

[0139] When a write command is received from host 2, controller 4 determines the block of data to be written from host 2 (the target block) and its location within that target block (the target location). Controller 4 may select one of the idle blocks belonging to the QoS domain corresponding to the QoS domain ID as the target block. The target location is determined considering page write order constraints and bad pages. Then, controller 4 writes the data from host 2 to the target location within the target block.

[0140] Furthermore, if the target block for writing is already full of user data, controller 4 moves the target block to the active block list (active block pool). Then, controller 4 selects an idle block from the idle block list corresponding to the QoS domain and assigns the selected idle block as the new target block for writing.

[0141] If the number of remaining idle blocks managed by the idle block list falls below a threshold determined by a prescribed policy, or if host 2 instructs the implementation of useless information collection, controller 4 may begin useless information collection for that QoS domain.

[0142] During the collection of useless information in this QoS domain, controller 4 selects a copy source block (GC source block) and a copy target block (GC destination block) from the group of active blocks corresponding to this QoS domain. The selection of which block is chosen as a GC candidate (copy source block) can be determined either according to the policy specified by host 2 or by host 2 itself. In the case where the selection is also based on a policy, for example, the block with the least amount of valid data can be selected as the GC candidate (copy source block).

[0143] Figure 8 Indicates to Figure 7 The response to the write command.

[0144] The response includes the logical address, the physical address, and the length.

[0145] Logical address is Figure 7 The logical address contained in the write command.

[0146] Entity address representation based on Figure 7The write command specifies the physical storage location within the NAND flash memory 5 where the data is written. In this embodiment, the physical address is not specified by a combination of block number and page number, but rather by a combination of block number and offset (intra-block offset) as described above. The block number is an identifier that uniquely identifies any one of all blocks within the flash memory 3. These block numbers can be used directly when different block numbers are assigned to all blocks. Alternatively, the block number can be represented using a combination of chip block number and intra-chip block number. The length indicates the length of the write data to be written. This length (data length) can be specified by the number of grains, the number of LBAs, or its size in bytes.

[0147] Figure 9 This indicates the Trim command used by flash storage device 3.

[0148] The Trim command contains the block number and offset within the block indicating the storage location of the entity containing data that should be invalidated. In other words, the Trim command does not specify a logical address like an LBA, but rather a physical address. The Trim command includes a command ID, the physical address, and a length.

[0149] The command ID is the ID (command code) that indicates that the command is a Trim command. The Trim command contains the command ID used by the Trim command.

[0150] The entity address represents the initial physical storage location where the data to be invalidated is stored. In this embodiment, the entity address is specified by a combination of the block number and the offset (offset within the block).

[0151] The length indicates the length of the data to be invalidated. This length (data length) can be specified by the number of granularities or by bytes.

[0152] Controller 4 uses block management table 32 to manage the valid / invalid flags (bitmap flags) representing the data contained in multiple blocks. When a Trim command is received from host 2 containing the block number and offset (intra-block offset) of the physical storage location that stores data that should be invalidated, controller 4 updates block management table 32, changing the flag (bitmap flag) corresponding to the data of the physical storage location corresponding to the block number and intra-block offset contained in the Trim command to a value indicating invalidity.

[0153] Figure 10 This indicates the block number and offset of the specified entity address.

[0154] The block number specifies a particular block (BLK). For example... Figure 10 As shown, each block BLK contains multiple pages (here, page 0 to page n).

[0155] In an instance where the page size (the user data storage area for each page) is 16KB and the granularity is 4KB, the block BLK is logically divided into 4×(n+1) regions.

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

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

[0158] Figure 11 This indicates the relationship between the write action performed in response to a write command and the return value contained in the response to that write command.

[0159] The controller 4 of the flash storage device 3 uses a list of idle blocks to manage groups of idle blocks that do not contain valid data. It selects a block (idle block) from these groups and assigns it as the target block for writing. Now, assume that block BLK#1 is assigned as the target block for writing. The controller 4 writes data to block BLK#1 in page-by-page order: page 0, page 1, page 2, ..., page n.

[0160] exist Figure 11 In this example, assuming 16KB of data has already been written to page 0 of block BLK#1, a write command with a specified logical address (LBAx) and length (=4) is received from host 2. Controller 4 determines page 1 of block BLK#1 as the write target location and writes the 16KB of data received from host 2 to page 1 of block BLK#1. Then, controller 4 sends back the response to the write command (logical address, block number, offset (intra-block offset), length) to host 2. In this example, the logical address is LBAx, the block number is BLK#1, the offset (intra-block offset) is +5, and the length is 4.

[0161] Figure 12 This indicates that the write operation will skip bad pages.

[0162] exist Figure 12In this example, assuming data has already been written to pages 0 and 1 of block BLK#1, a write command with a specified logical address (LBAx+1) and length (=4) is received from host 2. If page 2 of block BLK#1 is a bad page, then controller 4 determines page 3 of block BLK#1 as the write target location and writes the 16KB of data received from host 2 to page 3 of block BLK#1. Then, controller 4 sends back the response to the write command (logical address, block number, offset (intra-block offset), length) to host 2. In this example, the logical address is LBAx+1, the block number is BLK#1, the offset (intra-block offset) is +12, and the length is 4.

[0163] Figure 13 Another example of a write operation that skips bad pages.

[0164] exist Figure 13 In the following scenario, consider writing data across two pages separated by a faulty page. Now, assume that data has already been written to pages 0 and 1 of block BLK#2, and 8KB of unwritten data remains in write buffer 31. In this state, if a write command with a specified logical address (LBAy) and length (=6) is received, controller 4 uses the unwritten 8KB of data and the initial 8KB of data from the 24KB of newly received data from host 2 to prepare 16KB of write data corresponding to the page size. Then, controller 4 writes this prepared 16KB of write data to page 2 of block BLK#2.

[0165] If the next page 3 of block BLK#2 is a bad page, then controller 4 will determine page 4 of block BLK#2 as the next write target location and write the remaining 16K bytes of write data from the 24K bytes of write data received from host 2 to page 4 of block BLK#2.

[0166] Then, controller 4 sends back the response to the write command (logical address, block number, offset (intra-block offset), length) to host 2. In this example, the response may include LBAy, block number (=BLK#2), offset (=+10), length (=2), block number (=BLK#2), offset (=+16), length (=4).

[0167] Figure 14 , Figure 15 This indicates the action of writing the logical address and data pairing into a page within the block.

[0168] Within each block, each page may contain a user data area for storing user data and a redundant area for storing management data. The page size is 16KB+α.

[0169] Controller 4 writes both 4KB of user data and its corresponding logical address (e.g., LBA) to the write target block BLK. In this case, such as Figure 14 As shown, four data sets, each containing LBA and 4KB of user data, can be written to the same page. The offset within the block can also represent the boundary of the set.

[0170] Or, it can be like Figure 15 As shown, four 4KB user data entries are written to the user data area within the page, and four LBAs corresponding to these four 4KB user data entries are written to the redundant area within the page.

[0171] Figure 16 This indicates the relationship between the block number and the offset (internal offset) in an instance using a superblock. Hereinafter, the intra-block offset will also be referred to simply as the offset.

[0172] Here, for the sake of simplicity, it is assumed that a superblock SB#1 contains four blocks BLK#11, BLK#21, BLK#31, and BLK#41. 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, ...

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

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

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

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

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

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

[0179] For example, when writing 4K bytes of data corresponding to a write command specifying a certain LBA (LBAx) to the position corresponding to offset +8, controller 4 can send back the logical address (=LBAx), block number (=SB#1), offset (=+8), and length (=1) as a response to the write command to host 2.

[0180] Figure 17 This indicates the order in which write operations are performed using host 2 and flash storage device 3.

[0181] Host 2 sends a write command containing the QoS domain ID, LBA, and length to flash storage device 3. When the controller 4 of flash storage device 3 receives the write command, the controller 4 determines the target block for the write data from host 2 and the location within that target block. More specifically, the controller 4 selects an idle block from the list of idle blocks and allocates the selected idle block as the target block for the write (step S12). That is, the selected idle block and the first available page within the selected idle block are determined as the target block for the write data from host 2 and the location within that target block. If a target block for the write has already been allocated, the target block allocation process in step S12 is not required. The next available page within the already allocated target block is determined as the location within the target block for the write data from host 2.

[0182] Controller 4 can manage multiple lists of idle blocks corresponding to multiple QoS domains. Alternatively, it can register only the group of blocks reserved for a specific QoS domain in the list of idle blocks corresponding to that QoS domain. In this case, in step S12, controller 4 can also select an idle block from the list of idle blocks corresponding to the QoS domain specified by the QoS domain ID of the write command, and assign the selected idle block as the write target block. This prevents data corresponding to different QoS domains from being mixed in the same block.

[0183] The controller 4 writes the write data received from the host 2 to the write target block (step S12). In step S12, the controller 4 writes both the logical address (here, LBA) and the write data to the write target block.

[0184] Controller 4 updates block management table 32, changing the bitmap flag corresponding to the written data (i.e., the bitmap flag corresponding to the entity address of the entity storage location where the data is written) from 0 to 1 (step S13). For example, as Figure 18 As shown, this assumes that 16KB of update data with a starting LBA of LBAx is written to the physical storage location corresponding to offsets +4 to +7 of block BLK#1. In this case, as... Figure 19 As shown, in the block management table for block BLK#1, the bitmap flags corresponding to offsets +4 to +7 are changed from 0 to 1 respectively.

[0185] Controller 4 sends a response to the write command back to host 2 (step S14). For example, as Figure 18 As shown, if 16K bytes of update data with a starting LBA of LBAx are written to the physical storage location corresponding to the offset +4 to +7 of block BLK#1, then a response containing LBAx, block number (=BLK1), offset (=+4), and length (=4) will be sent from controller 4 to host 2.

[0186] When host 2 receives this response, host 2 updates the LUT managed by host 2, mapping the logical addresses corresponding to the written data to the physical addresses. For example... Figure 20 As shown, a LUT contains multiple entries corresponding to multiple logical addresses (e.g., LBAs). In the entry corresponding to a specific logical address (e.g., a specific LBA), the physical address PBA, i.e., the block number and offset (offset within the block), is stored, indicating the location (physical storage location) within the NAND flash memory 5 where the data corresponding to that LBA is stored. For example... Figure 18As shown, if 16KB of update data with a starting LBA of LBAx is written to the physical storage location corresponding to offset +4 to +7 of block BLK#1, then as Figure 20 As shown, update the LUT by storing BLK#1 and offset +4 in the entry corresponding to LBAx, storing BLK#1 and offset +5 in the entry corresponding to LBAx+1, storing BLK#1 and offset +6 in the entry corresponding to LBAx+2, and storing BLK#1 and offset +7 in the entry corresponding to LBAx+3.

[0187] Subsequently, host 2 sends a Trim command to flash storage device 3 to invalidate past data that has become useless due to the writing of the updated data (step S21). For example... Figure 18 As shown, when past data is stored at positions corresponding to offsets +0, +1, +2, and +3 of block BLK#0, such as... Figure 21 As shown, host 2 sends a Trim command to flash storage device 3 specifying block number (=BLK#0), offset (=+0), and length (=4). Controller 4 of flash storage device 3 updates block management table 32 according to this Trim command (step S15). In step S15, as... Figure 21 As shown, in the block management table for block BLK#0, the bitmap flags corresponding to offsets +0 to +3 are changed from 1 to 0 respectively.

[0188] Figure 22 This indicates the read command used by flash storage device 3.

[0189] A read command is a command that requests data from flash storage device 3. This read command includes a command ID, physical address PBA, length, and transfer target indicator.

[0190] The command ID is the ID (command code) that indicates that the command is a read command. The read command contains the command ID used for the read command.

[0191] The Entity Address (PBA) indicates the initial physical storage location of the data to be read. The Entity Address (PBA) is specified by the block number and the offset (offset within the block).

[0192] The length indicates the length of data to be read. This data length can be specified by the number of grains.

[0193] The transmission target indicator indicates the location on the memory within host 2 where the read data should be transmitted.

[0194] A read command can specify multiple entity addresses PBA (block number, offset) and length groups.

[0195] Figure 23 This indicates a read operation.

[0196] Here, we assume that a read command with a specified block number (=BLK#2), offset (=+5), and length (=3) is received from host 2. The controller 5 of flash storage device 4 reads data d1 to d3 from BLK#2 based on the block number (=BLK#2), offset (=+5), and length (=3). In this case, controller 4 reads one page of data from page 1 of BLK#2 and extracts data d1 to d3 from this read data. Next, controller 4 transfers data d1 to d3 to the host memory specified by the transfer target indicator.

[0197] Figure 24 This indicates the action of reading data stored in different physical storage locations according to the read command from host 2.

[0198] Here, we assume that a read command is received from host 2 with a specified block number (=BLK#2), offset (=+10), length (=2), or block number (=BLK#2), offset (=+16), and length (=4). The controller 5 of flash storage device 4 reads one page of data from page 2 of BLK#2 based on the block number (=BLK#2), offset (=+10), and length (=2), and extracts data d1 to data d2 from this read data. Next, the controller 5 reads one page of data (data d3 to data d4) from page 4 of BLK#2 based on the block number (=BLK#2), offset (=+16), and length (=4). Then, the controller 5 transfers the read data of length (=6) obtained by combining data d1 to data d2 with data d3 to data d4 to the host memory specified by the transfer target indicator in the read command.

[0199] Therefore, even if bad pages exist within a block, no read errors will occur, and data can be read from individual physical storage locations. Furthermore, even if data is written across two blocks, it can be retrieved by issuing a single read command.

[0200] Figure 25 This indicates the order in which the read processes are performed using host 2 and flash storage device 3.

[0201] Host 2, referring to the LUT managed by Host 2, translates the logical address contained in the read request from the user application into a block number and offset. Then, Host 2 sends a read command specifying the block number, offset, and length to flash storage device 3.

[0202] When the controller 4 of the flash storage device 3 receives a read command from the host 2, the controller 4 determines the block corresponding to the block number specified by the read command as the block to be read, and determines the page to be read based on the offset specified by the read command (step S31). In step S31, the controller 4 may first divide the offset specified by the read command by the number of granularities representing the page size (here, 4). Then, the controller 4 may determine the quotient and remainder obtained from the division as the page number and the offset position within the page of the read object, respectively.

[0203] The controller 4 reads data from the NAND flash memory 5, which is defined by the block number, offset, and length (step S32), and sends the read data to the host 2.

[0204] Figure 26 This indicates the GC control commands used by flash storage device 3.

[0205] GC control commands may include command ID, policy, source QoS domain ID, destination QoS domain ID, etc.

[0206] The command ID is the ID (command code) that indicates that the command is a GC control command. The GC control command contains the command ID used by the GC control command.

[0207] The strategy is a parameter that specifies the conditions (GC strategy) used to select GC candidate blocks (GC source blocks). The controller 4 of the flash storage device 3 supports a variety of GC strategies.

[0208] The GC strategy supported by controller 4 may include a strategy that prioritizes blocks with less effective data as GC candidate blocks (GC source blocks) (Greedy).

[0209] In addition, the GC strategy supported by controller 4 may also include the following strategy: compared with blocks in the data set with a lower update frequency (cold data) set, prioritize the selection of blocks in the data set with a lower update frequency (cold data) set as GC candidate blocks (GC source blocks).

[0210] Furthermore, GC strategies can also specify GC start conditions. GC start conditions can, for example, represent the number of remaining free blocks.

[0211] Controller 4 uses a list of active blocks to manage a group of blocks containing valid data. When performing GC, it selects one or more GC candidate blocks (GC source blocks) from the group of blocks managed by the list of active blocks based on the GC policy specified by the GC control command.

[0212] The source QoS domain ID is a parameter that specifies which QoS domain should be set as the GC source. Controller 4 belongs to the block group of the QoS domain specified by the source QoS domain ID, that is, the list of active blocks corresponding to that QoS domain, and selects one or more GC candidate blocks (GC source blocks).

[0213] The Destination QoS Domain ID is a parameter that specifies which QoS domain should be set as the GC destination. Controller 4 can select one or more idle blocks within the idle block group belonging to the QoS domain specified by the Destination QoS Domain ID as the GC destination block.

[0214] The source QoS domain ID and destination QoS domain ID can specify either the same QoS domain or different QoS domains. In other words, the source QoS domain ID and destination QoS domain ID are each parameters that specify any one of multiple QoS domains.

[0215] Controller 4 may initiate GC if the number of remaining idle blocks corresponding to the source QoS domain falls below a threshold specified by the policy. If a GC control command containing a policy specifying the enforcement of GC is received, controller 4 may initiate GC immediately upon receiving the GC control command from host 2.

[0216] Figure 27 This indicates that GC uses callback commands.

[0217] The GC uses callback commands to notify host 2 of the logical address of the valid data copied by the GC, as well as the block number and offset representing the target location of the copied valid data.

[0218] GC callback commands can include command ID, logical address, length, destination entity address, and source entity address (optional).

[0219] The command ID is the ID (command code) of the GC callback command, which contains the GC callback command ID.

[0220] A logical address represents the logical address of valid data that is copied from the GC source block to the GC destination block through GC.

[0221] The length indicates the length of the data being copied. This data length can be specified by the number of granularities.

[0222] The destination entity address indicates the location within the GC destination block where the valid data has been copied. The destination entity address is specified by the block number and the offset (offset within the block).

[0223] The source entity address (optional) indicates the location within the GC source block where valid data was previously stored. The source entity address is specified by the block number and the offset (offset within the block).

[0224] Figure 28 A program that represents garbage collection (GC) actions.

[0225] Based on the policy specified by the host 2, the controller 4 of the flash storage device 3 selects one or more GC source blocks (copy source blocks) from the block group belonging to the QoS domain specified by the source QoS domain ID, where valid and invalid data coexist (step S41). Next, the controller 4 selects one or more idle blocks from the idle block group belonging to the QoS domain specified by the destination QoS domain ID, and assigns the selected idle block as the GC destination block (copy target block) (step S42).

[0226] Controller 4 copies all valid data from the GC source block (copy source block) to the GC destination block (copy target block) (step S44). In step S44, controller 4 not only copies the valid data from the GC source block (copy source block), but also copies both the valid data and its corresponding logical address from the GC source block (copy source block) to the GC destination block (copy target block). This allows the pairing of data and logical addresses to be preserved within the GC destination block (copy target block).

[0227] Then, controller 4 uses a GC callback command to notify host 2 of the logical address of the copied valid data and the destination entity address (block number, offset (intra-block offset)) indicating the location within the GC destination block (copy target block) where the valid data was copied (step S44). Furthermore, in step S44, controller 4 may also notify host 2 not only of the logical address and destination entity address of the copied valid data, but also of the source entity address.

[0228] When host 2 receives the GC callback command, host 2 updates the LUT managed by host 2 and maps the logical addresses corresponding to the copied valid data to the destination entity addresses respectively (step S51).

[0229] Figure 29 This represents an example of a data copying action performed for garbage collection (GC).

[0230] exist Figure 29In this scenario, consider the following: The valid data (LBA=10) stored at offset +4 of the GC source block (here, block BLK#50) is copied to the position corresponding to offset +0 of the GC destination block (here, block BLK#100), and the valid data (LBA=20) stored at offset +10 of the GC source block (here, block BLK#50) is copied to the position corresponding to offset +1 of the GC destination block (here, block BLK#100). In this case, controller 4 notifies the host of {LBA10, BLK#100, offset (=+0), LBA20, BLK#100, offset (=+1)} (GC uses a callback).

[0231] Figure 30 Indicates based on Figure 29 The data replication action results in the updated LUT content of host 2.

[0232] In this LUT, the block number and offset corresponding to LBA10 are updated from BLK#50, offset (=+4) to BLK#100, offset (=+0). Similarly, the block number and offset corresponding to LBA20 are updated from BLK#50, offset (=+10) to BLK#100, offset (=+1).

[0233] After the LUT update, host 2 can send a Trim command to flash storage device 3 specifying BLK#50 and offset (=+4) to invalidate the data stored at the position corresponding to the offset (=+4) of BLK#50. Furthermore, host 2 can send a Trim command to flash storage device 3 specifying BLK#50 and offset (=+10) to invalidate the data stored at the position corresponding to the offset (=+10) of BLK#50.

[0234] Figure 31 This indicates the relationship between the response to the write command and the GC callback processing.

[0235] Sometimes, while controller 4 is copying valid data corresponding to a certain logical address, a write command specifying that logical address is received from host 2.

[0236] exist Figure 31 In the process of execution, it is assumed that... Figure 29 In the data replication operation (the data replication operation corresponding to LBA10), the case where the host 2 receives a write command for the specified LBA10.

[0237] Controller 4 writes the write data received from host 2 to the write target block (here, the position corresponding to offset +0 of BLK#3). Then, controller 4 notifies host 2 of {LBA10, BLK#3, offset (=+0)}.

[0238] Host 2 updates the LUT, changing the block number and offset corresponding to LBA10 from BLK#50, offset (+4) to BLK#3, offset (+0).

[0239] If the controller 4 then notifies the host 2 of the destination entity address of LBA10, the block number and offset (BLK#3, offset (+0)) representing the location where the latest data is stored corresponding to LBA10 may be incorrectly changed to the destination entity address corresponding to LBA10 (here, BLK#100, offset (=+0)).

[0240] In this embodiment, the controller 4 can notify the host 2 not only of LBA10 and the destination entity address (BLK#100, offset (=+0)), but also of the source entity address (BLK#50, offset (=+4)). The host 2 does not update the LUT when the source entity address (BLK#50, offset (=+4)) is inconsistent with the block number and offset currently mapped to LBA10 according to the LUT. Therefore, it is possible to prevent the block number and offset (BLK#3, offset (+0)) representing the location storing the latest data corresponding to LBA10 from being incorrectly changed to the destination entity address corresponding to LBA10 (here, BLK#100, offset (=+0)).

[0241] Figure 32 This represents another example of a GC control command.

[0242] Should Figure 32 The GC control command can specify a pairing of source device ID and source QoS domain ID instead of the source QoS domain ID. Furthermore, this... Figure 32 The GC control command can specify a pair of destination device IDs and destination QoS domain IDs instead of the destination QoS domain ID. This allows one flash storage device 3 to act as a GC source and another flash storage device 3 to act as a GC destination. When the source device ID and destination device ID are the same, GC is performed within one flash storage device 3.

[0243] Figure 33 Indicates and Figure 32 Examples of GC callback commands corresponding to GC control commands.

[0244] Figure 33The GC uses a callback command containing a pair of destination device IDs and destination entity addresses instead of the destination entity address. Additionally, Figure 33 The GC callback command can optionally include a pair of source device IDs and source entity addresses instead of the source entity address.

[0245] Now, the camera operates with flash storage device 3 (device ID 1) as the GC source and flash storage device 3 (device ID 2) as the GC destination. The host 2 can send GC control commands specifying the source device ID #1 and the destination device ID #2 to flash storage device 3 (device ID #1) and flash storage device 3 (device ID #2).

[0246] Flash storage device 3 of device ID #1 selects a GC source block from the block group belonging to the QoS domain specified by the source QoS domain ID, and sends the valid data within the GC source block and the logical address of the valid data to the flash storage device (flash storage device of device ID #2) specified by the destination device ID. The valid data within the GC source block and the logical address of the valid data are, for example, transmitted via... Figure 3 Switch 1 transfers data from flash storage device 3 of device ID #1 to flash storage device 3 of device ID #2.

[0247] Flash storage device 3 of device ID#2 selects a GC destination block from the group of idle blocks belonging to the QoS domain specified by the destination QoS domain ID, and writes (copies) the valid data and logical address received via switch 1 to the GC destination block.

[0248] Flash storage device 3 with device ID #2 uses GC callback commands to notify host 2 of the logical address of the copied valid data and the destination entity address (block number, offset) of the copied valid data.

[0249] Flash storage device 3 with device ID #1 uses GC callback commands to notify host 2 of the logical address of the copied valid data and the address (block number, offset) of the source entity that previously stored the valid data.

[0250] Figure 34 This indicates write / read / GC actions.

[0251] First, the host write operation of writing data from host 2 will be explained.

[0252] (1) Controller 4 receives LBA and writes data from host 2.

[0253] (2) Controller 4 writes both the LBA and the write data to the write target block. If no write target block is allocated, controller 4 selects an idle block from the list of idle blocks and allocates the selected idle block as the new write target block. Then, controller 4 writes both the LBA and the write data to the new write target block.

[0254] (3) Controller 4 notifies host 2 of the LBA and the entity address PBA indicating the location within the write target block where the write data is written. The entity address PBA is represented by the block number and offset. When the write target block is completely filled with data, controller 4 registers the write target block to the active block list.

[0255] Secondly, the reading action will be explained.

[0256] (4) Host 2 refers to the LUT managed by Host 2 and converts the LBA contained in the read request from the user application into the read entity address PBA (block number, offset).

[0257] (5) Based on the read entity address PBA (block number, offset) received from host 2, controller 4 determines the block with that block number as the block to be read. The block to be read is any one of the blocks managed by the active block list (active blocks), the current GC source block, or the current write target block. Then, controller 4 reads data from the block to be read based on the offset.

[0258] Secondly, the GC action will be explained.

[0259] (6) Controller 4 selects the GC source block (copy source block) and the GC destination block (copy target block), and copies the valid data stored in the GC source block and the LBA of the valid data to the GC destination block.

[0260] (7) Controller 4 notifies host 2 of both the LBA of the copied valid data and the PBA (block number, offset) indicating the location of the GC destination block where the valid data was copied.

[0261] Alternatively, controller 4 may notify host 2 of the LBA of the copied valid data, the PBA (block number, offset) indicating the location within the GC destination block where the valid data was copied, and the PBA (block number, offset) indicating the location within the GC source block where the valid data was stored.

[0262] Figure 35 This represents an example of the structure of a block management table used to manage reference counting.

[0263] Host 2 supports deduplication exclusion. Therefore, if duplicate data matching the data requested by the user application already exists in flash memory 3 (NAND flash memory 5), host 2 will not write that data to flash memory 3, but will only associate the indicator pointing to the location (block number, offset) where the data is stored with the LBA of the requested data. Therefore, each 4KB of data stored in flash memory 3 (NAND flash memory 5) may be referenced not only by one logical address, but by multiple logical addresses.

[0264] In this embodiment, the flash storage device 3 has a function to manage a reference count for each 4KB of data. Here, the reference count corresponding to a certain data represents the number of logical addresses that reference that data.

[0265] exist Figure 35 The example shown is the block management table for block BLK#1.

[0266] Block BLK#1 contains multiple entries in the block management table that correspond to multiple offset values ​​of block BLK#1.

[0267] For example, in the entry corresponding to offset +0, the reference count corresponding to the 4KB of data stored at the position corresponding to offset +0 of block BLK#1 is stored. Similarly, in the entry corresponding to offset +1, the reference count corresponding to the 4KB of data stored at the position corresponding to offset +1 of block BLK#1 is stored.

[0268] Data with a reference count of 1 or higher is considered valid data, while data with a reference count of 0 is considered invalid data.

[0269] The flash storage device 3 increments / decrements the reference count based on repeat commands / Ttim commands received from the host 2.

[0270] Figure 36 This indicates a repeating command applied to the flash memory device 3 for the purpose of managing reference counts.

[0271] The repeat command is a command that requests the flash storage device 3 to increment the reference count of the data stored at a certain physical address (block number, offset) by 1.

[0272] The repeating command may include a command ID, entity address PBA, and length.

[0273] The command ID is the ID (command code) that indicates that the command is a repeating command. Repeating commands contain the command ID of repeating commands.

[0274] The Entity Address (PBA) represents the initial storage location of the entity containing the data that should increment the reference count by 1. The Entity Address (PBA) is specified by the block number and the offset (offset within the block).

[0275] The length indicates the length of the data that should increment the reference count by 1. This data length can be specified by the number of granularities.

[0276] When the controller 4 receives a repeat command from the host 2 containing a block number and an offset within the block indicating the physical storage location where the reference count should be incremented, the controller 4 updates the block management table 32, increasing the reference count corresponding to the data at the physical storage location corresponding to the block number and offset within the block contained in the repeat command by 1.

[0277] Figure 37 This indicates the Trim command applied to flash storage device 3 for managing reference counts.

[0278] The Trim command is a command that requests the flash storage device 3 to reduce the reference count of the data stored at a certain physical address (block number, offset) by 1.

[0279] The Trim command can include the command ID, entity address PBA, and length.

[0280] The command ID is the ID (command code) that indicates that the command is a Trim command. The Trim command contains the command ID used by the Trim command.

[0281] The Entity Address (PBA) represents the initial physical storage location containing the data that should decrement the reference count by 1. The Entity Address (PBA) is specified by the block number and the offset (offset within the block).

[0282] The length represents the length of the data that should reduce the reference count by 1. This data length can be specified by the number of granularities.

[0283] When the controller 4 receives a Trim command from the host 2 containing a block number and an intra-block offset indicating the location of the entity storage location where the reference count should be reduced, the controller 4 updates the block management table 32 to reduce the reference count of the data corresponding to the entity storage location containing the block number and intra-block offset in the Trim command by 1.

[0284] Figure 38 This indicates the process of increasing / decreasing the reference count.

[0285] When the controller 4 of the flash memory device 3 receives a repeat command from the host 2, the controller 4 increments the reference count corresponding to the physical address PBA (block number, offset) specified by the repeat command, that is, the reference count corresponding to the data stored at the physical storage location in the NAND flash memory 5 specified by the block number and offset, by 1 (step S61). In this case, the controller 4 updates the block management table 32 corresponding to the block with the block number specified by the repeat command. In updating the block management table 32, the reference count stored in the entry of the block management table 32 corresponding to the offset specified by the repeat command is incremented by 1. If the length specified by the repeat command is 2 or more, not only the reference count corresponding to the offset specified by the repeat command is incremented by 1, but also the reference count corresponding to several subsequent offsets is incremented by 1.

[0286] When the controller 4 of the flash memory device 3 receives a Trim command from the host 2, the controller 4 decrements the reference count corresponding to the physical address PBA (block number, offset) specified by the Trim command, i.e., the reference count corresponding to the data stored at the physical storage location within the NAND flash memory 5 specified by the block number and offset, by 1 (step S62). In this case, the controller 4 updates the block management table 32 corresponding to the block with the block number specified by the Trim command. In updating the block management table 32, the reference count stored in the entry of the block management table 32 corresponding to the offset specified by the Trim command is decremented by 1. If the length specified by the Trim command is 2 or more, not only the reference count corresponding to the offset specified by the Trim command is decremented by 1, but also the reference count corresponding to several subsequent offsets is decremented by 1.

[0287] During GC, controller 4 refers to the block management table corresponding to the GC source block and determines whether the data in the GC source block is valid or invalid, using data units of 4KB in size. Controller 4 determines that data with a reference count of 0 is invalid data, and data with a reference count of 1 or higher is valid data. Then, controller 4 copies the valid data (data with a reference count of 1 or higher) and the logical address corresponding to the valid data from the GC source block to the GC destination block.

[0288] More specifically, when performing useless information collection on the NAND flash memory 5, the controller 4 selects a source block and a target block for the useless information collection. The controller 4 copies both the first data (valid data) with a reference count of 1 or higher stored in the source block and the logical address of the first data to the target block. Then, the controller 4 notifies the host 2 of the logical address of the first data, the block number of the target block, and the intra-block offset, expressed in granular multiples, relative to the front end of the target block where the copied first data is located.

[0289] As explained above, according to this embodiment, the flash storage device 3, rather than the host 2, determines the write target block of the data (user data) to be written from the host 2 and the location within that write target block (write target position). The flash storage device 3 writes the user data to the write target position within the write target block, and then notifies the host 2 of the block number and the offset within the block. This offset within the block is expressed as a multiple of the front end of the write target block to the write target position, having a granularity different from the page size. Therefore, the host 2 can write user data to the NAND flash memory 5 without considering block size, page write order constraints, bad pages, page size, etc., and further, can map the physical address (abstracted physical address) represented by the block number and the offset within the block to the logical address of the user data.

[0290] In this way, the flash storage device 3 can utilize its configuration of determining the target block to be written and its location within that target block, and then transmitting the block number and offset within the block back to the host 2. This allows for the merging of the application-level address translation table of the higher-level (host 2) with the LUT-level address translation table of the existing SSD. Furthermore, the flash storage device 3 can control the NAND flash memory 5 by taking into account its characteristics and constraints. Therefore, appropriate allocation of functions between the host 2 and the flash storage device 3 can be achieved, thereby improving the overall I / O performance of the system including the host 2 and the flash storage device 3.

[0291] Furthermore, according to this embodiment, instead of the host 2 managing the address translation table, the flash storage device 3 selects the source block and target block for data collection and copies the valid data stored in the source block to the target block. Then, the flash storage device 3 notifies the host 2 of the logical address of the copied valid data, the block number of the target block, and the intra-block offset indicating the location of the copied valid data within the target block. In this way, by utilizing the flash storage device 3 to perform data collection and notifying the host 2 of the logical address, block number, and intra-block offset from the flash storage device 3, the host 2 can correctly manage the mapping between each logical address and the physical address (i.e., the pairing of block number and intra-block offset) of the NAND flash memory 5 using the address translation table (LUT). Additionally, by merging the application-level garbage collection (GC) with the GC of the flash storage device 3, write amplification can be significantly reduced.

[0292] Furthermore, the flash storage device 3 can also be used as one of multiple flash storage devices 3 disposed within a memory array. The memory array can be connected to an information processing device such as a server computer via cable or network. The memory array includes a controller that controls the multiple flash storage devices 3 within the memory array. When the flash storage device 3 is used in the memory array, the controller of the memory array can function as a host 2 of the flash storage device 3.

[0293] Furthermore, in this embodiment, NAND flash memory is exemplified as a non-volatile memory. However, the functionality of this embodiment can also be applied to various other non-volatile memories such as MRAM (Magnetoresistive Random Access Memory), PRAM (Phase Change Random Access Memory), ReRAM (Resistive Random Access Memory), or FeRAM (Ferroelectric Random Access Memory).

[0294] Several embodiments of the present invention have been described, but these embodiments are provided by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other ways and can be omitted, substituted, or modified in various ways without departing from the spirit of the invention. These embodiments and their variations are included within the scope or spirit of the invention and within the scope of the invention as set forth in the claims and its equivalents.

[0295] [Explanation of Symbols]

[0296] 2 host

[0297] 3 Flash storage devices

[0298] 4 Controller

[0299] 5 NAND flash memory

[0300] 21. Write to the motion control unit

[0301] 22 Read the motion control unit

[0302] 23 GC Motion Control Unit

Claims

1. A memory system, characterized in that: It is a memory system that can be connected to a host computer, and includes: A non-volatile memory comprising multiple blocks, each of which is a unit of deletion operation; and The controller is electrically connected to the non-volatile memory; and The multiple blocks are classified into multiple domains; The controller is configured as follows: When a write command is received from the host requesting the writing of first data and specifying the identifier of the domain to which the first data should be written, the domain associated with the specified identifier is selected from the plurality of domains, a first block to be written to the first data is allocated from the set of blocks belonging to the selected domain, the first data is written to a first storage location within the first block, and the first storage location is notified to the host using the identifier of the first block and the offset address within the first block.

2. The memory system according to claim 1, characterized in that: The write command also specifies a logical address corresponding to the first data, but does not specify the identifier of the first block.

3. The memory system according to claim 1, characterized in that: Each of the multiple blocks contains multiple pages, and each of the multiple pages is a unit of data writing action; The controller specifies the offset address using a multiple of granularity that is different from the size of each of the plurality of pages.

4. The memory system according to claim 1, characterized in that: The controller is configured as follows: When a read command is received from the host specifying the identifier of the first block and the offset address within the first block, the first data is read from the first storage location within the first block.

5. The memory system according to claim 4, characterized in that: The read command does not specify a logical address corresponding to the first data.

6. The memory system according to claim 1, characterized in that: The controller is further configured as follows: The logical address corresponding to the first data is written together with the first data to the first storage location within the first block.

7. The memory system according to claim 6, characterized in that: The controller is further configured as follows: Copy the first data and the logical address from the first storage location within the first block to the second storage location of the non-volatile memory; The second storage location and the logical address are notified to the host.

8. The memory system according to claim 1, characterized in that: Each of the multiple blocks belongs to only one of the multiple domains.

9. The memory system according to claim 1, characterized in that: The non-volatile memory comprises multiple memory chip blocks, each of which belongs to only one of the multiple domains.

10. A memory system, characterized in that: It is a memory system that can be connected to a host computer, and includes: A non-volatile memory comprising multiple blocks, each of which is a unit of deletion operation; and The controller is electrically connected to the non-volatile memory; and The controller is configured as follows: When a write command is received from the host requesting the writing of first data, specifying a logical address corresponding to the first data, and not specifying an identifier for the block to which the first data should be written, the first data is written to a first storage location in the non-volatile memory, and the first storage location is notified to the host using the identifier of the block to which the first data was written and the offset address within the block to which the first data was written. When a read command is received from the host requesting the reading of the first data and specifying the identifier of the block in which the first data was written and the offset address within the block in which the first data was written, the first data is read from the first storage location in the non-volatile memory. The multiple blocks are classified into multiple domains; The write command also specifies an identifier for the field to be written to the first data; The controller is configured as follows: Select the domain from the plurality of domains that will be associated with the specified identifier; Allocate blocks from the set of blocks belonging to the selected domain to which the first data should be written.

11. A control method, characterized in that: It is a control method that uses a controller to control a non-volatile memory containing multiple blocks, each of which is a unit for deletion operations; and The multiple blocks are classified into multiple domains; When a write command is received from the host requesting the writing of first data and specifying the identifier of the domain to which the first data should be written, the domain associated with the specified identifier is selected from the plurality of domains, a first block to be written to the first data is allocated from the set of blocks belonging to the selected domain, the first data is written to a first storage location within the first block, and the first storage location is notified to the host using the identifier of the first block and the offset address within the first block.

12. The control method according to claim 11, characterized in that: The write command also specifies a logical address corresponding to the first data, but does not specify the identifier of the first block.

13. The control method according to claim 11, characterized in that: Each of the multiple blocks contains multiple pages, and each of the multiple pages is a unit of data writing action; The offset address is specified using a multiple of a granularity that is different from the size of each of the plurality of pages.

14. The control method according to claim 11, characterized in that... Also includes: When a read command is received from the host specifying the identifier of the first block and the offset address within the first block, the first data is read from the first storage location within the first block.

15. The control method according to claim 14, characterized in that: The read command does not specify a logical address corresponding to the first data.

16. The control method according to claim 11, characterized in that: The logical address corresponding to the first data is written together with the first data to the first storage location within the first block.

17. The control method according to claim 16, characterized in that... Also includes: Copy the first data and the logical address from the first storage location within the first block to the second storage location of the non-volatile memory; and The second storage location and the logical address are notified to the host.

18. The control method according to claim 11, characterized in that: Each of the multiple blocks belongs to only one of the multiple domains.

19. The control method according to claim 11, characterized in that: The non-volatile memory comprises multiple memory chip blocks, each of which belongs to only one of the multiple domains.

Images