JP2023138818A - Memory system and control method - Google Patents

Abstract

To provide a memory system capable of improving I/O performance.SOLUTION: A memory system which can be connected to a host includes: a nonvolatile memory including a plurality of blocks; and a controller electrically connected to the nonvolatile memory to control the nonvolatile memory. The controller is configured, when receiving, from the host, a write instruction that designates a location on a memory of the host where write data exists, to write the write data acquired from the memory of the host to the nonvolatile memory, and control a notification to the host regarding the write instruction, when receiving, from the host, a read instruction to read the write data on the memory of the host, so that the write data on the memory of the host may not be discarded.SELECTED DRAWING: Figure 50

Description

Embodiments of the present invention relate to techniques for controlling nonvolatile memory.

In recent years, memory systems including nonvolatile memory have become widespread.
As one such memory system, a solid state drive (SSD) based on NAND flash technology is known.
Recently, new interfaces between hosts and storage have begun to be proposed.

Yiying Zhang, outside, "De-indirection for flash-based SSDs with nameless writes." FAST. 2012, [online], [Retrieved September 13, 2017], Internet <URL: https://www.usenix. org/system/files/conference/fast12/zhang.pdf>

However, in general, controlling NAND flash memory is complex, so when creating a new interface to improve I/O performance, it is necessary to consider appropriate division of roles between the host and storage (memory system). It is necessary to do so.
An object of the present invention is to provide a memory system and control method that can improve I/O performance.

According to an embodiment, a memory system connectable to a host includes a non-volatile memory including a plurality of blocks, and a controller electrically connected to the non-volatile memory and controlling the non-volatile memory. When the controller receives a write command from the host that specifies a location in the host's memory where write data to be written exists, the controller obtains the write data from the host's memory and writes it to the nonvolatile memory; When a read command that targets the write data on the memory of the host is received from the host, notification to the host regarding the write command is controlled so that the write data on the memory of the host is not discarded.

FIG. 2 is a block diagram showing the relationship between a host and a memory system (flash storage device) according to an embodiment. FIG. 3 is a diagram for explaining the division of roles between a conventional SSD and a host, and the division of roles between a flash storage device and a host according to the same embodiment. 1 is a block diagram illustrating a configuration example of a computer system in which data transfer between multiple hosts and multiple flash storage devices is performed via network equipment. FIG. 2 is a block diagram showing a configuration example of a memory system according to the embodiment. FIG. 3 is a block diagram showing the relationship between a NAND interface provided in the memory system of the embodiment and a plurality of NAND flash memory dies. The figure which shows the example of a structure of the super block constructed|assembled by the set of several blocks. A data write operation in which the host specifies a logical address and a block number and the memory system of the same embodiment determines a physical address within a block (intra-block offset), and a data write operation in which the host specifies a block number and a physical address within a block (intra-block offset). FIG. 3 is a diagram for explaining a data read operation specifying a FIG. 3 is a diagram for explaining a write command applied to the memory system of the embodiment. FIG. 9 is a diagram for explaining a response to the write command in FIG. 8; FIG. 7 is a diagram for explaining a Trim command applied to the memory system of the embodiment. A diagram for explaining block numbers and offsets representing physical addresses. FIG. 3 is a diagram for explaining a write operation executed in response to a write command. FIG. 3 is a diagram for explaining a write operation that skips a bad page. FIG. 7 is a diagram for explaining another example of a write operation that skips a bad page. A diagram for explaining the operation of writing a logical address and data pair to a page within a block. FIG. 3 is a diagram for explaining the operation of writing data to a user data area of a page in a block and writing a logical address of this data to a redundant area of this page. FIG. 3 is a diagram for explaining the relationship between block numbers and offsets when super blocks are used. FIG. 3 is a diagram for explaining a maximum block number get command applied to the memory system of the embodiment. FIG. 7 is a diagram for explaining a response to a maximum block number get command. FIG. 3 is a diagram for explaining a block size get command applied to the memory system of the embodiment.

A diagram for explaining a response to a block size get command. FIG. 3 is a diagram for explaining a block allocation command (block allocation request) applied to the memory system of the embodiment. FIG. 3 is a diagram for explaining a response to a block allocate command. 7 is a sequence chart showing block information acquisition processing executed by a host and a memory system of the same embodiment. 5 is a sequence chart showing a sequence of write processing executed by a host and a memory system of the same embodiment. FIG. 7 is a diagram showing a data update operation of writing update data to data that has already been written. FIG. 7 is a diagram for explaining an operation of updating a block management table managed by the memory system of the embodiment. FIG. 3 is a diagram for explaining the operation of updating a lookup table (logical-physical address translation table) managed by a host. FIG. 3 is a diagram for explaining an operation of updating a block management table in response to a notification from a host indicating a block number and physical address corresponding to data to be invalidated. FIG. 3 is a diagram for explaining a read command applied to the memory system of the same embodiment. FIG. 4 is a diagram for explaining a read operation executed by the memory system of the embodiment. FIG. 3 is a diagram for explaining an operation of reading data portions stored in different physical storage locations in response to a read command from a host. 5 is a sequence chart showing a sequence of read processing executed by a host and a memory system of the same embodiment. FIG. 3 is a diagram for explaining garbage collection (GC) control commands applied to the memory system of the embodiment. FIG. 3 is a diagram for explaining a GC callback command applied to the memory system of the embodiment. 5 is a sequence chart showing the procedure of a garbage collection (GC) operation executed by the host and the memory system of the same embodiment. FIG. 3 is a diagram for explaining an example of a data copy operation executed for garbage collection (GC). FIG. 38 is a diagram for explaining the contents of a host lookup table that is updated based on the result of the data copy operation in FIG. 37; FIG. 3 is a diagram showing a system architecture of a host and a memory system of the same embodiment. FIG. 3 is a diagram showing an example of definition of a virtual storage device on the memory system of the embodiment.

FIG. 6 is a diagram illustrating an example in which QoS domains are managed for each virtual storage device on the memory system of the embodiment. 7 is a flowchart showing the operation procedure (first case) of the flash storage device 3 when receiving a block reuse command in the memory system of the same embodiment. 7 is a flowchart showing the operation procedure (second case) of the flash storage device 3 when receiving a block reuse command in the memory system of the same embodiment. FIG. 3 is a block diagram for explaining I/O command processing executed by the memory system of the embodiment. FIG. 3 is a diagram for explaining a multi-stage write operation executed by the memory system of the embodiment. FIG. 3 is a diagram for explaining the order of writing data to a certain write destination block in the memory system of the same embodiment. FIG. 3 is a diagram for explaining the operation of transferring write data from the host to the memory system of the embodiment in units of the same size as data write units of the nonvolatile memory. 7 is a flowchart showing the procedure of data write processing executed by the memory system of the embodiment. 7 is a flowchart showing another procedure of data write processing executed by the memory system of the same embodiment. 7 is a flowchart illustrating a process of transmitting a releasable notification to a host, which is executed by the memory system of the embodiment. 7 is a flowchart showing the procedure of write data discard processing executed by the host. FIG. 6 is a diagram for explaining dummy data write processing executed by the memory system of the embodiment when the next write command is not received for a threshold period after the last write command is received. 5 is a flowchart showing the procedure of dummy data write processing executed by the memory system of the embodiment. FIG. 3 is a block diagram illustrating data transfer operations performed by the memory system of the embodiment using internal buffers. 7 is a flowchart illustrating the procedure of a data write process executed by the memory system of the embodiment using an internal buffer. 5 is a flowchart showing the procedure of data read processing executed by the memory system of the embodiment. FIG. 3 is a diagram for explaining a block reuse command applied to the memory system of the embodiment. FIG. 6 is a diagram for explaining another example of a write command applied to the memory system of the embodiment. FIG. 59 is a diagram for explaining a response to the write command in FIG. 58; 7 is a sequence chart showing another example of a write operation processing sequence executed by the host and the memory system of the same embodiment.

FIG. 6 is a diagram for explaining another example of a garbage collection (GC) control command applied to the memory system of the embodiment. 7 is a sequence chart illustrating another example of a garbage collection (GC) operation procedure executed by the memory system of the embodiment. 5 is a flowchart showing a procedure for allocating a write destination block in the memory system of the embodiment. 7 is a flowchart showing a procedure for allocating a GC destination block in the memory system of the embodiment.

Hereinafter, embodiments will be described with reference to the drawings.
First, with reference to FIG. 1, the configuration of a computer system including a memory system according to an embodiment will be described.
The memory system is a semiconductor storage device configured to write data to and read data from non-volatile memory. This memory system is realized as a flash storage device 3 based on NAND flash technology.

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

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

Examples of services that can be provided by the host (server) 2 include (1) platform as a service (PaaS) that provides a system operating platform to each client (each end user terminal 61), (2) virtual server. There is infrastructure as a service (IaaS), etc., which provides infrastructure such as this to each client (each end user terminal 61).

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

The host (server) 2 includes a storage management function that manages a plurality of flash storage devices 3 that constitute a flash array, and a front end function that provides various services including storage access to each end user terminal 61. .
In conventional SSDs, the block/page hierarchy of NAND flash memory is hidden by a flash translation layer (FTL) within the SSD. In other words, the FTL of a conventional SSD includes (1) the ability to manage the mapping between each logical address and each physical address of the NAND flash memory using a lookup table that functions as a logical-physical address translation table; It has (2) a function to hide read/write operations in page units and erase operations in block units, and (3) a function to execute garbage collection (GC) of NAND flash memory. The mapping between each logical address and the physical address of the NAND flash memory is invisible to the host. The block/page structure of the NAND flash memory is also invisible to the host.

On the other hand, a type of address translation (application level address translation) may also be executed in the host. This address translation uses an application level address translation table to manage the mapping between each application level logical address and each logical address for the SSD. Also, in the host, a type of GC (application level GC) is executed to change the data arrangement on the logical address space for the SSD in order to eliminate fragments occurring on the logical address space for the SSD.

However, in a redundant configuration where the host and SSD each have an address translation table (the SSD has a lookup table that functions as a logical-physical address translation table, and the host has an application-level address translation table), these address translations Huge memory resources are consumed to maintain the table. Furthermore, double address translation, including address translation on the host side and address translation on the SSD side, is also a factor that reduces I/O performance.

Furthermore, the application level GC on the host side becomes a factor that increases the amount of data written to the SSD to several times (for example, twice) the actual amount of user data. Such an increase in the amount of data written, together with write amplification of the SSD, reduces the storage performance of the entire system and also shortens the life of the SSD.

In order to solve these problems, one possible measure is to move all of the FTL functions of the conventional SSD to the host.
However, in order to implement this measure, it is necessary for the host to directly handle blocks and pages of the NAND flash memory. In a NAND flash memory, there are page write order restrictions, so it is difficult for a host to directly handle pages. Furthermore, in a NAND flash memory, a block may include a defective page (bad page). Handling bad pages is even more difficult for hosts.

Therefore, in this embodiment, the role of FTL is shared between the host 2 and the flash storage device 3. Generally speaking, the host 2 manages a lookup table that functions as a logical-physical address translation table, but the host 2 only specifies the block number of the block into which data is to be written and the logical address corresponding to this data, and The location within this block (destination location) to which is to be written is determined by the flash storage device 3. The host 2 is notified from the flash storage device 3 of the physical address within the block indicating the determined position within the block (write destination position).

In this way, the host 2 only handles blocks, and positions within blocks (eg, pages, positions within pages) are handled by the flash storage device 3.
When the host 2 needs to write data to the flash storage device 3, it selects a block number (or requests the flash storage device 3 to allocate a free block) and writes the logical address and block number of the selected block (or A write request (write command) specifying the block number of the allocated block notified by the flash storage device 3 is sent to the flash storage device 3. The flash storage device 3 writes data from the host 2 to the block having the specified block number. In this case, the flash storage device 3 determines a position within this block (write destination position) and writes the data from the host 2 to the position within this block (write destination position). Then, the flash storage device 3 notifies the host 2 of the physical address within the block indicating the position within the block (write destination position) as a response (return value) to the write request. In the following, the FTL function transferred to host 2 will be referred to as global FTL.

The global FTL of host 2 includes a function to execute storage services, a software control function, a function to realize high availability, and deduplication (Deduplication) to prevent multiple duplicate data parts with the same content from being stored in the storage. -duplication) function, garbage collection (GC) block selection function, QoS control function, etc. The QoS control function includes a function of determining access units for each QoS domain (or each block). The access unit indicates the minimum data size (grain) that the host 2 can write/read. The flash storage device 3 supports single or multiple access units (grain), and the host 2 can perform QoS for each domain (or for each block) if the flash storage device 3 supports multiple access units (grain). ), it is possible to instruct the flash storage device 3 which access unit to use.

Furthermore, the QoS control function includes a function to prevent performance interference between QoS domains as much as possible. This function is basically a function to maintain stable latency.
On the other hand, the flash storage device 3 is capable of performing low level abstraction (LLA). LLA is a function for abstracting NAND flash memory. LLA includes a function to hide bad pages and a function to protect page write order constraints. LLA also includes GC execution functions. The GC execution function copies valid data in a copy source block (GC source block) specified by the host 2 to a copy destination block (GC destination block) specified by the host 2. The GC execution function of the flash storage device 3 determines the position (copy destination position) in the GC destination block where valid data is to be written, and writes the valid data in the GC source block to the copy destination position in the GC destination block. make a copy.

FIG. 2 shows the division of roles between the conventional SSD and the host and the division of roles between the flash storage device 3 and the host 2 of this embodiment.
The left side of FIG. 2 represents the hierarchical structure of the entire computer system including a conventional SSD and a host that executes a virtual disk service.

A virtual machine service 101 for providing multiple virtual machines to multiple end users is executed on the host (server). Each virtual machine on the virtual machine service 101 executes an operating system and user application 102 used by a corresponding end user.

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

Sending commands from the host (server) to the conventional SSD and returning command completion responses from the conventional SSD to the host (server) are performed using the I/O queue 200 that exists in each of the host (server) and the conventional SSD. is executed via.
The conventional SSD includes a write buffer (WB) 301, a look-up table (LUT) 302, a garbage collection function 303, and a NAND flash memory (NAND flash array) 304. A conventional SSD manages only one lookup table (LUT) 302, and the resources of a NAND flash memory (NAND flash array) 304 are shared by multiple virtual disk services 103.

In this configuration, write amplification increases due to redundant GC including the application level GC 104 under the virtual disk service 103 and the garbage collection function 303 (LUT level GC) in the conventional SSD. In addition, in conventional SSDs, the frequency of GC increases due to an increase in the amount of data written by a certain end user or a certain virtual disk service 103, which increases the I/O performance for other end users or other virtual disk services 103. A noisy neighbor problem may occur where the

Additionally, the presence of duplicate resources, including application level address translation tables within each virtual disk service and LUTs 302 within a conventional SSD, consumes a large amount of memory resources.
The right side of FIG. 2 represents the hierarchical structure of the entire computer system including the flash storage device 3 and host 2 of this embodiment.

In the host (server) 2, a virtual machine service 401 is executed to provide a plurality of virtual machines to a plurality of end users. Each virtual machine on virtual machine service 401 executes an operating system and user application 402 used by a corresponding end user.

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

In LBA-based block I/O services, a LUT 411 may be used that manages the mapping between each logical address (LBA) and each physical address of the flash storage device 3.
In the key-value store service, each logical address (i.e., key-like tag) and the physical A LUT 411 may be used to manage the mapping between each physical address indicating a storage location. In this LUT 411, a correspondence relationship between a tag, a physical address where data identified by this tag is stored, and a data length of this data may be managed.

Each end user can select the addressing method to use (LBA, key-value store keys, etc.).
Each of these LUTs 411 does not convert each logical address from the user application 402 into each logical address for the flash storage device 3, but converts each logical address from the user application 402 into each physical address of the flash storage device 3. . In other words, each of these LUTs 411 is a table in which a table for converting a logical address for the flash storage device 3 into a physical address and an application level address conversion table are integrated (merged).

Each I/O service 403 also includes a GC block selection function. The GC block selection function can manage the effective data amount of each block using a corresponding LUT, and thereby can select a GC source block.
In the host (server) 2, an I/O service 403 may exist for each of the above-mentioned QoS domains. An I/O service 403 that belongs to a certain QoS domain has a link between each logical address used by the user application 402 in the corresponding QoS domain and each block number of a group of blocks belonging to a resource group allocated to the corresponding QoS domain. may manage the mapping of

Sending commands from the host (server) 2 to the flash storage device 3 and returning command completion responses from the flash storage device 3 to the host (server) 2 are sent to each of the host (server) 2 and flash storage device 3. This is done via the existing I/O queue 500. These I/O queues 500 may also be classified into multiple queue groups corresponding to multiple QoS domains.

The flash storage device 3 includes multiple write buffers (WB) 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. include.

In the configuration shown on the right side of FIG. 2, the upper layer (host 2) can recognize block boundaries, so user data can be written into each block while taking the block boundaries/block size into consideration. In other words, the host 2 can recognize individual blocks of the NAND flash memory (NAND flash array) 603, and thereby, for example, write data to an entire block at once, or write data to the entire block. It becomes possible to perform control such as invalidation by deletion or update. As a result, it becomes possible to make it difficult for a situation in which valid data and invalid data are mixed in one block to occur. Therefore, the frequency with which it is necessary to perform GC can be reduced. By reducing the frequency of GC, write amplification is reduced, the performance of the flash storage device 3 can be improved, and the life of the flash storage device 3 can be maximized. In this way, a configuration in which the upper layer (host 2) can recognize the block number is useful.

On the other hand, the location within the block where data is to be written is determined by the flash storage device 3, not by the upper layer (host 2). Therefore, defective pages (bad pages) can be hidden, and page write order constraints can be observed.

FIG. 3 shows a modification of the system configuration of FIG. 1.
In FIG. 3, data transfer between multiple hosts 2A and multiple flash storage devices 3 is performed via a network device (here, network switch 1).
That is, in the computer system shown in FIG. 3, the storage management function of the host (server) 2 shown in FIG. It has been moved to 2A.

The manager 2B manages a plurality of flash storage devices 3 and distributes the storage resources of these flash storage devices 3 to each host (end user service host) 2A in response to a request from each host (end user service host) 2A. Assign to

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) which is the above-mentioned integrated (merged) logical-physical address translation table. Each host (end user service host) 2A uses its own LUT to manage only the mapping between each logical address used by the corresponding end user and each physical address of the resources assigned to it. do. Therefore, this configuration allows the system to be easily scaled out.

The global FTL of each host 2A has a look-up table (LUT) management function, a high availability function, a QoS control function, a GC block selection function, and the like.
The manager 2B is a dedicated device (computer) for managing multiple flash storage devices 3. The manager 2B has a global resource reservation function that reserves storage resources for the capacity requested by each host 2A. Furthermore, the manager 2B has a wear monitoring function for monitoring the degree of wear of each flash storage device 3, a NAND resource allocation function that allocates reserved storage resources (NAND resources) to each host 2A, a QoS control function, and a global clock management function. It has functions, etc.

The low level abstraction (LLA) of each flash storage device 3 has a function of hiding a bad page (bad page), a function of observing page write order constraints, a function of managing a write buffer, a function of executing GC, etc.
According to the system configuration of FIG. 3, management of each flash storage device 3 is executed by the manager 2B, so each host 2A sends an I/O request to one or more flash storage devices 3 assigned to itself. It is only necessary to perform the operations of ``receiving the response'' and ``receiving the response'' from the flash storage device 3. That is, data transfer between the multiple hosts 2A and the multiple flash storage devices 3 is performed only via the network switch 1, and the manager 2B is not involved in this data transfer. Further, as described above, the contents of the LUTs managed by each host 2A are independent from each other. Therefore, since the number of hosts 2A can be easily increased, a scale-out system configuration can be realized.

FIG. 4 shows a configuration example of the flash storage device 3.
The flash storage device 3 includes a controller 4 and a nonvolatile memory (NAND flash memory) 5. Flash storage device 3 may also include random access memory, eg DRAM 6.

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

The memory cell array of the NAND flash memory 5 includes a plurality of blocks BLK0 to BLKm-1. Each of blocks BLK0 to BLKm-1 is organized by a large number of pages (pages P0 to Pn-1 here). Blocks BLK0 to BLKm-1 function as erase units. A block may also be referred to as an "erasure block,""physicalblock," or "physical erase block." Each of pages P0 to Pn-1 includes a plurality of memory cells connected to the same word line. Pages P0 to Pn-1 are units of data write operations and data read operations.
The controller 4 is electrically connected to a NAND flash memory 5, which is a nonvolatile memory, via a NAND interface 13 such as Toggle or an open NAND flash interface (ONFI). The controller 4 is a memory controller (control circuit) configured to control the NAND flash memory 5.

As shown in FIG. 5, the NAND flash memory 5 includes a plurality of NAND flash memory dies. Each NAND flash memory die is a nonvolatile memory die that includes a memory cell array including a plurality of blocks BLK and a peripheral circuit that controls the memory cell array. Each NAND flash memory die can operate independently. Therefore, the NAND flash memory die functions as a parallel operating unit. A NAND flash memory die is also referred to as a "NAND flash memory chip" or a "nonvolatile memory chip." In FIG. 5, 16 channels Ch1, Ch2, ... Ch16 are connected to the NAND interface 13, and each of these channels Ch1, Ch2, ... Ch16 has the same number of NAND dies (for example, two dies per channel). A case is illustrated in which each flash memory die is connected. Each channel includes a communication line (memory bus) for communicating with a corresponding NAND flash memory die.

The controller 4 controls the NAND flash memory dies #1 to #32 via channels Ch1, Ch2, . . . Ch16. The controller 4 can drive channels Ch1, Ch2, . . . Ch16 simultaneously.
The 16 NAND flash memory dies #1 to #16 connected to channels Ch1 to Ch16 may be organized as a first bank, and the remaining 16 NAND flash memory dies #1 to #16 connected to channels Ch1 to Ch16 Memory dies #17-#32 may be organized as a second bank. A bank functions as a unit for operating multiple memory modules in parallel by bank interleaving. In the configuration example of FIG. 5, a maximum of 32 NAND flash memory dies can be operated in parallel with 16 channels and bank interleaving using two banks.

In the present embodiment, the controller 4 may manage a plurality of blocks (hereinafter referred to as superblocks) each made up of a plurality of blocks BLK, and may execute the erase operation in units of superblocks. .
The super block may include, but is not limited to, a total of 32 blocks BLK selected one by one from NAND flash memory dies #1 to #32. Note that each of the NAND flash memory dies #1 to #32 may have a multiplane configuration. For example, if each of the NAND flash memory dies #1 to #32 has a multiplane configuration including two planes, one superblock has 64 planes corresponding to the NAND flash memory dies #1 to #32. A total of 64 blocks BLK may be included, one selected from each plane. In FIG. 6, one super block SB is a total of 32 blocks BLK selected one by one from NAND flash memory dies #1 to #32 (blocks BLK surrounded by thick frames in FIG. 5). An example is shown in which the

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

This host interface 11 is a host interface circuit configured to communicate with the host 2. This host interface 11 may be, for example, a PCIe controller (NVMe controller). The host interface 11 receives various requests (commands) from the host 2. These requests (commands) include write requests (write commands), read requests (read commands), and various other requests (commands).

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

The CPU 12 can function as a write operation control section 21, a read operation control section 22, and a GC operation control section 23. In these write operation control section 21, read operation control section 22, and GC operation control section 23, an application program interface (API) for realizing the system configuration shown on the right side of FIG. 2 is implemented.

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

Then, the write operation control unit 21 notifies the host 2 of the physical address within the block indicating the above-mentioned write destination position of this write destination block. This intra-block physical address is represented by an intra-block offset indicating the write destination position within this write destination block.

In this case, the intra-block offset indicates the offset from the beginning of the writing destination block to the writing destination position, that is, the offset of the writing destination position from the beginning of the writing destination block. The size of the offset from the beginning of the write destination block to the write destination position is expressed as a multiple of a grain having a size different from the page size. Grain is the above-mentioned access unit. The maximum value of the grain size is limited to the block size. In other words, the intra-block offset indicates the offset from the beginning of the write destination block to the write destination position as a multiple of a granularity having a size different from the page size.

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

Alternatively, the grain size may have a size larger than the page size. For example, the grain size may be several times the page size. If the page size is 16K bytes, the granularity may be 32K bytes in size.

In this manner, the write operation control unit 21 determines by itself the write destination position within the block having the block number from the host 2, and writes the write data from the host 2 to this write destination position within this block. Then, the write operation control unit 21 notifies the host 2 of the intra-block physical address (intra-block offset) indicating the write destination position as a response (return value) corresponding to the write request. Alternatively, instead of notifying the host 2 of only the intra-block physical address (intra-block offset), the write operation control unit 21 notifies the host 2 of a set of a logical address, block number, and intra-block physical address (intra-block offset). may be notified.

Therefore, the flash storage device 3 can hide page write order constraints, bad pages, page sizes, etc. while allowing the host 2 to handle block numbers.
As a result, although the host 2 can recognize block boundaries, it can manage which user data exists in which block number without being aware of page write order constraints, bad pages, and page sizes.

When the read operation control unit 22 receives a read request (read command) specifying a physical address (that is, a block number and an intra-block offset) from the host 2, the read operation control unit 22 determines the read target based on these block numbers and intra-block offsets. Read data from the physical storage location to be read within the block. The block to be read is identified by the block number. The physical storage location to be read within this block is specified by the intra-block offset. By using this intra-block offset, the host 2 does not need to handle different page sizes for each generation of NAND flash memory.

In order to obtain the physical storage location to be read, the read operation control unit 22 first converts this intra-block offset into the number of grains representing the page size (if the page size is 16K bytes and the grain is 4K bytes) In this case, the number of granularity representing the page size may be divided by 4), and the quotient and remainder obtained by this division may be determined as the page number of the read target and the offset within the page of the read target, respectively.

The GC operation control unit 23 receives a GC control command from the host 2 that specifies a copy source block number (GC source block number) and a copy destination block number (GC destination block number) for garbage collection of the NAND flash memory 5. If received, a block having the specified copy source block number and a block having the specified copy destination block number are selected from multiple blocks of the NAND flash memory 5 as a copy source block (GC source block) and a copy destination block. (GC destination block). The GC operation control unit 23 determines a copy destination position in the GC destination block to which valid data stored in the selected GC source block is to be written, and copies the valid data to the copy destination position in the GC destination block. do.

Then, the GC operation control unit 23 notifies the host 2 of the logical address of the valid data, the copy destination block number, and the intra-block physical address (intra-block offset) indicating the copy destination position within the GC destination block. .
Valid data/invalid data management may be performed using the block management table 32. This block management table 32 may exist for each block, for example. In the block management table 32 corresponding to a certain block, bitmap flags indicating validity/invalidity of each data in this block are stored. Here, valid data means data that is linked as the latest data from a logical address and that may be read from the host 2 later. Invalid data means data that can no longer be read by the host 2. For example, data that is associated with a certain logical address is valid data, and data that is not associated with any logical address is invalid data.

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

In this embodiment, as described above, the write operation control unit 21 can write both the data (write data) from the host 2 and the logical address from the host 2 to the write destination block. Therefore, since the GC operation control unit 23 can easily obtain the logical address of each data in the copy source block (GC source block) from this copy source block (GC source block), the copied valid data The logical address of the host 2 can be easily notified to the host 2.

The NAND interface 13 is a memory control circuit configured to control the NAND flash memory 5 under the control of the CPU 12. The DRAM interface 14 is a DRAM control circuit configured to control the DRAM 6 under the control of the CPU 12. A part of the storage area of the DRAM 6 is used for storing an internal buffer (shared cache) 31. Further, another part of the storage area of the DRAM 6 is used for storing the block management table 32. Note that the internal buffer (shared cache) 31 and block management table 32 may be stored in an SRAM (not shown) in the controller 4.

FIG. 7 shows a data write operation in which the host 2 specifies a logical address and a block number, and the flash storage device 3 determines an intra-block physical address (intra-block offset), and a data write operation in which the host 2 specifies a block number and an intra-block physical address ( The data read operation specifies the block offset) and the data read operation.

The data write operation is executed in the following steps.
(1) When the write processing unit 412 of the host 2 needs to write data (write data) to the flash storage device 3, the write processing unit 412 requests the flash storage device 3 to allocate a free block. good. The controller 4 of the flash storage device 3 includes a block allocation unit 701 that manages free block groups of the NAND flash memory 5. When the block allocation unit 701 receives this request (block allocation request) from the write processing unit 412, the block allocation unit 701 allocates one free block of the free block group to the host 2, and the block number of the allocated block ( BLK#) to the host 2.

Alternatively, in a configuration in which the write processing unit 412 manages the free block group, the write processing unit 412 may select the write destination block by itself.
(2) The write processing unit 412 transmits a write request to the flash storage device 3 that specifies the logical address (for example, LBA) corresponding to the write data and the block number (BLK#) of the write destination block.

(3) The controller 4 of the flash storage device 3 includes a page allocation unit 702 that allocates pages for data writing. When the page allocation unit 702 receives a write request, the page allocation unit 702 uses an intra-block physical address (intra-block PBA) indicating the write destination position in the block having the block number specified by the write request (write destination block). Determine. The intra-block physical address (intra-block PBA) can be represented by the above-mentioned intra-block offset (also simply referred to as offset). The controller 4 writes the write data from the host 2 to the write destination position in the write destination block based on the block number specified by the write request and the intra-block physical address (intra-block PBA).

(4) The controller 4 notifies the host 2 of the intra-block physical address (intra-block PBA) indicating the write destination position as a response to the write request. Alternatively, the controller 4 sends a set of a logical address (LBA) corresponding to the write data, a block number (BLK#) of the write destination block, and an intra-block PBA (offset) indicating the write destination position in response to a write request. The host 2 may be notified as follows. In other words, the controller notifies the host 2 of either the intra-block physical address or the combination of the logical address, block number, and intra-block physical address. In the host 2, the LUT 411 is updated so that the physical address (block number, intra-block physical address (intra-block offset)) indicating the physical storage location where the write data is written is mapped to the logical address of this write data. be done.

Data read operation is executed in the following steps.
(1)' When the host 2 needs to read data from the flash storage device 3, the host 2 refers to the LUT 411 and reads the physical address (block number, within the block) that corresponds to the logical address of the data to be read. The physical address (intra-block offset) is obtained from the LUT 411.

(2)' The host 2 sends a read request to the flash storage device 3 specifying the obtained block number and intra-block physical address (intra-block offset). When the controller 4 of the flash storage device 3 receives this read request from the host 2, the controller 4 identifies the block to be read and the physical storage location to be read based on the block number and the physical address within the block, and Read data from the physical storage location to be read within the block to be read.

FIG. 8 shows a write command applied to the flash storage device 3.
The write command is a command that requests the flash storage device 3 to write data. This write command may include a command ID, block number BLK#, logical address, length, etc.

The command ID is an ID (command code) indicating that this command is a write command, and the write command includes a command ID for a write command.
The block number BLK# is an identifier (block address) that can uniquely identify the block into which data is to be written.

The logical address is an identifier for identifying write data to be written. This logical address may be an LBA, a key of a key-value store, or a hash value of a key, as described above. If the logical address is an LBA, the logical address (starting LBA) included in this write command indicates the logical position (first logical position) where write data is to be written.

The length indicates the length of write data to be written. This length (data length) may be specified by the number of grains, the number of LBAs, or the size may be specified by bytes.
When receiving a write command from the host 2, the controller 4 determines the write destination position within the block having the block number specified by the write command. This write destination position is determined in consideration of page write order constraints, bad pages, and the like. The controller 4 then writes the data from the host 2 to this write destination location within this block having the block number specified by the write command.

FIG. 9 shows a response to the write command in FIG. 8.
This response includes the physical address within the block and the length. The intra-block physical address indicates the position (physical storage position) within the block where data is written. As described above, the intra-block physical address can be specified by the intra-block offset. Length indicates the length of written data. This length (data length) may be specified by the number of grains, the number of LBAs, or the size may be specified by bytes.

Alternatively, this response may further include not only the physical address and length within the block, but also the logical address and block number. The logical address is the logical address included in the write command in FIG. The block number is the logical address included in the write command in FIG.

FIG. 10 shows the Trim command applied to the flash storage device 3.
This Trim command is a command that includes a block number indicating a physical storage location where data to be invalidated is stored and a physical address within the block (offset within the block). In other words, this Trim command can specify a physical address instead of a logical address such as LBA. This Trim command includes a command ID, physical address, and length.

The command ID is an ID (command code) indicating that this command is a Trim command, and the Trim command includes a command ID for the Trim command.
The physical address indicates the first physical storage location where the data to be invalidated is stored. In this embodiment, this physical address is specified by a combination of a block number and an offset (intra-block offset).

Length indicates the length of data to be invalidated. This length (data length) may be specified by the number of grains or bytes.
The controller 4 uses the block management table 32 to manage flags (bitmap flags) indicating validity/invalidity of data included in each of a plurality of blocks. When the controller 4 receives a Trim command from the host 2 that includes a block number and an offset (intra-block offset) indicating the physical storage location where data to be invalidated is stored, the controller 4 updates the block management table 32 and performs the Trim command. The flag (bitmap flag) corresponding to the data at the physical storage location corresponding to the block number and intra-block offset included in the command is changed to a value indicating invalidity.

FIG. 11 shows intra-block offsets that define intra-block physical addresses.
The block number specifies one block BLK. Each block BLK includes a plurality of pages (here, page 0 to page n), as shown in FIG.
In the case where the page size (user data storage area of each page) is 16 KB and the grain size is 4 KB, this block BLK is logically divided into 4×(n+1) areas. Ru.

Offset +0 indicates the first 4KB area of page 0, offset +1 indicates the second 4KB area of page 0, offset +2 indicates the third 4KB area of page 0, and offset +3 indicates the fourth 4KB area of page 0. Indicates a 4KB area.
Offset +4 indicates the first 4KB region of page 1, offset +5 indicates the second 4KB region of page 1, offset +6 indicates the third 4KB region of page 1, and offset +7 indicates the fourth 4KB region of page 1. Indicates a 4KB area.

FIG. 12 shows a write operation performed in response to a write command.
Now, assume that block BLK#1 is assigned as a write destination block. The controller 4 writes data to the block BLK#1 in page units in the order of page 0, page 1, page 2, . . . page n.

In FIG. 12, the block number (=BLK#1), logical address (LBAx), and length (=4) are specified with 16K bytes of data already written to page 0 of block BLK#1. A case is assumed in which a write command to do this is received from the host 2. Controller 4 determines page 1 of block BLK#1 as the write destination position, and writes 16 Kbytes of write data received from host 2 to page 1 of block BLK#1. The controller 4 then returns the offset (intra-block offset) and length to the host 2 as a response to this write command. In this case, the offset (intra-block offset) is +5 and the length is 4. Alternatively, the controller 4 may return the logical address, block number, offset (internal block offset), and length to the host 2 as a response to this write command. In this case, the logical address is LBAx, the block number is BLK#1, the offset (intra-block offset) is +5, and the length is 4.

FIG. 13 shows a write operation that skips bad pages.
In FIG. 13, the block number (=BLK#1), logical address (LBAx+1), and length (=4) are specified in a state where data has already been written to pages 0 and 1 of block BLK#1. A case is assumed in which a write command is received from the host 2. If page 2 of block BLK#1 is a bad page, controller 4 determines page 3 of block BLK#1 as the write destination position, and transfers the 16K bytes of write data received from host 2 to block BLK Write on page 3 of #1. The controller 4 then returns the offset (intra-block offset) and length to the host 2 as a response to this write command. In this case, the offset (intra-block offset) is +12 and the length is 4. Alternatively, the controller 4 may return the logical address, block number, offset (internal block offset), and length to the host 2 as a response to this write command. In this case, the logical address is LBAx+1, the block number is BLK#1, the offset (intra-block offset) is +12, and the length is 4.

FIG. 14 shows another example of a write operation that skips bad pages.
In FIG. 14, it is assumed that data is written across two pages sandwiching a defective page. Now, assume that data has already been written to pages 0 and 1 of block BLK#2, and 8 Kbytes of unwritten write data remains in the internal buffer (shared cache) 31. In this state, if a write command specifying the block number (=BLK#2), logical address (LBAy), and length (=6) is received, the controller 4 writes the unwritten 8K byte write data, Using the first 8 Kbyte write data of the 24 Kbyte write data newly received from the host 2, 16 Kbyte write data corresponding to the page size is prepared. Then, the controller 4 writes the prepared 16 Kbyte write data to page 2 of block BLK#2.

If the next page 3 of block BLK#2 is a bad page, the controller 4 determines page 4 of the block BLK#2 as the next write destination location, and stores the 24K byte write data received from the host 2. The remaining 16K bytes of write data are written to page 4 of block BLK#2.

Then, the controller 4 returns two offsets (intra-block offsets) and two lengths to the host 2 as a response to this write command. In this case, the response may include offset (=+10), length (=2), offset (=+16), length (=4). Alternatively, the controller 4 sends LBAy, block number (=BLK#2), offset (=+10), length (=2), block number (=BLK#2), offset (=+16) as a response to this write command. ) and the length (=4) may be returned to the host 2.

15 and 16 illustrate the operation of writing logical address and data pairs to pages within a block.
In each block, each page may include a user data area for storing user data and a redundant area for storing management data. The page size is 16KB+alpha.

The controller 4 writes both the 4KB user data and the logical address (for example, LBA) corresponding to the 4KB user data to the write destination block BLK. In this case, four data sets each including an LBA and 4KB user data may be written to the same page, as shown in FIG. 15. Intra-block offsets may indicate set boundaries.

Alternatively, as shown in Figure 16, four 4KB user data are written to the user data area within a page, and four LBAs corresponding to these four 4KB user data are written to a redundant area within this page. It's okay.
FIG. 17 shows the relationship between block numbers and offsets (intra-block offsets) in the case where superblocks are used. In the following, intra-block offsets are also simply referred to as offsets.

Here, in order to simplify the illustration, it is assumed that one super block SB#1 is composed of four blocks BLK#11, BLK#21, BLK#31, and BLK#41. The controller 4 controls 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, and page of block BLK#21. 1, page 1 of block BLK#31, page 1 of block BLK#41, and so on.

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

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

Similarly, offset +12 indicates the first 4KB area of page 0 of block BLK#41, offset +13 indicates the second 4KB area of page 0 of block BLK#41, and offset +14 indicates page 0 of block BLK#41. The offset +15 indicates the fourth 4KB area of page 0 of block BLK#41.

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

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

Similarly, offset +28 indicates the first 4KB area of page 1 of block BLK#41, offset +29 indicates the second 4KB area of page 1 of block BLK#41, and offset +30 indicates page 1 of block BLK#41. The offset +31 indicates the fourth 4KB area of page 1 of block BLK#41.

FIG. 18 shows a maximum block number get command applied to the flash storage device 3.
The maximum block number get command is a command for acquiring the maximum block number from the flash storage device 3. The host 2 can recognize the maximum block number indicating the number of blocks included in the flash storage device 3 by sending a maximum block number get command to the flash storage device 3. The maximum block number get command includes a command ID for the maximum block number get command, but does not include any parameters.

FIG. 19 shows a response to the maximum block number get command.
When receiving the maximum block number get command from the host 2, the flash storage device 3 returns the response shown in FIG. 19 to the host 2. This response includes a parameter indicating the maximum block number (ie, the total number of available blocks contained in the flash storage device 3).

FIG. 20 shows a block size get command applied to the flash storage device 3.
The block size get command is a command for obtaining the block size from the flash storage device 3. The host 2 can recognize the block size of the NAND flash memory 5 included in the flash storage device 3 by sending a block size get command to the flash storage device 3 .

Note that in another embodiment, the block size get command may include a parameter specifying a block number. When receiving a block size get command specifying a certain block number from the host 2, the flash storage device 3 returns the block size of the block having this block number to the host 2. Thereby, even if the block sizes of the blocks included in the NAND flash memory 5 are non-uniform, the host 2 can recognize the block size of each block.

FIG. 21 shows a response to the block size get command.
When receiving the block size get command from the host 2, the flash storage device 3 returns the block size (the common block size of the blocks included in the NAND flash memory 5) to the host 2. In this case, if the block number was specified by the block size get command, the flash storage device 3 returns the block size of the block having this block number to the host 2, as described above.

FIG. 22 shows a block allocate command applied to flash storage device 3.
The block allocation command is a command (block allocation request) that requests the flash storage device 3 to allocate a block (free block). The host 2 requests the flash storage device 3 to allocate a free block by sending a block allocate command to the flash storage device 3, thereby obtaining a block number (the block number of the allocated free block). I can do it.

In the case where the flash storage device 3 manages the free blocks by a free block list and the host 2 does not manage the free blocks, the host 2 requests the flash storage device 3 to allocate free blocks, thereby Get the number. On the other hand, in the case where the host 2 manages free block groups, the host 2 can select one of the free block groups by itself, so there is no need to send a block allocate command to the flash storage device 3.

FIG. 23 shows the response to the block allocate command.
When receiving the block allocate command from the host 2, the flash storage device 3 selects a free block to be allocated to the host 2 from the free block list, and returns a response including the block number of the selected free block to the host 2.

FIG. 24 shows block information acquisition processing executed by the host 2 and flash storage device 3.
When the host 2 starts using the flash storage device 3, the host 2 first sends a maximum block number get command to the flash storage device 3. The controller of the flash storage device 3 returns the maximum block number to the host 2. The maximum block number indicates the total number of available blocks. Note that in the case where the above-mentioned superblocks are used, the maximum block number may indicate the total number of available superblocks.

Next, the host 2 sends a block size get command to the flash storage device 3 to obtain the block size. In this case, the host 2 sends a block size get command specifying block number 1, a block size get command specifying block number 2, a block size get command specifying block number 3, etc. to the flash storage device 3. The block size of each block may be obtained individually.

Through this block information acquisition process, the host 2 can recognize the number of available blocks and the block size of each block.
FIG. 25 shows the sequence of write processing executed by the host 2 and flash storage device 3.
The host 2 first selects a block (free block) to be used for writing by itself or instructs the flash storage device 3 to allocate a free block by sending a block allocate command to the flash storage device 3. request. Then, the host 2 sends a write command that includes the block number BLK# of the block it selected (or the block number BLK# of a free block allocated by the flash storage device 3), the logical address (LBA), and the length. The data is transmitted to the flash storage device 3 (step S20).

When the controller 4 of the flash storage device 3 receives this write command, the controller 4 determines the write destination position in the block with this block number BLK# (write destination block BLK#) into which the write data from the host 2 is to be written. is determined, and write data is written to the write destination position of this write destination block BLK# (step S11). In step S11, the controller 4 may write both the logical address (LBA here) and the write data to the write destination block.

The controller 4 updates the block management table 32 corresponding to the write destination block BLK#, and updates the bitmap flag corresponding to the written data (that is, the bit corresponding to the offset (intra-block offset) at which this data was written). map flag) from 0 to 1 (step S12).

For example, as shown in FIG. 26, assume that 16 Kbyte update data whose starting LBA is LBAx is written to physical storage locations corresponding to offsets +4 to +7 of block BLK#1. In this case, as shown in FIG. 27, in the block management table for block BLK#1, each of the bitmap flags corresponding to offsets +4 to +7 is changed from 0 to 1.

Then, as shown in FIG. 25, the controller 4 returns a response to this write command to the host 2 (step S13). This response includes at least the offset (intra-block offset) at which this data was written.
When the host 2 receives this response, the host 2 updates the LUT 411 managed by the host 2 and maps a physical address to each logical address corresponding to the written write data. As shown in FIG. 28, LUT 411 includes multiple entries corresponding to multiple logical addresses (for example, LBA). An entry corresponding to a certain logical address (for example, a certain LBA) contains a physical address PBA indicating the position (physical storage position) in the NAND flash memory 5 where the data corresponding to this LBA is stored, that is, the block number and offset. (intra-block offset) is stored. As shown in FIG. 26, if the 16K byte update data whose starting LBA is LBAx is written to the physical storage locations corresponding to offsets +4 to +7 of block BLK#1, as shown in FIG. As shown in FIG. , offset +6 are stored, and BLK#1 and offset +7 are stored in the entry corresponding to LBAx+3.

As shown in FIG. 25, the host 2 then sends a Trim command to the flash storage device 3 to invalidate the previous data that has become unnecessary due to the writing of the update data described above. As shown in FIG. 26, if the previous data is stored in the positions corresponding to offset +0, offset +1, offset +2, and offset +3 of block BLK#0, as shown in FIG. A Trim command specifying the block number (=BLK#0), offset (=+0), and length (=4) is sent from the host 2 to the flash storage device 3. The controller 4 of the flash storage device 3 updates the block management table 32 in response to this Trim command (FIG. 25, step S14). In step S15, as shown in FIG. 29, in the block management table for block BLK#0, each of the bitmap flags corresponding to offsets +0 to +3 is changed from 1 to 0.

FIG. 30 shows a read command applied to the flash storage device 3.
The read command is a command that requests the flash storage device 3 to read data. This read command includes a command ID, physical address PBA, length, and transfer destination pointer.

The command ID is an ID (command code) indicating that this command is a read command, and the read command includes a command ID for the read command.
Physical address PBA indicates the first physical storage location from which data is to be read. The physical address PBA is specified by a block number and an offset (intra-block offset).

Length indicates the length of data to be read. This data length can be specified by the number of grains.
The transfer destination pointer indicates the location in the memory within the host 2 to which the read data is to be transferred.
One read command can specify multiple pairs of physical address PBA (block number, offset) and length.

FIG. 31 shows a read operation.
Here, it is assumed that a read command specifying a block number (=BLK#2), an offset (=+5), and a length (=3) is received from the host 2. The controller 4 of the flash storage device 3 reads data d1 to d3 from BLK#2 based on the block number (=BLK#2), offset (=+5), and length (=3). In this case, the controller 4 reads one page size worth of data from page 1 of BLK#2, and extracts data d1 to data d3 from this read data. Next, the controller 4 transfers the data d1 to data d3 onto the host memory specified by the transfer destination pointer.

FIG. 32 shows the operation of reading data portions stored in different physical storage locations in response to a read command from the host 2.
Here, the read that specifies the block number (=BLK#2), offset (=+10), length (=2), block number (=BLK#2), offset (=+16), and length (=4) is used. It is assumed that the command is received from host 2. The controller 4 of the flash storage device 3 reads one page size worth of data from page 2 of BLK#2 based on the block number (=BLK#2), offset (=+10), and length (=2). , extracts data d1 to data d2 from this read data. Next, the controller 4 extracts one page size worth of data (data d3 to data d6) from page 4 of BLK#2 based on the block number (=BLK#2), offset (=+16), and length (=4). ) to lead. Then, the controller 4 transfers the read data of length (=6) obtained by combining data d1 to data d2 and data d3 to data d6 to the host memory specified by the transfer destination pointer in the read command. Transfer to.

This allows data portions to be read from separate physical storage locations without causing read errors even if there are bad pages within the block. Furthermore, even if data is written across two blocks, this data can be read by issuing one read command.

FIG. 33 shows the sequence of read processing executed by the host 2 and flash storage device 3.
The host 2 refers to the LUT 411 managed by the host 2 and converts the logical address included in the read request from the user application into a block number and offset. Then, the host 2 sends a read command specifying this block number, offset, and length to the flash storage device 3.

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 this read command as the block to be read, and the block specified by this read command. The page to be read is determined based on the offset (step S31). In step S31, the controller 4 may first divide the offset specified by the read command by the number of granularity (4 in this case) representing the page size. Then, the controller 4 may determine the quotient and remainder obtained by this division as the page number of the read target and the intra-page offset position of the read target, respectively.

The controller 4 reads data defined by the block number, offset, and length from the NAND flash memory 5 (step S32), and transmits this read data to the host 2.
FIG. 34 shows GC control commands applied to the flash storage device 3.

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

The command ID is an ID (command code) indicating that this command is a GC control command, and the GC control command includes a command ID for the GC control command.
The GC source block number is a block number indicating a GC source block. The host 2 can specify which block should be the GC source block. The host 2 may set multiple GC source block numbers in one GC control command.

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

FIG. 35 shows a GC callback command.
The GC callback command is used to notify the host 2 of the logical address of valid data copied by the GC, and the block number and offset indicating the copy destination position of this valid data.
The GC callback command may include a command ID, logical address, length, and destination physical address.

The command ID is an ID (command code) indicating that this command is a GC callback command, and the GC callback command includes a command ID for the GC callback command.
The logical address indicates the logical address of valid data copied from the GC source block to the GC destination block by the GC.

Length indicates the length of this copied data. This data length may be specified by the number of grains.
The destination physical address indicates the location within the GC destination block where valid data has been copied. The destination physical address is specified by a block number and an offset (intra-block offset).

FIG. 36 shows the procedure of garbage collection (GC) operation.
For example, when the number of remaining free blocks included in the free block list managed by host 2 falls below a threshold, host 2 selects a GC source block and a GC destination block, and selects a GC source block and a GC destination block. A GC control command specifying the source block and the selected GC destination block is transmitted to the flash storage device 3 (step S41). Alternatively, in a configuration in which the write processing unit 412 manages free block groups, when the number of remaining free blocks falls below a threshold, the write processing unit 412 notifies the host 2 to that effect, and the host 2 that receives the notification may perform block selection and transmit GC control commands.

Upon receiving this GC control command, the controller 4 of the flash storage device 3 determines the position (copy destination position) in the GC destination block where valid data in the GC source block should be written, and A data copy operation including an operation of copying valid data to a copy destination position in the GC destination block is executed (step S51). In step S51, the controller 4 transfers not only the valid data in the GC source block (copy source block) but also both this valid data and the logical address corresponding to this valid data from the GC source block (copy source block). Copy to the destination block (copy destination block). Thereby, a pair of data and a logical address can be held in the GC destination block (copy destination block).

Furthermore, in step S51, the data copy operation is repeatedly executed until all valid data in the GC source block has been copied. If multiple GC source blocks are specified by the GC control command, the data copy operation is repeatedly performed until all valid data in all GC source blocks has been copied.

Then, for each copied valid data, the controller 4 uses a GC callback command to send the logical address (LBA) of the valid data, the destination physical address indicating the copy destination position of the valid data, etc. The host 2 is notified (step S52). The destination physical address corresponding to certain valid data indicates the block number of the copy destination block (GC destination block) to which this valid data has been copied and the physical storage location within the copy destination block to which this valid data has been copied. It is represented by an intra-block physical address (intra-block offset).

When host 2 receives this GC callback command, host 2 updates the LUT 411 managed by host 2 and assigns a destination physical address (block number) to the logical address corresponding to each copied valid data. , intra-block offset) (step S42).

FIG. 37 shows an example of a data copy operation performed for GC.
In FIG. 37, valid data (LBA=10) stored at a position corresponding to offset +4 of the GC source block (here, block BLK#50) is offset from the GC destination block (here, block BLK#100). The valid data (LBA=20) copied to the position corresponding to +0 and stored at the position corresponding to offset +10 of the GC source block (block BLK#50 here) is copied to the position corresponding to offset +10 of the GC destination block (block BLK#50 here). #100) is assumed to be copied to a position corresponding to offset +1. In this case, the controller 4 notifies the host of {LBA10, BLK#100, offset (=+0), LBA20, BLK#100, offset (=+1)} (GC callback process).

FIG. 38 shows the contents of the LUT 411 of host 2 that is updated based on the result of the data copy operation of FIG. 37.
In this LUT 411, 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).

After the LUT 411 is updated, the host 2 sends a Trim command specifying BLK#50 and offset (=+4) to the flash storage device 3, and stores it in the position corresponding to the offset (=+4) of BLK#50. You may invalidate the data that has been set. Furthermore, the host 2 sends a Trim command that specifies BLK#50 and an offset (=+10) to the flash storage device 3 to remove the data stored in the location corresponding to the offset (=+10) of BLK#50. May be disabled. Alternatively, the controller 4 may update the block management table 32 and invalidate these data as part of the GC processing without transmitting the Trim command from the host 2.

As explained above, according to this embodiment, when a write request specifying a first logical address and a first block number is received from the host 2, the controller 4 of the flash storage device 3 receives the write request from the host 2. The position (destination position) in the block having the first block number (destination block) to which the data of 2 is to be written is determined, the data from the host 2 is written to the destination position of the destination block, and the The host 2 is notified of either the first in-block physical address indicating the location or the set of the first logical address, first block number, and first in-block physical address.

Therefore, the host 2 handles the block number, and the flash storage device 3 takes into account page write order constraints/bad pages, etc., and determines the write destination position (intra-block offset) within the block having the block number specified by the host 2. It is possible to realize a configuration in which the By the host 2 handling the block number, it is possible to realize the merging of the application level address translation table of the upper layer (host 2) and the LUT level address translation table of the conventional SSD. Further, the flash storage device 3 can control the NAND flash memory 5 in consideration of the characteristics/constraints of the NAND flash memory 5. Furthermore, since the host 2 can recognize block boundaries, it can write user data into each block taking the block boundaries/block size into consideration. This makes it possible for the host 2 to perform control such as invalidating data in the same block all at once by updating data, etc., thereby making it possible to reduce the frequency at which GC is executed. As a result, write amplification is reduced, the performance of the flash storage device 3 can be improved, and the life of the flash storage device 3 can be maximized.

Therefore, appropriate division of roles between the host 2 and the flash storage device 3 can be realized, and thereby the I/O performance of the entire system including the host 2 and the flash storage device 3 can be improved.
Further, when receiving a control command from the host 2 that specifies a copy source block number and a copy destination block number for garbage collection, the controller 4 of the flash storage device 3 selects the first block number having the copy source block number from among the plurality of blocks. 2 and a third block having the copy destination block number, determine the copy destination position in the third block to which the valid data stored in the second block is to be written, and write the valid data to the third block. Copy to the copy destination position of block 3. Then, the controller notifies the host 2 of the logical address of the valid data, the copy destination block number, and the physical address within the second block indicating the copy destination position within the third block. As a result, even in GC, it is possible to realize a configuration in which the host 2 only handles block numbers (copy source block number, copy destination block number), and the flash storage device 3 determines the copy destination position within the copy destination block. .

Note that the flash storage device 3 may be used as one of a plurality of flash storage devices 3 provided within a storage array. The storage array may be connected to an information processing device such as a server computer via a cable or a network. The storage array includes a controller that controls multiple flash storage devices 3 within the storage array. If the flash storage device 3 is applied to a storage array, the controller of this storage array may function as the host 2 of the flash storage device 3.

Further, in this embodiment, a NAND flash memory is exemplified as a nonvolatile memory. However, the functions of this embodiment are, for example, MRAM (Magnetoresistive
Random Access Memory), PRAM (Phase change
It is also applicable to various other non-volatile memories such as Random Access Memory (Random Access Memory), ReRAM (Resistive Random Access Memory), or FeRAM (Ferroelectric Random Access Memory).

FIG. 39 shows the system architecture of the host 2 and flash storage device 3. Specifically, FIG. 39 shows the write data buffer 51 and flash translation unit 52 included in the host 2, and the write operation control unit 21, read operation control unit 22, and (GC operation control unit) included in the flash storage device 3. 23) shows the relationship with the optimization processing unit 53 (including 23).

The host 2 stores write data in a write data buffer 51 on the host memory, and issues a write command to the flash storage device 3. This write command includes a data pointer indicating the position on the write data buffer 51 where this write data exists, a tag (for example, LBA) that identifies this write data, the length of this write data, and the location where the write data should be written. It may also include an identifier indicating the block (block address or stream ID).

The flash storage device 3 may be implemented as any of the following storage devices: type #1-storage device, type #2-storage device, type #3-storage device.
Type #1 - Storage Device is a type of storage device in which the host 2 specifies both the block where data is to be written and the page address where this data is to be written. Type #1 - Write commands applied to storage devices include block address, page address, data pointer, length. The block address specifies the block into which write data received from the host 2 is to be written. The page address specifies the page within this block to which this write data is to be written. The data pointer indicates the location in the memory within the host 2 where this write data exists. The length indicates the length of this write data.

Type #2 - Storage device is a type of storage device where the host 2 specifies the block where data is to be written and the storage device specifies the location (page) within this block where this data is to be written. Type #2 - A write command applied to a storage device includes a tag (eg, LBA, key), block address, data pointer, length to identify the write data to be written. Furthermore, the write command may include a QoS domain ID. The QoS domain ID specifies one of multiple areas obtained by logically dividing the NAND flash memory. Each of the multiple regions includes multiple blocks. Type #2 - The storage device can consider bad pages, page write order constraints, and decide which page the data should be written to.

In other words, in the case where the flash storage device 3 is implemented as a type #2 storage device, the flash storage device 3 allows the host 2 to handle blocks while hiding page write order constraints, bad pages, page sizes, etc. can do. As a result, the host 2 can recognize block boundaries and manage which user data resides in which block without being aware of page write order constraints, bad pages, and page sizes.

Type #3 - Storage Device is a type of storage device in which the host 2 specifies a tag (eg, LBA) that identifies the data, and the storage device determines both the block and page to which this data is written. Type #3 - A write command applied to a storage device includes a tag (eg, LBA, key), stream ID, data pointer, length to identify the write data to be written. The stream ID is an identifier of a stream associated with this write data. In the case where the flash storage device 3 is realized as a type #3-storage device, the flash storage device 3 performs this write processing by referring to a management table that manages the mapping between each stream ID and each block address. Determine the block to which data should be written. Furthermore, the flash storage device 3 uses an address translation table called a logical-physical address translation table to manage the mapping between each tag (LBA) and each physical address of the NAND flash memory.

When the flash storage device 3 is realized as a type #1 storage device, the flash storage device 3 performs a write operation of the write destination block specified by the identifier of this block under the control of the write operation control unit 21. As the process progresses, data transfer from the write data buffer 51 to the internal buffer (shared cache) 31 is executed by the DMAC. This data transfer is performed in units of the same data size as the data writing unit of the NAND flash memory 5. Under the control of the write operation control section 21, the write data to be written is transferred from the internal buffer (shared cache) 31 to the NAND flash memory chip 15 that includes this write destination block, and then from the write operation control section 21 to this write destination block. A NAND command for writing instructions is sent to the NAND flash memory chip 15.

If the flash storage device 3 is implemented as a type #2 storage device, the write operation control unit 21 assigns one of the free blocks to the write destination block in response to a block allocation request received from the host 2. It also executes the process of allocating it to host 2 as a host. The block allocation request may include a QoS domain ID. The write control unit 21 determines one of the free blocks belonging to this QoS domain ID as a write destination block, and notifies the host 2 of the block address of this write destination block. This allows the host 2 to issue a write command that specifies this block address, data pointer, tag (for example, LBA), and length. After this write data is written to this write destination block, the write operation control unit 21 sends the block address indicating the write destination block to which this write data has been written, and the block address in this write destination block to which this write data has been written. The page address indicating the page and the tag (for example, LBA) of this write data are notified to the host 2. The flash translation unit 52 of the host 2 runs an LUT 411 that is an address translation table that manages mapping between each tag (for example, LBA) and each physical address (block address, page address, etc.) of the NAND flash memory 5. include. When the block address, page address, and tag (for example, LBA) are notified from the flash storage device 3, the flash translation unit 52 updates the LUT 411 and assigns the notified physical address to the notified tag (for example, LBA). (block address, page address). The flash translation unit 52 can convert the tag (for example, LBA) included in the read request into a physical address (block address, page address) by referring to the LUT 411, and thereby converts the read command including the physical address. It can be issued to the flash storage device 3.

When the flash storage device 3 is implemented as a type #1 storage device or a type #2 storage device, the read operation control unit 22 performs read operations on the NAND flash memory chip 15 based on the physical address included in the read command. Sends an instruction NAND command. If the flash storage device 3 is implemented as a type #3 storage device, the read operation control unit 22 refers to the address conversion table and determines the physical address corresponding to the tag (LBA) included in the read command. Based on the obtained physical address, a NAND command for instructing the NAND flash memory chip 15 to read is sent.

Under the control of the read operation control unit 22, data read from the NAND flash memory chip 15 is transferred to the internal buffer (shared cache) 31. Then, under the control of the read operation control unit 22, data transfer from the internal buffer (shared cache) 31 to the host 2 is executed by the DMAC. Furthermore, if the read data to be read exists in the write data buffer 51 of the host 2, the read operation control unit 22 can acquire the read data from the write data buffer 51. Alternatively, the host 2 may be instructed to obtain read data from the write data buffer 51. Note that the area where write data on the write data buffer 51 is stored can be released by being sent from the write operation control unit 21 to the host 2 when the write operation control unit 21 completes writing to the NAND flash memory 5. Upon notification, it is released on the host 2 side. For example, if writing to the NAND flash memory 5 by the write operation control unit 21 fails and the write data is written to a different location (a different page or block), the data required for the write has not yet been released. , data transfer from the write data buffer 51 area of the host 2 to the internal buffer (shared cache) 31 of the flash storage device 3 is re-executed. Data rewriting may be performed within the range where the error was detected, or may be performed within the entire range of the write command. The release possibility notification may be notified to the host 2 in units of write commands, or may be notified to the host 2 in units of data usage by the host 2.

The optimization processing unit 53 (including the GC operation control unit 23) executes, for example, a process of returning an allocated block to a free block in response to a block release request received from the host 2. The host 2 sends a block release request to the flash storage device 3 as a block reuse command. The allocated blocks that can be specified in the block reuse command are only available if the flash storage device 3 is implemented as a type #1 storage device and the host 2 does not manage free block groups, or if the flash storage device 3 is of type #1-storage device and the host 2 does not manage free blocks 2-When implemented as a storage device, this is a block allocated from free blocks in response to a block allocation request received from the host 2 as a block allocation command. Further, the optimization processing unit 53 executes processing such as copying data of a certain block to another block in response to a GC control command received from the host 2, for example.

Further, various commands that the flash storage device 3 receives from the host 2 may include priorities. In other words, the flash storage device 3 can execute commands received from the host 2 later, giving priority to commands received from the host 2 first. Control of the command execution order can be realized, for example, by comparing the priorities of commands when taking out commands from an I/O command queue in which various commands received from the host 2 are temporarily stored. The I/O command queue may be provided for each QoS domain, for each virtual storage device (VD) described later, or for each flash storage device 3. They may be provided one at a time.

In the flash storage device 3 in which the NAND flash memory 5 includes a plurality of NAND flash memory chips 15, one or more virtual storage devices can be defined. FIG. 40 shows an example of defining a virtual storage device on the flash storage device 3.

In FIG. 40, (A) shows an example of the definition of a plurality of virtual storage devices in which a channel connected to the NAND interface 13 is shared among the virtual storage devices. (B) shows an example of the definition of a plurality of virtual storage devices in which the channels connected to the NAND interface 13 are not shared among the virtual storage devices. (C) shows an example of the definition of one virtual storage device using all of the plurality of NAND flash memory chips 15 included in the NAND flash memory 5. (D) shows an example of defining the same number of virtual storage devices as the NAND flash memory chips 15, that is, the maximum number, using each of the plurality of NAND flash memory chips 15 included in the NAND flash memory 5.

In this way, one or more virtual storage devices can be defined on the flash storage device 3 in various forms. When a virtual storage device is defined, for example, wear monitoring for monitoring the degree of wear of the NAND flash memory chip 15 can be performed for each virtual storage device.

Furthermore, in the flash storage device 3 in which one or more virtual storage devices can be defined, a QoS domain can be managed for each virtual storage device. FIG. 41 shows an example in which QoS domains are managed for each virtual storage device.
Blocks of flash storage device 3 are shared between QoS domains defined on the same virtual storage device. The unit for handling blocks may be a superblock unit composed of a plurality of blocks. That is, superblocks may be shared between QoS domains. For example, when a QoS domain is assigned to each end user, when a block allocate command including a QoS domain ID indicating a QoS domain is received from the host 2, allocate blocks among the free blocks shared within the virtual storage device. One free block is assigned to the QoS domain indicated by the QoS domain ID.

On the other hand, when a block reuse command including a QoS domain ID and a block address is received from the host 2, the block indicated by the block address among the blocks assigned to the QoS domain indicated by the QoS domain ID becomes a free block. It is returned to the free block group as a free block group. Returning a block assigned to a QoS domain to the free block group as a free block is also referred to as releasing the block. The freed block may then be allocated to any QoS domain within that virtual storage device, such as by a block allocate command from host 2, for example.

By the way, when a block reuse command targeting a certain block in a certain QoS domain is received from the host 2, it is determined whether a read command targeting that block is being executed or not yet executed in the flash storage device 3. In this case, if the block reuse command is executed before the read command, there is a risk that, for example, data with an undefined value may be returned to the host 2. As mentioned above, various commands that the flash storage device 3 receives from the host 2 may include priorities, so the flash storage device 3 gives priority to read commands received from the host 2 first, and The block reuse command received from the host 2 can be executed. Further, in addition to a read command, a similar situation may occur when, for example, data in a block is copied to another block in response to a GC control command. In other words, if a data read process for that block is being executed or not yet executed, there is a risk that unintended data may be read in the currently executed or unexecuted data read process.

In order to prevent such a situation through control on the host 2 side, it is necessary for the host 2 to manage, for example, whether there is a data read process in progress for each block. Therefore, the flash storage device 3 may be provided with a mechanism to prevent such a situation to reduce the burden on the host 2.

When the flash storage device 3 receives a block reuse command from the host 2, if the data read process for the block specified by the block reuse command is being executed or has not yet been executed, the flash storage device 3 receives the block reuse command from the host 2. 2, or suspends the execution of the block reuse command until the currently executed or unexecuted process is completed, and then executes the block reuse command when the currently executed or unexecuted process is completed.

By providing this mechanism in the flash storage device 3, the host 2 can send a block reuse command to the flash storage device without worrying about, for example, whether or not there is a pending data read process for the block to be released. You will be able to send it to 3. In other words, the burden on the host 2 can be reduced.

In this mechanism, for example, when the optimization processing unit 53 receives a block reuse command or executes a block reuse command, a read command or a GC control command targeting a block specified by the block reuse command is This can be realized by searching the command queue 42 to see if it is stored. FIG. 41 shows an example in which the I/O command queue 42 is provided for each QoS domain, and in this case, the optimization processing unit 53 The I/O command queue 42 provided for the block reuse command is checked to see if there is a read command or a GC control command that targets the block indicated by the block address included in the block reuse command. When one I/O command queue 42 is provided for each virtual storage device or each flash storage device, the optimization processing unit 53 determines the QoS domain included in the block reuse command for the I/O command queue 42. It is checked whether there is a read command or a GC control command that targets the block indicated by the block address included in the block reuse command in the QoS domain indicated by the ID. If the optimization processing unit 53 exists, the optimization processing unit 53 notifies the host 2 of the error, or executes a read command or GC control for the block specified by the block reuse command that exists in the I/O command queue 42. Holds execution of block reuse commands until the commands are finished, and then executes block reuse commands.

Alternatively, for example, for each block selected from a group of free blocks and assigned to a QoS domain, this mechanism can calculate the number of read commands being executed for that block, and the number of GCs being executed with that block as a copy source. This can be realized by providing a counter indicating the number of control commands as metadata or the like. For example, when the read operation control unit 21 or the optimization processing unit 53 (including the GC operation control unit 23) executes data read processing for a certain block, it adds one to the counter value of that block. . Furthermore, when the read operation control unit 21 and the optimization processing unit 53 complete the data read process, they subtract one from the counter value of the block. When receiving a block reuse command or executing a block reuse command, the optimization processing unit 53 notifies the host 2 of an error if the counter value of the block specified by the block reuse command is not 0, or , the execution of the block reuse command is suspended until the counter value reaches 0, and when the counter value becomes 0, the block reuse command is executed.

FIG. 42 is a flowchart showing the operation procedure (first case) of the flash storage device 3 when receiving a block reuse command. Note that although here it is assumed that the block reuse command is received, the operations described below may be performed when the block reuse command is executed.

When a block reuse command is received from the host 2 (step A1), the optimization processing unit 23 determines whether there is a read process being executed or waiting to be executed for the block specified by the block reuse command. (Step A2). If it does not exist (step A2: NO), the optimization processing unit 23 makes the specified block a free block (releases it) and returns a response indicating completion of reuse to the host 2 (step A3).

On the other hand, if the error exists (step A2: YES), the optimization processing unit 23 notifies the host 2 of the error (step A4).
FIG. 43 is a flowchart showing the operation procedure (second case) of the flash storage device 3 when receiving a block reuse command. Again, it is assumed that the block reuse command is received, but the operations described below may also be performed when the block reuse command is executed.

When a block reuse command is received from the host 2 (step A11), the optimization processing unit 23 determines whether there is a read process being executed or waiting to be executed for the block specified by the block reuse command. is determined (step A12).

If it does not exist (step A12: NO), the optimization processing unit 23 immediately makes the specified block a free block (releases it) and returns a response indicating completion of reuse to the host 2 (step A14). On the other hand, if it exists (step A12: YES), then the optimization processing unit 23 determines whether all the corresponding read processing has been completed (step A13), and if all the corresponding read processing is completed (step A13: YES) ), the specified block is made into a free block (released), and a response indicating completion of reuse is returned to the host 2 (step A14).

In addition, in the above, when a block reuse command is received from the host 2, a block is specified when a read command or GC control command that is currently being executed or is waiting for execution has been received for the block specified by the block reuse command. Explained the handling of reuse commands. Furthermore, after a block reuse command is received from the host 2, if a read command or GC control command is received from the host 2 that targets the block specified by the block reuse command, the flash storage device 3 will generate an error message. may be returned to the host 2.

Further, as described with reference to FIG. 41, the blocks of the flash storage device 3 are shared, for example, between QoS domains managed for each virtual storage device. That is, for example, a free block group is managed for each virtual storage device, and free blocks are allocated to each QoS domain from the free block group.

Cases in which data is written to a block can be roughly divided into two cases, one is a case in which data stored in the write data buffer 51 of the host 2 is written in response to a write command received from the host 2, and the other is a case in which data is written in a GC control received from the host 2. There are cases where data stored in another block of the flash storage device 3 is written in response to a command. The data stored in the write data buffer 51 of the host 2 is new, and the data stored in another block of the flash storage device 3 is old. Therefore, if these data are mixed in the same block, write amplification may worsen. Therefore, if this flash storage device 3 is implemented as a type #3 storage device in which the storage device determines both the block and page to which data is written, data from the host 2 is written for each QoS domain. A mechanism may be provided to separate blocks into blocks for copying data in the flash storage device 3 and blocks for copying data in the flash storage device 3. When blocks are handled in units of superblocks, the superblocks are separated into superblocks for writing data from the host 2 and superblocks for copying data in the flash storage device 3. That is, for each QoS domain, a block for writing data from the host 2 and a block for copying data in the flash storage device 3 are secured as blocks containing free pages.

This separation of blocks can be realized, for example, by holding attribute information indicating the use of each block selected from the free block group and assigned to the QoS domain as metadata. When the QoS domain starts being used, neither a block for writing data from the host 2 nor a block for copying data in the flash storage device 3 is reserved. Note that "a block is secured" means that a block including a free page is allocated.

For example, when writing data from the host 2 in a certain QoS domain, the write operation control unit 21 secures a block whose attribute information indicates that the block is for writing data from the host 2 in that QoS domain. If not, one free block among the free blocks is acquired for that QoS domain and data is written to the acquired block. At the time of this acquisition, the write operation control unit 21 records attribute information indicating that the block is a block for writing data from the host 2 as metadata. On the other hand, if a block for writing data from the host 2 whose attribute information indicates that it is a block for writing data from the host 2 is secured, the write operation control unit 21 controls the block in which the data from the host 2 is written. Data is written from the page following the last written page. When data is written to the last page of the block during data writing, the block returns to an unallocated state, so the write operation control unit 21 assigns one free block from the free block group to the QoS domain. and write the following data to the acquired block. At the time of this acquisition, the write operation control unit 21 also records attribute information indicating that the block is a block for writing data from the host 2 as metadata.

Furthermore, for example, when the optimization processing unit 53 (including the GC operation control unit 23) executes data copying for a certain QoS domain, the optimization processing unit 53 (including the GC operation control unit 23) may copy data in the flash storage device 3 based on the attribute information in that QoS domain. If the block is not reserved, one free block from the free block group is acquired for that QoS domain, and data is written (copied) to the acquired block. At the time of this acquisition, the optimization processing unit 53 records attribute information indicating that the block is a block for copying data in the flash storage device 3 as metadata. On the other hand, if a block for copying data in the flash storage device 3 whose attribute information indicates that it is a block for copying data in the flash storage device 3 is secured, the optimization processing unit 53 writes data from the page following the last written page in the block. When data is written to the last page of the block during data writing, the block returns to an unallocated state, so the optimization processing unit 53 allocates one free block from the free block group for that QoS domain. and write data to the retrieved block. At the time of this acquisition, the optimization processing unit 53 records attribute information indicating that the block is a block for copying data in the flash storage device 3 as metadata.

In this way, this flash storage device 3 provides write amplification by separating blocks for writing new data from the host 2 and blocks for copying old data in the flash storage device 3. Deterioration can be prevented.

Further, as described with reference to FIG. 39, if the read data to be read exists in the write data buffer 51 of the host 2, the read operation control unit 22 can acquire the read data from the write data buffer 51. can. On the other hand, the area where write data is stored on the write data buffer 51 is released on the host 2 side when the write operation control unit 21 sends a notification that it can be released to the host 2 . Therefore, when the flash storage device 3 receives a read command from the host 2 that targets data in the write data existing in the write data buffer 51, the data is stored until the read command is completed. A mechanism may be provided to prevent the host 2 from transmitting a releasable notification regarding the area.

For example, this mechanism calculates the number of data write operations and read operations for write data stored in the write data buffer 51 of the host 2 in units of write commands received from the host 2 or units of data usage by the host 2. This can be realized by providing a counter indicating the remaining number as metadata. The counter is provided, for example, in accordance with the unit in which the releasable notification is notified to the host 2. In the case where the host 2 is notified of releasability in units of write commands, a counter may be provided in units of data usage by the host 2.

Assuming that a counter is provided for each data usage unit of the host 2, the write operation control unit 21 sets the number of data transfers necessary for writing data to the NAND flash memory 5+1 as the initial value of each counter. do. +1 is added for rewriting processing when an error is detected.

The write operation control unit 21 decrements the value of the corresponding counter by 1 each time data is transferred to the NAND flash memory 5. Assuming that data transfer for a certain data usage unit is completed, the value of the counter generally becomes 1 at that point. When it is determined that all the transferred data has been written to the NAND flash memory 5 and rewriting processing is no longer necessary when an error is detected, the write operation control unit 21 further subtracts 1 from the value of the corresponding counter. do. At this point, the value of the counter is generally zero. Assuming that a releasable notification is sent to the host 2 in units of data usage by the host 2, when the write operation control unit 21 detects that the counter value has become 0, it will A releasable notification is sent to the host 2. Note that if an error is detected, the write operation control unit 21 re-adds the number of data transfers necessary for rewriting processing to the counter. Even if an error is detected after the data has been transferred to the NAND flash memory 5, the counter value is not 0, so the release possibility notification is not notified to the host 2, which is necessary for the rewrite process. The data exists in the write data buffer 51 of the host 2. Therefore, data transfer from the write data buffer 51 of the host 2 to the internal buffer (shared cache) 31 of the flash storage device 3 can be re-executed.

When the read operation control unit 21 also receives a read command from the host 2 that targets data in the write data existing in the write data buffer 51 of the host 2, it increments the value of the counter corresponding to the data by 1. Then, when the read processing is completed, the read operation control unit 21 subtracts 1 from the value of the corresponding counter.

Regarding the data to be read out in the write data existing on the write data buffer 51, even if writing to the NAND flash memory 5 is completed, the value of the corresponding counter does not become 0 and can be released. Notification is not sent to host 2. That is, by adding 1 to the value of the counter, the read operation control unit 21 sets the target area on the write data buffer 51 in a release prohibited state. Therefore, in a situation where a read command that targets data in the write data existing in the write data buffer 51 of the host 2 is received from the host 2, the area on the write data buffer 51 containing the data is on the host 2 side. It will never be released.

Note that when a read command that targets data in the write data existing in the write data buffer 51 of the host 2 is received from the host 2, the read operation control unit 21 does not necessarily read the data from the write data buffer 51. Alternatively, if writing of the write data to the NAND flash memory 5 is completed and the write data is in a readable state, the write data may be read from the NAND flash memory 5. In this case, the write data on the write data buffer 51 can be used as, for example, spare data.

When a releasable notification is notified to the host 2 for each write command and a counter is provided for each data usage unit of the host 2, the write operation control unit 21 updates all the counters corresponding to the write data to be written by the write command. When the value becomes 0, a releasable notification is sent to the host 2.

Also, focusing on the fact that the read operation control unit 22 can acquire read data from the write data buffer 51, when this flash storage device 3 is realized as a type #2 storage device, it is possible to obtain read data from the host 2. The host 2 may be provided with a mechanism for notifying the host 2 of the page address at which the write data is scheduled to be written without waiting for the completion of writing to the NAND flash memory 5. When the flash storage device 3 is equipped with this mechanism, the host 2 does not have to wait until the data written by the write command becomes readable in the flash storage device 3, and the host 2 does not have to wait until the data written by the write command becomes readable. It becomes possible to promptly issue a read command that targets the data.

In this mechanism, for example, the write operation control unit 21 creates a write buffer list for each write destination block, which provides information regarding the write data on the write data buffer 51 notified from the host 2 as metadata when receiving a write command. This can be achieved by notifying the host 2 of the page address to which write data is to be written for each unit of data usage by the host 2. The size of the write data registered in the write buffer list may be larger than the size of the remaining write area of the write destination block. In this case, the write operation control unit 21 first notifies the host 2 of the page address to be written for the amount that can be written to the write destination block, and after writing to the write destination block is completed, a new write destination is assigned. After the blocks are secured, the host 2 is notified of the page addresses to be written for the remaining blocks. All write data exists on the write data buffer 51, and it takes only a very short time to secure a write destination block, so there is no practical problem even if write data is written across blocks.

If an error is detected during writing to the NAND flash memory 5, the write operation control unit 21 notifies the host 2 of the newly determined page address to be written. Note that the notification of the page address to the host 2 may be carried out at the time when the page address to be written is determined, as described above, or may be carried out every time writing is completed in units of data usage by the host 2. . In the former case, the notification to the host 2 may occur multiple times when an error is detected, but the notification to the host 2 is quick. In the latter case, the notification to the host 2 will be slower than in the former case, but even if an error is detected when writing to the NAND flash memory 5, the notification will be sent once regardless of the number of times. That would be enough.

Next, various I/O command processing executed by this flash storage device 3, including write command processing using the write data buffer 51 of the host 2, will be explained in detail.
FIG. 44 shows I/O command processing executed by the flash storage device 3.

As described above, in this embodiment, the flash storage device 3 may be any type #1 storage device, type #2 storage device, or type #3 storage device, but in FIG. The case where device 3 is a type #1 storage device is illustrated.

Each write command issued by the host 2 includes a block address, page address, data pointer, and length. Each issued write command is placed in the I/O command queue 42. Each read command issued by the host 2 also includes a block address, page address, data pointer, and length. Each issued read command is also placed in the I/O command queue 42.

When the host 2 wishes to request the flash storage device 3 to write write data, the host 2 first stores this write data in the write data buffer 51 on the host memory, and then sends the write command to the flash storage device 3. Issued on 3rd. This write command includes the block address indicating the write destination block to which this write data is to be written, the page address indicating the page within this write destination block to which this write data is to be written, and the write data buffer where this write data exists. 51 and the length of this write data.

Flash storage device 3 includes a program/read sequencer 41 . This program/read sequencer 41 is realized by the write control section 21 and read control section 22 described above. The program/read sequencer 41 can execute each command placed in the I/O command queue 42 in any order.

After the program/read sequencer 41 obtains one or more write commands specifying the same write destination block from the I/O command queue 42, the program/read sequencer 41 adjusts the write commands in accordance with the progress of the write operation of this write destination block. Then, a transfer request is sent to the internal buffer (shared cache) 31 or the write data buffer 51 to obtain the next write data (for example, write data for one page size) to be written to this write destination block. )31. This transfer request may include a data pointer and length. The data pointer included in this transfer request is created by dividing the write data associated with one write command or by combining two or more write data associated with two or more write commands that specify the same write destination block. Calculated. In other words, the program/read sequencer 41 processes a set of write data associated with one or more write commands having identifiers indicating the same write destination block, starting from the beginning with the same size as the data write unit of the NAND flash memory 5. and identify the location in host memory that corresponds to each boundary. This allows the program/read sequencer 41 to obtain write data from the host 2 in units of the same size as write units.

The data pointer included in this transfer request indicates the position on the write data buffer 51 where this one page size worth of write data exists. This write data for one page size may be a collection of multiple small-sized write data associated with multiple write commands that specify this write destination block, or a single page size write data that specifies this write destination block. It may be a portion of large-sized write data associated with a write command.

Furthermore, the program/read sequencer 41 stores the block address of the write destination block into which this one page size worth of write data is to be written and the page address of the page into which this one page size worth of write data is to be written into an internal buffer ( (shared cache) 31.

The controller 4 of the flash storage device 3 may include a cache controller that controls an internal buffer (shared cache) 31. In this case, this cache controller can operate the internal buffer (shared cache) 31 as if it were control logic. A plurality of flush command queues 43 exist between the internal buffer (shared cache) 31 and the plurality of write destination blocks #0, #1, #2, . . . , #n. These flash command queues 43 are respectively associated with a plurality of NAND flash memory chips.

The internal buffer (shared cache) 31, that is, the cache controller, determines whether the write data for one page size specified by the transfer request exists in the internal buffer (shared cache) 31.
If the write data for this one page size specified by this transfer request exists in the internal buffer (shared cache) 31, the internal buffer (shared cache) 31, that is, the cache controller, transfers the write data for this one page size. is transferred to the NAND flash memory chip that includes the write destination block to which this write data is to be written. Furthermore, the internal buffer (shared cache) 31, that is, the cache controller, sends the block address of the write destination block to the NAND flash memory chip containing the write destination block to which this write data is to be written, and the page to which this write data is to be written. A NAND command (flash write command) for address and write instruction is sent via the flash command queue 43. A flash command queue 43 is provided for each NAND flash memory chip. Therefore, the internal buffer (shared cache) 31, that is, the cache controller, stores the block address of the write destination block, Enter the page address to which this write data is to be written and a NAND command (flash write command) for write instruction.

Note that this one page size write data transfer from the internal buffer (shared cache) 31 to the NAND flash memory chip is the final data transfer necessary to write this write data to the NAND flash memory chip. If there is, the internal buffer (shared cache) 31, that is, the cache controller discards this write data from the internal buffer (shared cache) 31, and reserves the area where this write data was stored as a free area. In the case where write data is written to the write destination block by a write operation that involves transferring data once to the NAND flash memory chip (for example, a full sequence write operation, etc.), the first transfer to the NAND flash memory chip This data transfer is the final data transfer. On the other hand, in the case where write data is written to a write destination block by a write operation that involves transferring data multiple times to a NAND flash memory chip (for example, a foggy fine write operation), the The data transfer to the NAND flash memory chip is the final data transfer.

Next, a case will be described in which the write data for one page size specified by the transfer request does not exist in the internal buffer (shared cache) 31.
If the write data for one page size specified by this transfer request does not exist in the internal buffer (shared cache) 31, the internal buffer (shared cache) 31, that is, the cache controller S) is sent to the DMAC 15. Based on this transfer request (data pointer, length), the DMAC 15 transfers this one page size worth of write data from the write data buffer 51 on the host memory to the internal buffer (shared cache) 31. When this data transfer is completed, the DMAC 15 notifies the internal buffer (shared cache) 31, that is, the cache controller, of the completion of the transfer (Done), this data pointer, and this length.

If a free space exists in the internal buffer (shared cache) 31, the internal buffer (shared cache) 31, that is, the cache controller stores the write data obtained from the write data buffer 51 by DMA transfer in this free space. .
If there is no free space in the internal buffer (shared cache) 31, the internal buffer (shared cache) 31, that is, the cache controller, transfers the oldest write data in the internal buffer (shared cache) 31 to the internal buffer (shared cache) 31. , and reserve the area where the oldest write data was stored as free space. Then, the internal buffer (shared cache) 31, that is, the cache controller, stores the write data acquired from the write data buffer 51 by DMA transfer in this free area.

In the case where a multi-stage write operation is used, such as a foggy fine write operation, the cache controller stores data in the internal buffer (shared cache) 31 where the first stage write operation, such as a foggy write operation, has finished. The oldest write data among the write data is discarded.

The progress speed of a data write operation to a write destination block with a large amount of data written tends to be faster than the progress speed of a data write operation to a write destination block with a small amount of data written. Therefore, write data to be written to a write destination block with a large amount of data written is frequently transferred from the write data buffer 51 to the internal buffer (shared cache) 31. As a result, there is a high possibility that this oldest write data is write data to a write destination block in which the amount of data written from the host 2 is relatively small. Therefore, the host 2 It becomes possible to efficiently reduce data traffic between the flash storage device 3 and the flash storage device 3.

Note that the algorithm for selecting write data to be discarded from among the write data in the internal buffer (shared cache) 31 for which the first stage write operation such as foggy write operation has been completed, selects the oldest data. The selection is not limited to first-in-first-out, and other algorithms such as LRU, random, etc. may be used.

The program/read sequencer 41 receives statuses, ie, write completion (Done), write failure (Error), block address, and page address, from each NAND flash memory chip. Based on these statuses, the program/read sequencer 41 performs a write operation for the entire write data associated with this write command (transfers the same data to the NAND flash memory chip once or multiple times) for each write command. It is determined whether all write operations) have been completed. When all write operations for the entire write data associated with a certain write command are completed, the program/read sequencer 41 transmits a response (Done) indicating completion of this write command to the host 2. The response (Done) indicating completion of this command includes a command ID that uniquely identifies this write command.

Next, processing of a read command will be explained.
The read command includes a block address indicating the block in which the data to be read is stored, a page address indicating the page in which this data is stored, and an address in the read data buffer 53 on the host memory to which this data is to be transferred. , and the length of this data.

The program/read sequencer 41 sends the block address and page address specified by the read command to the internal buffer (shared cache) 31, and requests the internal buffer (shared cache) 31 to read the data specified by the read command. .

The internal buffer (shared cache) 31, that is, the cache controller, sends this block address, this page address, and a NAND command for read instruction (flash read command) to the NAND flash memory chip via the flash command queue 43. Send. Data read from the NAND flash memory chip is transferred to the read data buffer 53 by the DMAC 15.

Note that if the data specified by the read command is data for which the write operation has not yet been completed, or data for which all write operations have been completed but is not yet readable from the NAND flash memory 5, the internal The buffer (shared cache) 31, ie, the cache controller, may determine whether this data exists in the internal buffer (shared cache) 31. If this data exists in the internal buffer (shared cache) 31, this data is read from the internal buffer (shared cache) 31 and transferred to the read data buffer 53 by the DMAC 15.

On the other hand, if this data does not exist in the internal buffer (shared cache) 31, this data is first transferred from the write data buffer 51 to the internal buffer (shared cache) 31 by the DMAC 15. Then, this data is read from the internal buffer (shared cache) 31 and transferred to the read data buffer 53 by the DMAC 15.

FIG. 45 illustrates a multi-step write operation performed by flash storage device 3.
Here, a foggy fine write operation when reciprocating through four word lines will be exemplified. Further, here, it is assumed that the NAND flash memory 5 is a QLC-flash that stores 4 bits of data per memory cell. A foggy fine write operation to one specific write destination block (here, write destination block BLK#1) in the NAND flash memory 5 is executed as follows.

(1) First, write data for four pages (P0 to P3) is transferred page by page to the NAND flash memory 5, and is transferred to multiple memory cells connected to the word line WL0 in the write destination block BLK#1. , a foggy write operation is performed to write write data for these four pages (P0 to P3).

(2) Next, the write data for the next four pages (P4 to P7) is transferred page by page to this NAND flash memory 5, and multiple A foggy write operation is performed to write write data for these four pages (P4 to P7) into the memory cells.

(3) Next, the write data for the next four pages (P8 to P11) is transferred to this NAND flash memory 5 in page units, and the A foggy write operation is performed to write write data for these four pages (P8 to P11) into the memory cells.

(4) Next, the write data for the next four pages (P12 to P15) is transferred page by page to this NAND flash memory 5, and the A foggy write operation is performed to write write data for these four pages (P12 to P15) into the memory cells.

(5) When the foggy write operation to the plurality of memory cells connected to the word line WL3 is completed, the word line to be written returns to the word line WL0, and the fine write operation to the plurality of memory cells connected to the word line WL0 is started. Execution becomes possible. Then, the write data for four pages (P0 to P3), which is the same as the write data for four pages (P0 to P3) used in the foggy write operation to word line WL0, is transferred again to the NAND flash memory 5 in page units. A fine write operation is executed to write write data for these four pages (P0 to P3) to a plurality of memory cells connected to the word line WL0 in this write destination block BLK#1. This completes the foggy fine write operation for pages P0 to P3.

(6) Next, the write data for the next four pages (P16 to P19) is transferred page by page to this NAND flash memory 5, and multiple A foggy write operation is performed to write write data for these four pages (P16 to P19) into the memory cells.

(7) When the foggy write operation to the plurality of memory cells connected to the word line WL4 is completed, the word line to be written returns to the word line WL1, and the fine write operation to the plurality of memory cells connected to the word line WL1 is started. Execution becomes possible. Then, the write data for four pages (P4 to P7), which is the same as the write data for four pages (P4 to P7) used in the foggy write operation to the word line WL1, is transferred again to the NAND flash memory 5 in page units. , a fine write operation is performed to write write data for these four pages (P4 to P7) to a plurality of memory cells connected to the word line WL1 in this write destination block BLK#1. This completes the foggy fine write operation for pages P4 to P7.

(8) Next, the write data for the next four pages (P20 to P23) is transferred page by page to this NAND flash memory 5, and the plurality of write data connected to the word line WL5 in this write destination block BLK#1 are A foggy write operation is performed to write write data for these four pages (P20 to P23) into the memory cells.

(9) When the foggy write operation to the plurality of memory cells connected to the word line WL5 is completed, the word line to be written returns to the word line WL2, and the fine write operation to the plurality of memory cells connected to the word line WL2 is started. Execution becomes possible. Then, the write data for four pages (P8 to P11), which is the same as the write data for four pages (P8 to P11) used in the foggy write operation to the word line WL2, is transferred again to the NAND flash memory 5 in page units. , a fine write operation is performed to write write data for these four pages (P8 to P11) to a plurality of memory cells connected to the word line WL2 in this write destination block BLK#1. This completes the foggy fine write operation for pages P8 to P11.

FIG. 46 shows the order of writing data to write destination block BLK#1.
Here, as in FIG. 7, it is assumed that a foggy fine write operation is performed when reciprocating between four word lines.
Data d0, data d1, data d2, data d3, data d4, data d5, data d6, data d7, ..., data d252, data d253, data d254, data d255 shown on the left side of FIG. 46 are write destination blocks. A plurality of write data corresponding to each of a plurality of write commands specifying BLK#1 are shown. Here, in order to simplify the illustration, it is assumed that all write data have the same size.

The right part of FIG. 46 shows the order in which data is written to the write destination block BLK#1. Write operations include writing data d0 to multiple memory cells connected to word line WL0 (foggy write), writing data d1 to multiple memory cells connected to word line WL1 (foggy writing), and writing data d1 to multiple memory cells connected to word line WL1 (foggy write). Writing data d2 to multiple memory cells connected to WL2 (foggy write), writing data d3 to multiple memory cells connected to word line WL3 (foggy writing), multiple memory cells connected to word line WL0 Writing data d0 to the memory cells of (fine write), writing data d4 to multiple memory cells connected to word line WL4 (foggy writing), writing data to multiple memory cells connected to word line WL1 Write data d1 (fine write), write data d5 to multiple memory cells connected to word line WL5 (foggy write), write data d2 to multiple memory cells connected to word line WL2 (fine write) ), ... are executed in this order.

FIG. 47 shows the operation of transferring write data from the host 2 to the flash storage device 3 in units of the same size as the data write unit of the NAND flash memory 5.
Data d1, data d2, data d3, data d4, data d5, data d6, data d7, data d8, data d9, data d10, etc. shown on the left side of FIG. 47 specify write destination block BLK#1. Ten pieces of write data corresponding to ten write commands are shown. The length (size) of write data differs for each write command. In FIG. 47, each of data d1, data d2, data d3, and data d4 has a size of 4K bytes, data d5 has a size of 8K bytes, data d6 has a size of 40K bytes, and data d7 has a size of 4K bytes. It is assumed that data d8 and data d9 each have a size of 8 Kbytes, and data d10 has a size of 1 Mbyte.

Since each write command received from the host 2 includes a data pointer, a length, and a block identifier (e.g. block address), the controller 4 of the flash storage device 3 can send the write command received from the host 2 to multiple write destinations. It can be classified into multiple groups, each corresponding to a block. The above data d1, data d2, data d3, data d4, data d5, data d6, data d7, data d8, data d9, data d10, ... are classified into 10 groups corresponding to the write destination block BLK#1. It corresponds to each write command. These ten write commands include a block identifier (for example, a block address) indicating the write destination block BLK#1.

The controller 4 of the flash storage device 3 writes data d1, data d2, data d3, data d4, data d5, data d6, based on the data pointer and length in these write commands that specify the write destination block BLK#1. The positions on the write data buffer 51 where data d7, data d8, data d9, and data d10 exist, and data d1, data d2, data d3, data d4, data d5, data d6, data d7, data d8, and data d9. , data d10. Then, the controller 4 divides the large-sized write data associated with one write command into multiple write data (multiple data parts), or divides the large-sized write data associated with one write command into two or more small-sized write data respectively associated with two or more write commands. Write data having the same size as the data write unit of the NAND flash memory 5, which is obtained by combining the write data with each other, is obtained from the host 2.

In FIG. 47, the controller 4 first transfers 16 Kbyte write data obtained by combining data d1, data d2, data d3, and data d4 each having a size of 4 Kbytes to the write data buffer 51 of the host 2. Get from. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by, for example, but not limited to, four DMA transfers. In the first DMA transfer, a transfer source address specifying the starting position of the data d1 and a data length of 4 KB may be set in the DMAC 15. A transfer source address that specifies the starting position of data d1 is represented by a data pointer in the write command corresponding to data d1. In the second DMA transfer, a transfer source address specifying the start position of data d2 and a data length of 4 KB may be set in the DMAC 15. The transfer source address that specifies the starting position of the data d2 is represented by the data pointer in the write command corresponding to the data d2. In the third DMA transfer, a transfer source address specifying the starting position of data d3 and a data length of 4 KB may be set in the DMAC 15. The transfer source address specifying the start position of data d3 is represented by the data pointer in the write command corresponding to data d3. In the fourth DMA transfer, a transfer source address specifying the starting position of data d4 and a data length of 4 KB may be set in the DMAC 15. The transfer source address specifying the start position of the data d4 is represented by the data pointer in the write command corresponding to the data d4.

Then, the controller 4 transfers this 16K byte write data (d1, d2, d3, d4) acquired by DMA transfer to the NAND flash memory 5 as data to be written to page P0 of write destination block BLK#1. do.
Controller 4 changes the next write destination page of write destination block BLK#1 to page P1, and combines data d3 having a size of 8 Kbytes and first 8 Kbyte data d6-1 in data d6 with each other. The 16 Kbyte write data obtained by this is acquired from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by, for example, two DMA transfers, although the present invention is not limited thereto. In the first DMA transfer, a transfer source address specifying the starting position of data d5 and a data length of 8 KB may be set in the DMAC 15. The transfer source address that specifies the starting position of the data d5 is represented by the data pointer in the write command corresponding to the data d5. In the second DMA transfer, a transfer source address specifying the start position of data d6-1 and a data length of 8 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data d6-1 is represented by the data pointer in the write command corresponding to data d6.

Then, the controller 4 transfers this 16 Kbyte write data (d5, d6-1) to the NAND flash memory 5 as data to be written to page P1 of write destination block BLK#1.
The controller 4 changes the next write destination page of the write destination block BLK#1 to page P2, and transfers the first 16 Kbyte data d6-2 of the remaining 32 Kbyte data of the data d6 to the write data buffer 51 of the host 2. Get from. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by one DMA transfer, for example, although the controller 4 is not limited thereto. In this DMA transfer, a transfer source address specifying the starting position of data d6-2 and a data length of 16 KB may be set in the DMAC 15. The transfer source address specifying the start position of data d6-2 can be obtained by adding an 8 KB offset to the value of the data pointer in the write command corresponding to data d6.

Then, the controller 4 transfers this 16 Kbyte write data (d6-2) to the NAND flash memory 5 as data to be written to page P2 of write destination block BLK#1.
The controller 4 changes the next write destination page of the write destination block BLK#1 to page P3, and acquires the remaining 16 Kbyte data d6-3 of the data d6 from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by one DMA transfer, for example, although the controller 4 is not limited thereto. In this DMA transfer, a transfer source address specifying the starting position of data d6-3 and a data length of 16 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data d6-3 can be obtained by adding an offset of 24 KB to the value of the data pointer in the write command corresponding to data d6.

Then, the controller 4 transfers this 16 Kbyte write data (d6-3) to the NAND flash memory 5 as data to be written to page P3 of write destination block BLK#1.
Then, the controller 4 writes four pages of data (P0 to P3) into the plurality of memory cells connected to the word line WL0 of the write destination block BLK#1 by a foggy write operation.

The controller 4 changes the next write destination page of the write destination block BLK#1 to page P4, and acquires data d7 having a size of 16 Kbytes from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by one DMA transfer, for example, although the controller 4 is not limited thereto. In this DMA transfer, a transfer source address specifying the starting position of data d7 and a data length of 16 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data 7 is represented by the data pointer in the write command corresponding to data d7.

Then, the controller 4 transfers this 16 Kbyte write data (d7) to the NAND flash memory 5 as data to be written to page P4 of write destination block BLK#1.
The controller 4 changes the next write destination page of the write destination block BLK#1 to page P5, and combines data d8 having a size of 8 Kbytes and data d9 having a size of 8 Kbytes with each other. 16 Kbyte write data is acquired from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by, for example, two DMA transfers, although the present invention is not limited thereto. In the first DMA transfer, a transfer source address specifying the starting position of data d8 and a data length of 8 KB may be set in the DMAC 15. The transfer source address that specifies the starting position of the data d8 is represented by the data pointer in the write command corresponding to the data d8. In the second DMA transfer, a transfer source address specifying the starting position of data d9 and a data length of 8 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data d9 is represented by the data pointer in the write command corresponding to data d9.

Then, the controller 4 transfers this 16 Kbyte write data (d8, d9) to the NAND flash memory 5 as data to be written to page P5 of write destination block BLK#1.
The controller 4 changes the next write destination page of the write destination block BLK#1 to page P6, and acquires the first 16K byte data d10-1 in the data d10 from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by one DMA transfer, for example, although the controller 4 is not limited thereto. In this DMA transfer, a transfer source address specifying the starting position of data d10-1 and a data length of 16 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data d10-1 is represented by the data pointer in the write command corresponding to data d10.

Then, the controller 4 transfers this 16 Kbyte write data (d10-1) to the NAND flash memory 5 as data to be written to page P6 of write destination block BLK#1.
The controller 4 changes the next write destination page of the write destination block BLK#1 to page P7, and acquires the next 16 Kbyte data d10-2 in the data d10 from the write data buffer 51 of the host 2. In this case, the controller 4 may transfer the 16 Kbyte write data from the write data buffer 51 of the host 2 to the internal buffer 31 by one DMA transfer, for example, although the controller 4 is not limited thereto. In this DMA transfer, a transfer source address specifying the starting position of data d10-2 and a data length of 16 KB may be set in the DMAC 15. The transfer source address specifying the starting position of data d10-2 can be obtained by adding an offset of 16 KB to the value of the data pointer in the write command corresponding to data d10.

Then, the controller 4 transfers this 16 Kbyte write data (d10-2) to the NAND flash memory 5 as data to be written to page P7 of write destination block BLK#1.
Then, the controller 4 writes four pages of data (P4 to P7) into the plurality of memory cells connected to the word line WL1 of the write destination block BLK#1 by a foggy write operation.

In this way, the controller 4 acquires 16 Kbyte data to be transferred to the write destination page of the write destination block BLK#1 from the host 2 in accordance with the progress of the write operation of the write destination block BLK#1.
Then, when the foggy write operation for the plurality of memory cells connected to the word line WL3 is completed, it becomes possible to execute the fine write operation for the plurality of memory cells connected to the word line WL0. The controller 4 changes the next write destination page of the write destination block BLK#1 to page P1, and transfers the write data (P0 to P3) page by page again to the NAND flash memory 5 using the same procedure as described above. Then, by a fine write operation, these four pages worth of write data (P0 to P3) are written to a plurality of memory cells connected to the word line WL0 of the write destination block BLK#1.

As a result, the first six write commands, that is, the write command corresponding to data d1, the write command corresponding to data d2, the write command corresponding to data d3, the write command corresponding to data d4, and the write command corresponding to data d5, are executed. , for each of the write commands corresponding to data d6, all foggy fine write operations for the entire write data associated with each write command are completed, and each of data d1 to d6 is read from the NAND flash memory 5. It becomes possible. Therefore, the controller 4 returns six command completion responses corresponding to the first six write commands to the host 2.

In addition, in FIG. 47, write data associated with each write command that specifies write destination block BLK#1 is transferred from the host 2 to the flash storage in units of 16 Kbytes as the write operation of write destination block BLK#1 progresses. Although the operation of transferring data to device 3 has been described, the same operation as that described with reference to FIG. 9 is performed for each of the other write destination blocks BLK#.

The flowchart in FIG. 48 shows the procedure of data write processing executed by the flash storage device 3. Here, the flash storage device 3 is realized as a type #2 storage device, and waits for the page address to which write data from the host 2 is scheduled to be written to the NAND flash memory 5 to finish. It is assumed that a mechanism is provided to notify the host 2 without any notification.

The controller 4 of the flash storage device 3 receives each write command from the host 2, each including a data pointer, length, and block identifier (eg, block address) (step B1).
Next, the controller 4 divides the large size write data corresponding to one write command specifying a specific write destination block into two or more data parts, or divides the large size write data corresponding to one write command specifying a specific write destination block, or divides the large size write data corresponding to one write command specifying this specific write destination block into two or more write commands specifying this specific write destination block. Two or more pieces of write data corresponding to are combined, and thereby data is transferred from the host 2 to the flash storage device 3 in units of the same size as the write unit (data transfer size) of the NAND flash memory 5 (step B2). In step B2, as explained in FIG. 47, for example, one 16K byte data is obtained by combining several write data portions having a small size, or by dividing write data having a large size. One of several 16K bytes of data obtained is transferred from the host 2 to the flash storage device 3. In the case where the flash storage device 3 includes an internal buffer 31, each 16-byte write data transferred from the host 2 to the flash storage device 3 is stored in the internal buffer 31. Further, in step B2, in order to combine several write data portions having small sizes, the controller 4 determines that the size of the write data associated with the preceding write command having an identifier specifying a certain write destination block is If it is smaller than the write unit (for example, 16 Kbytes), it waits for reception of a subsequent write command having an identifier specifying this write destination block.

Regarding the 16 Kbyte data transferred from the host 2, before writing the 16 Kbyte data to a specific write destination block, the controller 4 sends the address in the specific write destination block assigned to the write destination of the 16 Kbyte data to the host. 2 (step B3). Then, the controller 4 transfers the 16K byte data transferred from the host 2 to the NAND flash memory 5, and writes this 16K byte data to the address assigned to the write destination in this specific write destination block (step B4 ). The controller 4 determines whether or not this writing was successful (step B5), and in the case of an error (step B5: NO), repeats the process from step B3. In other words, notification of the address to the host 2 regarding the same data may occur multiple times. If successful (step B5: YES), proceed to step B6.

Then, the controller 4 performs a write operation (a write operation that involves transferring the same data one or more times to the NAND flash memory 5) for the entire write data associated with one write command that specifies this specific write destination block. (step B6).

When all write operations for the entire write data associated with one write command specifying this specific write destination block are completed, the controller 4 returns a response indicating completion of this write command to the host 2 ( Step B7). The timing of transmitting the releasable notification to the host 2 regarding the area on the write data buffer 51 where write data is stored will be described later.

The flowchart in FIG. 49 shows another procedure of the data write process executed by the flash storage device 3. Here, too, the flash storage device 3 is realized as a type #2 storage device, and waits for the page address to which write data from the host 2 is scheduled to be written to the NAND flash memory 5 to finish. It is assumed that a mechanism is provided to notify the host 2 without any notification.

The controller 4 of the flash storage device 3 receives each write command from the host 2, each including a data pointer, a length, and a block identifier (for example, a block address) (step B11).
Next, the controller 4 divides the large size write data corresponding to one write command specifying a specific write destination block into two or more data parts, or divides the large size write data corresponding to one write command specifying a specific write destination block, or divides the large size write data corresponding to one write command specifying this specific write destination block into two or more write commands specifying this specific write destination block. Two or more pieces of write data corresponding to are combined, and thereby data is transferred from the host 2 to the flash storage device 3 in units of the same size as the write unit (data transfer size) of the NAND flash memory 5 (step B12). In step B12, as explained in FIG. 47, for example, one 16K byte data is obtained by combining several write data portions having a small size, or by dividing write data having a large size. One of several 16K bytes of data obtained is transferred from the host 2 to the flash storage device 3. In the case where the flash storage device 3 includes an internal buffer 31, each 16-byte write data transferred from the host 2 to the flash storage device 3 is stored in the internal buffer 31. Further, in step B2, in order to combine several write data portions having small sizes, the controller 4 determines that the size of the write data associated with the preceding write command having an identifier specifying a certain write destination block is If it is smaller than the write unit (for example, 16 Kbytes), it waits for reception of a subsequent write command having an identifier specifying this write destination block.

The controller 4 transfers the 16 Kbyte data transferred from the host 2 to the NAND flash memory 5, and writes this 16 Kbyte data to this specific writing destination block (step B13).
The controller 4 determines whether or not this writing was successful (step B14), and in the case of an error (step B14: NO), repeats the process from step B13. If successful (step B14: YES), the process advances to step B15.

The controller 4 notifies the host 2 of the address in the specific write destination block assigned to the write destination of the 16 Kbyte data transferred from the host 2 (step B15).
Then, the controller 4 performs a write operation for the entire write data associated with one write command that specifies this specific write destination block (a write operation that involves transferring the same data to the NAND flash memory 5 once or multiple times). (step B16).

When all write operations for the entire write data associated with one write command specifying this specific write destination block are completed, the controller 4 returns a response indicating completion of this write command to the host 2 ( Step B17). The timing of transmitting the releasable notification to the host 2 regarding the area on the write data buffer 51 where write data is stored will be described later.

The flowchart in FIG. 50 shows the procedure of the process of transmitting a releasable notification to the host 2, which is executed by the flash storage device 3.
The controller 4 first determines whether all write operations for the entire write data associated with one write command specifying a specific write destination block have been completed (step C1). Second, the controller 4 determines whether or not there is a read command that targets this write data (step C2). Note that the processing in step C1 and the processing in step C2 are executed in parallel. Then, the controller 4 determines that all write operations for the entire write data associated with one write command specifying a specific write destination block have been completed (step C1: YES), and that the read operation for this write data is completed. If the command does not exist (step C2: NO), a releasable notification regarding the area on the write data buffer 51 in which this write data is stored is sent to the host 2 (step C3).

The flowchart in FIG. 51 shows the procedure of write data discard processing executed by the host 2.
The host 2 determines whether a response indicating completion of the write command has been received from the flash storage device 3 (step D1). When receiving a response from the flash storage device 3 indicating command completion for a certain write command (step D1: YES), the host 2 further receives a releasable notification regarding the write data associated with this write command from the flash storage device 3. It is determined whether or not it has been received (step D2). If a releasable notification regarding this write data is received from the flash storage device 3 (step D2: YES), the host 2 discards the write data associated with this write command from the write data buffer 51 (step D3).

FIG. 52 shows dummy data executed by the flash storage device 3 when the next write command that specifies a certain write destination block is not received for a threshold period after the last write command that specifies this write destination block is received. Shows write processing.

Data d1, data d2, data d3, and data d4 shown on the left side of FIG. 52 indicate four pieces of write data corresponding to each of four write commands specifying write destination block BLK#1. In FIG. 52, it is assumed that each of data d1, data d2, data d3, and data d4 has a size of 4 Kbytes.

(1) The controller 4 acquires 16 Kbyte write data obtained by combining data d1, data d2, data d3, and data d4 from the write data buffer 51 of the host 2. Then, the controller 4 transfers this 16 Kbyte write data to the NAND flash memory 5 as data to be written to page P0 of write destination block BLK#1. If a subsequent write command that specifies write destination block BLK#1 is not received for a threshold period after the last write command that specifies write destination block BLK#1, that is, the write command that requested writing of data d4, is received. , the controller 4 writes dummy data to one or more pages in the write destination block BLK#1 in order to make it possible to return a response indicating completion of the last write command to the host 2 within a predetermined time. The position of the write destination page in the write destination block BLK#1 to which the next write data is to be written is advanced. For example, the controller 4 transfers three pages worth of dummy data corresponding to pages P1 to P3 to the NAND flash memory 5 page by page, and transfers four pages worth of data (P0 to P3) to the write destination block by a foggy write operation. Write to a plurality of memory cells connected to word line WL0 of BLK#1.

(2) Next, the controller 4 transfers four pages worth of dummy data corresponding to pages P4 to P7 to the NAND flash memory 5 in page units, and writes the four pages worth of data (P4 to P7) by a foggy write operation. Write to a plurality of memory cells connected to word line WL1 of write destination block BLK#1.

(3) Next, the controller 4 transfers four pages worth of dummy data corresponding to pages P8 to P11 to the NAND flash memory 5 in page units, and writes the four pages worth of data (P8 to P11) by a foggy write operation. Write to a plurality of memory cells connected to word line WL2 of write destination block BLK#1.

(4) Next, the controller 4 transfers four pages worth of dummy data corresponding to pages P12 to P15 to the NAND flash memory 5 in page units, and writes the four pages worth of data (P12 to P15) by a foggy write operation. Write to a plurality of memory cells connected to word line WL3 of write destination block BLK#1.

(5) Next, the controller 4 transfers the 16K byte write data obtained by combining the data d1, data d2, data d3, and data d4 from the write data buffer 51 or the internal buffer 31 to the NAND flash memory 5. , Furthermore, the same three pages of dummy data (P0 to P3) used in the foggy write operation of WL0 are transferred to the NAND flash memory 5 in page units. Then, the controller 4 writes four pages worth of data (P0 to P3) into the plurality of memory cells connected to the word line WL0 of the write destination block BLK#1 by a fine write operation. As a result, the multiple stages of write operations for data d1, data d2, data d3, and data d4 are all completed, and data d1, data d2, data d3, and data d4 can be read from the NAND flash memory 5. The controller 4 sends a response indicating completion of the first write command that requested writing of data d1, a response indicating completion of the second write command requesting writing of data d2, and a response requesting writing of data d3. A response indicating completion of the third write command and a response indicating completion of the fourth write command that requested writing of data d4 are returned to the host 2.

In this embodiment, write data is transferred from the host 2 to the flash storage device 3 in units of the same data size as the data write unit of the NAND flash memory 5, and all write operations for the entire write data of a certain write command are completed. At this point, or when all write operations for the entire write data are completed and the entire write data becomes readable, a response indicating completion of the write command is returned to the host 2. For this reason, for example, after a write command is issued from the host 2 to the flash storage device 3 requesting to write small write data to a certain write destination block, subsequent write commands specifying this write destination block will not be executed for a while. If the host 2 does not issue the write command, a timeout error may occur for this write command. In this embodiment, if the next write command with this block identifier is not received for a threshold period after the last write command with this block identifier is received from the host 2, the controller 4 assigns dummy data to this block identifier. Write to the next one or more unwritten pages in the corresponding write destination block. Therefore, it is possible to proceed with the write operation of this write destination block as necessary, so that it is possible to prevent a write command timeout error from occurring.

The flowchart in FIG. 53 shows the procedure of dummy data write processing executed by the flash storage device 3. Here, it is assumed that data is written to a write destination block by a multi-step write operation such as a foggy fine write operation.

The controller 4 of the flash storage device 3 writes the write data associated with the last write command specifying a certain write destination block to this write destination block by a first stage write operation such as a foggy write operation. If the next write command that specifies this write destination block is not received within a threshold period (Th) from reception of this last write command (YES in step S31), the controller 4 writes the write data associated with the last write command. writes dummy data to one or more pages following the page in the write destination block to which the next write data is written, thereby advancing the position of the write destination page in this write destination block into which the next write data is to be written (step S32 ). By writing dummy data to the write destination block, the position of the write destination page advances, and when the fine write operation (second stage write operation) of the write data associated with the last write command can be executed, the controller 4 transfers the write data associated with the last write command from the write data buffer 51 or the internal buffer (shared cache) 31 to the NAND flash memory 5 again, and executes a fine write operation of this write data (step S33). ).

When the fine write operation of the write data associated with the last write command is completed, that is, when all the multiple stages of write operation of the entire write data are completed, the controller 4 sends a response indicating the command completion of this last write command. is returned to the host 2 (step S34).

In this way, in a case where write data is written to a write destination block by a multiple-step write operation, the controller 4 performs a write operation such that the second-step write operation of the write data associated with the last write command can be executed. , writes dummy data to one or more pages within this destination block, and advances the position of the destination page within this destination block into which the next write data is to be written.

FIG. 54 shows data transfer operations performed by controller 4 using internal buffer (shared cache) 31.
The internal buffer (shared cache) 31 is shared by a plurality of write destination blocks BLK#1, BLK#2, . . . , BLK#n. The controller 4 of the flash storage device 3 executes the following process for each write destination block BLK#1, BLK#2, . . . , BLK#n.

In the following, the write destination block BLK#1 will be explained as an example.
After the controller 4 receives one or more write commands specifying the write destination block BLK#1, the controller 4 writes multiple write data associated with one write command specifying the write destination block BLK#1. Write data having the same size as the write unit of the NAND flash memory 5, obtained by dividing into data or combining write data respectively associated with two or more write commands specifying the write destination block BLK#1 is obtained from the write data buffer 51. Then, the controller 4 stores a plurality of write data obtained from the write data buffer 51, each of which has the same size as the write unit of the NAND flash memory 5, in the internal buffer (shared cache) 31.

The write data buffer 51 does not necessarily need to be composed of one continuous area on the host memory, and as shown in FIG. 51-n.
The controller 4 acquires the write data (first write data) to be written next to the write destination block BLK#1 from the internal buffer (shared cache) 31, and transfers the first write data to the NAND flash memory 5. , this write data is written to the write destination block BLK#1 by a first stage write operation such as a foggy write operation.

In order to efficiently accumulate write data from the host 2 in the internal buffer (shared cache) 31, if there is no free space in the internal buffer (shared cache) 31 to store the write data acquired from the host 2. In this case, the controller 4 discards the write data (write data in the foggy state) in the internal buffer (shared cache) 31 for which the first stage write operation such as the foggy write operation has been completed, and frees up the free space. Reserved in the internal buffer (shared cache) 31.

For example, when receiving a new write command from the host 2 that specifies an arbitrary write destination block when there is no free space in the internal buffer (shared cache) 31, the controller 4 performs a first-stage write operation such as a foggy write operation. The write data (foggy state write data) in the internal buffer (shared cache) 31 for which the write operation has been completed is discarded, and the internal buffer ( (shared cache) 31.

For example, if a new write command is received from the host 2 while the entire internal buffer (shared cache) 31 is filled with write data in a large number of foggy states, the controller 4 Specific write data to be discarded may be selected from among them, and the selected write data may be discarded. Thereby, the internal buffer (shared cache) 31 having a limited capacity can be efficiently shared among multiple write destination blocks.

If the first write data does not exist in the internal buffer (shared cache) 31 at the time when a second stage write operation such as a fine write operation of the first write data is to be executed, the controller 4 writes the first write data. The write data is acquired again from the write data buffer 51 of the host 2 by transmitting a request (transfer request: DMA transfer request) to the host 2 to acquire the write data. This acquired first write data may be stored in the internal buffer (shared cache) 31. Then, the controller 4 transfers the acquired first write data to the NAND flash memory 5, and transfers this first write data to the write destination block BLK#1 by a second stage write operation such as a fine write operation. write to.

If the first write data exists in the internal buffer (shared cache) 31 at the time when a second stage write operation such as a fine write operation of the first write data is to be executed, the controller 4 The first write data is acquired from this internal buffer (shared cache) 31, the acquired first write data is transferred to the NAND flash memory 5, and the second stage write operation such as a fine write operation is performed. Write the first write data to the write destination block BLK#1.

After performing the final data transfer of the first write data to the NAND flash memory 5 (here, data transfer for a fine write operation), the controller 4 transfers the first write data to the internal buffer ( By discarding the data from the internal buffer (shared cache) 31, a free space is secured in the internal buffer (shared cache) 31. Alternatively, the controller 4 may discard the first write data from the internal buffer (shared cache) 31 when the fine write operation of the first write data is completed.

Further, the controller 4 reads out the entire write data from the NAND flash memory 5 when the fine write operation of the entire write data associated with a certain write command is completed, or when the fine write operation of the entire write data is completed and the entire write data is read out from the NAND flash memory 5. If it becomes possible, a response indicating completion of this write command is returned to the host 2.

The internal buffer (shared cache) 31 has a limited capacity, but if the number of write destination blocks is less than a certain number, the first block is used at the time when the second stage write operation is to be performed. The probability (hit rate) that write data exists in the internal buffer (shared cache) 31 is relatively high. Therefore, a multi-stage write operation such as a foggy fine write operation can be performed without transferring the same write data from the host 2 to the flash storage device 3 multiple times. As a result, data traffic between the host 2 and the flash storage device 3 can be reduced, so the flash storage device 3 I/O performance can be improved.

The number of write destination blocks may be the same as the number of clients using the host 2. In this case, data corresponding to one client is written to a write destination block corresponding to this client, and data corresponding to another client is written to another write destination block. Therefore, as the number of clients using the host 2 increases, the hit rate of the internal buffer (shared cache) 31 decreases. However, if the first write data does not exist in the internal buffer (shared cache) 31 (miss), the controller 4 acquires this first write data from the host 2. Therefore, even if the number of clients increases, multi-step write operations such as foggy fine write operations can be successfully performed.

Therefore, the flash storage device 3 can flexibly respond to an increase in the number of clients sharing the flash storage device 3 (that is, an increase in the number of write destination blocks that can be used simultaneously), and can also handle the It is possible to reduce data traffic between

Although the write process for writing data to the write destination block BLK#1 has been described here, the same write process is executed for each of all other write destination blocks.
The flowchart in FIG. 55 shows the procedure of data write processing executed by the controller 4 using the internal buffer (shared cache) 31.

The controller 4 receives from the host 2 one or more write commands, each of which includes a data pointer, the length of the write data, and an identifier (for example, a block address) that specifies one of a plurality of write destination blocks. (Step S101). After receiving one or more write commands having identifiers indicating the same write destination block, the controller 4 divides the write data associated with one write command among these write commands into multiple write data, or divides the write data associated with one of these write commands into multiple pieces of write data, or writes the same write data. Write data having the same size as the write unit of the NAND flash memory 5, which is obtained by combining write data respectively associated with two or more write commands having identifiers indicating the destination block, is transferred from the write data buffer 51. The data is transferred to the internal buffer (shared cache) 31 (step S102).

The controller 4 obtains the write data to be written next to this write destination block from the internal buffer (shared cache) 31, transfers this write data to the NAND flash memory 5, and writes this first write data by a foggy write operation. is written into this write destination block (steps S103, S104). If the NAND flash memory 5 is implemented as a QLC-flash, in step S103 the write data for four pages is transferred to the NAND flash memory 5 page by page, and in step S104 the write data for four pages is transferred to the NAND flash memory 5 in page units. Data is written by a foggy write operation to a plurality of memory cells connected to one word line to be written in this write destination block.

Note that the transfer of write data from the write data buffer 51 to the internal buffer (shared cache) 31 is executed in accordance with the progress of the write operation of each write destination block. For example, when the operation of transferring write data to be written to a certain page of a certain write destination block to a NAND flash memory chip is completed, the write data to be written to the next page of this write destination block is transferred from the write data buffer 51 to the internal memory. It may be transferred to the buffer (shared cache) 31. Alternatively, when the operation of transferring write data to be written to a certain page of a certain write destination block to the NAND flash memory chip that includes this write destination block is completed, and the operation of writing this write data to this write destination block is completed. Additionally, write data to be written to the next page of this write destination block may be transferred from the write data buffer 51 to the internal buffer (shared cache) 31.

At the time when a fine write operation should be started for the write data that has been subjected to the foggy write operation, the controller 4 determines whether this write data exists in the internal buffer (shared cache) 31 or not.
If this write data exists in the internal buffer (shared cache) 31 (YES in step S106), the controller 4 acquires this write data from the internal buffer (shared cache) 31 and transfers this write data to the NAND flash memory. 5, and this write data is written to this write destination block by a fine write operation (steps S107, S108, S109). Thereby, this write data can be read from the NAND flash memory 5.

For each write command, the controller 4 determines whether the foggy fine write operation of the entire write data has been completed and whether the entire write data can be read from the NAND flash memory 5. Then, the controller 4 returns a response to the host 2 indicating completion of the write command corresponding to the write data that has completed the foggy/fine write operation and is now readable from the NAND flash memory 5 (step S110). If the fine write operation of the entire write data associated with a certain write command is completed by the process in step S109, a response indicating completion of this write command may be returned to the host 2 in step S110.

The flowchart in FIG. 56 shows the procedure of data read processing executed by the controller 4. Here, when the flash storage device 3 receives a read command from the host 2 that targets data in the write data existing in the write data buffer 51 of the host 2, the flash storage device 3 receives the data from the host 2 until the read command is completed. It is assumed that a mechanism is provided to prevent the host 2 from sending a releasable notification regarding the area where the storage area is stored.

As described above, the controller 4 performs all write operations (write operations in which the same data is transferred one or more times to the NAND flash memory 5) of the data specified by the read command received from the host 2. If the data is unfinished data, or data for which all write operations have been completed but is not yet readable from the NAND flash memory 5, check whether this data exists in the internal buffer (shared cache) 31. Determine whether or not. If this data does not exist in the internal buffer (shared cache) 31, the controller 4 obtains this data from the write data buffer 51, stores this data in the internal buffer (shared cache) 31, and stores this data in the internal buffer ( shared cache) 31 to the host 2.

Specifically, the following data read processing is executed.
When the controller 4 receives a read command from the host 2 (step E1: YES), the controller 4 reads out the data specified by this read command from the NAND flash memory 5 after all of its write operations have been completed. It is determined whether the data is possible (step E2).

If this data can be read from the NAND flash memory 5 (step E2: YES), the controller 4 reads this data from the NAND flash memory 5 and returns the read data to the host 2 (step E3). ). In step E3, the controller 4 transfers this read data to the position in the read data buffer 53 specified by the data pointer included in the read command.

If this data is not readable from the NAND flash memory 5 (step E2: NO), the controller 4 first sends a releasable notification to the host 2 so that the data on the write data buffer 51 is not discarded. It is set to a prohibited state (step E5). The controller 4 then determines whether this data exists in the internal buffer (shared cache) 31 (step E5).

If this data exists in the internal buffer (shared cache) 31 (step E5: YES), the controller 4 reads this data from the internal buffer (shared cache) 31 and returns the read data to the host 2 (step E5: YES). E6).
In step E6, the controller 4 transfers this read data to the position in the read data buffer 53 specified by the data pointer included in the read command.

If this data does not exist in the internal buffer (shared cache) 31 (step E5: NO), the controller 4 acquires this data from the write data buffer 51 and stores it in the internal buffer (shared cache) 31 (step E7). ). In step E7, the DMAC 15 transfers this data from the write data buffer 51 to the free area of the internal buffer (shared cache) 31. If there is no free space in the internal buffer (shared cache) 31, a process for securing a free space in the internal buffer (shared cache) 31 is executed. Then, the controller 4 reads this data from the internal buffer (shared cache) 31 and returns this read data to the host 2 (step E6). In step E6, the controller 4 transfers the read data to the position in the read data buffer 53 specified by the data pointer included in the read command. Then, the controller 4 cancels the state set in step E4 in which transmission of the releasable notification to the host 2 is prohibited (step E8).

FIG. 57 shows a block reuse command applied to the flash storage device 3.
The block reuse command is a command (block release request) that requests the flash storage device 3 to return an allocated block that is no longer needed because it stores only invalid or unnecessary data to a free block. ). The block reuse command includes a QoS domain ID that specifies a QoS domain, and a block address that specifies a block to be made into a free block (released).

Further, FIG. 58 shows another example of a write command applied to the flash storage device 3. Specifically, the write command shown in FIG. 8 is applied when the flash storage device 3 is realized as a type #1 storage device, whereas the write command shown in FIG. , is applied when the flash storage device 3 is realized as a type #2-storage device. Hatching in FIG. 58 indicates differences from FIG. 8.

The write command is a command that requests the flash storage device 3 to write data. This write command may include a command ID, QoS domain ID, logical address, length, etc.
The command ID is an ID (command code) indicating that this command is a write command, and the write command includes a command ID for a write command.

The QoS domain ID is an identifier that can uniquely identify the QoS domain in which data is to be written. A write command sent from the host 2 in response to a write request from a certain end user may include a QoS domain ID that specifies a QoS domain corresponding to this end user. A namespace ID may be treated as a QoS domain ID.

The logical address is an identifier for identifying write data to be written. This logical address may be an LBA or a key of a key-value store, as described above. If the logical address is an LBA, the logical address (starting LBA) included in this write command indicates the logical position (first logical position) where write data is to be written.

The length indicates the length of write data to be written. This length (data length) may be specified by the number of grains, the number of LBAs, or the size may be specified by bytes.
As described above, the controller 4 groups a large number of blocks in the NAND flash memory 5 into a plurality of groups (multiple QoS domains) so that each of the large number of blocks in the NAND flash memory 5 belongs to only one group. It can be classified into The controller 4 can manage a free block list (free block pool) and an active block list (active block pool) for each group (QoS domain).

The state of each block is roughly divided into active blocks that store valid data and free blocks that do not store valid data. Each block that is an active block is managed by an active block list. On the other hand, each block that is a free block is managed by a free block list.

When receiving a write command from the host 2, the controller 4 determines the block (write destination block) into which data from the host 2 is to be written and the position within this write destination block (write destination position). The controller 4 may determine one of the free block groups belonging to the QoS domain corresponding to the QoS domain ID as the write destination block. The write destination position is determined in consideration of page write order constraints, bad pages, and the like. Then, the controller 4 writes the data from the host 2 to the write destination position in the write destination block.

Note that once this write destination block is entirely filled with user data, the controller 4 moves this write destination block to the active block list (active block pool). Then, the controller 4 again selects a free block from the free block list corresponding to this QoS domain, and assigns this selected free block as a new writing destination block.

If the number of remaining free blocks managed by the free block list falls below a threshold determined by a predetermined policy, or if there is an instruction from the host 2 to perform garbage collection, the controller 4 Garbage collection may begin.

In garbage collection of this QoS domain, the controller 4 selects a copy source block (GC source block) and a copy destination block (GC destination block) from the active block group corresponding to this QoS domain. Which block to select as a GC candidate (copy source block) may be determined according to the above-mentioned policy specified by the host 2, or may be specified by the host 2. When a policy is also based, for example, a block with the smallest amount of effective data may be selected as a GC candidate (copy source block).

FIG. 59 shows a response to the write command of FIG. 58. Note that hatching in FIG. 59 also indicates differences from FIG. 9.
This response includes a logical address, physical address, and length.
The logical address is the logical address included in the write command in FIG.

The physical address indicates a physical storage location within the NAND flash memory 5 where data is written in response to the write command shown in FIG. In this embodiment, this physical address is specified not by a combination of a block number and a page number, but by a combination of a block number and an offset (intra-block offset), as described above. The block number is an identifier that can uniquely identify any one of all blocks within the flash storage device 3. If all blocks are assigned different block numbers, these block numbers may be used directly. Alternatively, the block number may be expressed by a combination of a die number and an intra-die block number. The length indicates the length of write data to be written. This length (data length) may be specified by the number of grains, the number of LBAs, or the size may be specified by bytes.

FIG. 60 shows another example of the write operation processing sequence executed by the host 2 and the flash storage device 3. Specifically, the sequence shown in FIG. 25 is for the case where the flash storage device 3 is implemented as a type #1 storage device, whereas the sequence shown in FIG. is implemented as a type #2 storage device.

The host 2 sends a write command including the QoS domain ID, LBA, and length to the flash storage device 3. When the controller 4 of the flash storage device 3 receives this write command, the controller 4 determines the write destination block to which the write data from the host 2 is to be written and the position within this write destination block. More specifically, the controller 4 selects one free block from the free block list and assigns the selected free block as a write destination block (step S11). That is, the selected free block and the first available page within the selected free block are determined as the write destination block and the position within this write destination block into which the write data from the host 2 is to be written. If the write destination block has already been allocated, there is no need to execute the write destination block allocation process in step 12. The next available page within the already allocated write destination block is determined as the location within the write destination block to which the write data from the host 2 is to be written.

The controller 4 may manage multiple free block lists corresponding to multiple QoS domains. In a free block list corresponding to a certain QoS domain, only blocks reserved for this QoS domain may be registered. In this case, in step S12, the controller 4 selects a free block list corresponding to the QoS domain specified by the QoS domain ID of the write command, selects one free block from this selected free block list, and selects one free block from the selected free block list. The free block that has been created may be assigned as the write destination block. This can prevent data corresponding to different QoS domains from being mixed in the same block.

The controller 4 writes the write data received from the host 2 to the write destination block (step S12). In step S12, the controller 4 writes both the logical address (here, LBA) and write data to the write destination block.
The controller 4 updates the block management table 32 and changes the bitmap flag corresponding to the written data (that is, the bitmap flag corresponding to the physical address of the physical storage location where this data is written) from 0 to 1. change (step S13). For example, as shown in FIG. 26, assume that 16 Kbyte update data whose starting LBA is LBAx is written to physical storage locations corresponding to offsets +4 to +7 of block BLK#1. In this case, as shown in FIG. 27, in the block management table for block BLK#1, each of the bitmap flags corresponding to offsets +4 to +7 is changed from 0 to 1.

The controller 4 returns a response to this write command to the host 2 (step S14). For example, as shown in FIG. 26, if 16K byte update data whose starting LBA is LBAx is written to physical storage locations corresponding to offsets +4 to +7 of block BLK#1, then LBAx, block number ( =BLK1), an offset (=+4), and a length (=4) are sent from the controller 4 to the host 2.

When the host 2 receives this response, the host 2 updates the LUT managed by the host 2 and maps a physical address to each logical address corresponding to the written write data. As shown in FIG. 28, the LUT includes multiple entries corresponding to multiple logical addresses (eg, LBAs). An entry corresponding to a certain logical address (for example, a certain LBA) contains a physical address PBA indicating the position (physical storage position) in the NAND flash memory 5 where the data corresponding to this LBA is stored, that is, the block number and offset. (intra-block offset) is stored. As shown in FIG. 26, if the 16K byte update data whose starting LBA is LBAx is written to the physical storage locations corresponding to offsets +4 to +7 of block BLK#1, as shown in FIG. The LUT is updated, BLK#1, offset +4 is stored in the entry corresponding to LBAx, BLK#1, offset +5 is stored in the entry corresponding to LBAx+1, and BLK#1 is stored in the entry corresponding to LBAx+2. , offset +6 are stored, and BLK#1 and offset +7 are stored in the entry corresponding to LBAx+3.

Thereafter, the host 2 sends a Trim command to the flash storage device 3 to invalidate previous data that is no longer needed due to writing of the update data described above (step S21). As shown in FIG. 26, if the previous data is stored in the positions corresponding to offset +0, offset +1, offset +2, and offset +3 of block BLK#0, as shown in FIG. A Trim command specifying the block number (=BLK#0), offset (=+0), and length (=4) is sent from the host 2 to the flash storage device 3. The controller 4 of the flash storage device 3 updates the block management table 32 in response to this Trim command (step S15). In step S15, as shown in FIG. 29, in the block management table for block BLK#0, each of the bitmap flags corresponding to offsets +0 to +3 is changed from 1 to 0.

FIG. 61 shows another example of the GC control command applied to the flash storage device 3. Specifically, while the GC control command shown in FIG. 34 is applied when the flash storage device 3 is realized as a type #1 storage device, the GC control command shown in FIG. The command applies in the case where the flash storage device 3 is implemented as a type #2-storage device. Hatching in FIG. 61 indicates differences from FIG. 34.

The GC control command may include a command ID, policy, source QoS domain ID, destination QoS domain ID, etc.
The command ID is an ID (command code) indicating that this command is a GC control command, and the GC control command includes a command ID for the GC control command.

The policy is a parameter that specifies conditions (GC policy) for selecting a GC candidate block (GC source block). The controller 4 of the flash storage device 3 supports multiple GC policies.
The GC policy supported by the controller 4 may include a policy (Greedy) that preferentially selects a block with a small amount of effective data as a GC candidate block (GC source block).

In addition, the GC policy supported by the controller 4 includes a block where data with a low update frequency (cold data) is collected than a block where data with a high update frequency (hot data) is collected. A policy of preferentially selecting the block as a GC candidate block (GC source block) may be included.

Additionally, the GC policy may specify GC initiation conditions. The GC start condition may indicate, for example, the number of remaining free blocks.
The controller 4 manages blocks containing valid data using an active block list, and when executing GC, blocks managed by the active block list are managed based on a GC policy specified by a GC control command. Select one or more GC candidate blocks (GC source blocks) from the group.

The QoS domain ID is a parameter that specifies the QoS domain in which GC should be performed. The controller 4 selects one or more GC candidate blocks (GC source blocks) from a group of blocks belonging to the QoS domain specified by the QoS domain ID, that is, from the active block list corresponding to this QoS domain. Further, the controller 4 selects one or more free blocks within the free block group belonging to the QoS domain specified by the QoS domain ID as the GC destination block.

The controller 4 may start GC when the number of remaining free blocks corresponding to a QoS domain becomes less than or equal to a threshold specified by a policy. If the controller 4 receives a GC control command that includes a policy specifying forced execution of GC, the controller 4 may immediately start GC upon receiving this GC control command from the host 2 .

FIG. 62 shows another example of a garbage collection (GC) operation procedure. Specifically, whereas the procedure shown in FIG. 36 is for the case where the flash storage device 3 is implemented as a type #1 storage device, the procedure shown in FIG. is implemented as a type #2 storage device. Hatching in FIG. 62 indicates differences from FIG. 36.

Based on the policy specified by the host 2, the controller 4 of the flash storage device 3 selects one or more GC sources containing a mixture of valid data and invalid data from a group of blocks belonging to the QoS domain specified by the QoS domain ID. A block (copy source block) is selected (step S41). Next, the controller 4 selects one or more free blocks from the free block group belonging to the QoS domain specified by the QoS domain ID, and assigns the selected free block as a GC destination block (copy destination block) (step S42 ).

The controller 4 copies all valid data in the GC source block (copy source block) to the GC destination block (copy destination block) (step S44). In step S44, the controller 4 transfers not only the valid data in the GC source block (copy source block) but also both this valid data and the logical address corresponding to this valid data from the GC source block (copy source block). Copy to the destination block (copy destination block). Thereby, a pair of data and a logical address can be held in the GC destination block (copy destination block).

The controller 4 then uses the logical address of the copied valid data and the destination physical address (block number, offset (internal offset )) is notified to the host 2 using the GC callback command (step S44). Note that in step S44, the controller 4 may notify the host 2 not only of the logical address and destination physical address of the copied valid data but also of the source physical address.

When the host 2 receives this GC callback command, the host 2 updates the LUT managed by the host 2 and maps the destination physical address to each logical address corresponding to the copied valid data. (Step S51).

The flowcharts in FIGS. 63 and 64 show a case where the flash storage device 3 is equipped with a mechanism to separate blocks into blocks for writing data from the host 2 and blocks for copying data in the flash storage device 3. The following shows the procedure for allocating free blocks.

The procedure shown in FIG. 63 is the free block allocation procedure in step S11 (write destination block allocation) in the write operation process sequence shown in FIG. 60.
The controller 4 of the flash storage device 3 determines whether a block (write destination block) for writing write data from the host 2 is allocated (step F1). Even if a block containing a free page is allocated, if that block is a block for copying data in the flash storage device 3, the controller 4 will not be able to write the write data from the host 2. It is determined that the block is not allocated. This determination is performed based on, for example, attribute information that is held as block metadata and indicates the use of the block.

If it is determined that a block for writing write data from the host 2 is not allocated (step F1: NO), the controller 4 assigns a free block group shared between QoS domains within the same virtual storage device, for example. One of the free blocks is allocated as a block for writing write data from the host 2 (step F2). At this time, the controller 4 records attribute information indicating that the block is a block for writing write data from the host 2 as metadata of this block.

On the other hand, the procedure shown in FIG. 64 is the free block allocation procedure in step S42 (GC destination block allocation) in the garbage collection (GC) operation procedure shown in FIG. 62.
The controller 4 of the flash storage device 3 creates a block (GC destination block) for copying valid data in a GC source block (copy source block), that is, a block for copying data in the flash storage device 3. It is determined whether it has been assigned (step F11). Even if a block containing a free page is allocated, if that block is for writing write data from the host 2, the controller 4 will copy the data in the flash storage device 3. It is determined that the block is not allocated.

If it is determined that a block for copying data in the flash storage device 3 is not allocated (step F11: NO), the controller 4 assigns a free block shared between QoS domains in the same virtual storage device, for example. One free block in the group is allocated as a block for copying data in the flash storage device 3 (step F12). At this time, the controller 4 records attribute information indicating that the block is a block for copying data in the flash storage device 3 as metadata of this block.

As described above, according to the flash storage device 3 of this embodiment, it is possible to improve I/O performance.
Although several embodiments of the invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included within the scope and gist of the invention, as well as within the scope of the invention described in the claims and its equivalents.

2... Host, 3... Flash storage device, 4... Controller, 5... NAND flash memory, 21... Write operation control section, 22... Read operation control section, 23... GC operation control section.

Claims (10)

A memory system connectable to a host,
non-volatile memory containing multiple blocks;
a controller electrically connected to the nonvolatile memory and controlling the nonvolatile memory;
The controller includes:
When receiving a write command from the host that specifies a location in the host's memory where write data to be written exists, acquiring the write data from the host's memory and writing it to the nonvolatile memory;
When a read command that targets the write data on the memory of the host is received from the host, controlling notification to the host regarding the write command so that the write data on the memory of the host is not discarded;
A memory system that is configured as follows. The controller is configured to send a notification to the host to permit the discarding of the write data on the host's memory after a read command that targets the write data on the host's memory is completed. The memory system according to claim 1. The controller is configured to read data from the host's memory when readable data targeted by a read command received from the host exists in both the host's memory and the nonvolatile memory. 3. The memory system according to claim 1, wherein: The controller is configured to read data from the non-volatile memory when readable data targeted by a read command received from the host exists both in the memory of the host and in the non-volatile memory. The memory system according to claim 1 or 2. The controller includes:
managing a counter indicating the remaining number of data write processes for the write data on the memory of the host in units of data usage by the host;
As the initial value of each counter, a value obtained by adding 1 to the number of data transfers required to write data to the nonvolatile memory is set, and a corresponding value is set each time data is transferred to the nonvolatile memory. Decrease the value of the counter by 1,
When it is determined that the transferred data has been written to the non-volatile memory and rewriting processing is no longer necessary when an error is detected, the value of the corresponding counter is further subtracted by 1;
If the value of the counter becomes 0, transmitting a notification to the host to permit the destruction of the write data on the memory of the host;
The memory system according to claim 1 or 2, configured as follows. When the controller receives a read command from the host that targets the write data on the memory of the host, the controller adds 1 to the value of a counter corresponding to the data, and when the read process is completed, the controller performs the corresponding command. 6. The memory system according to claim 5, wherein the memory system is configured to decrement the value of the counter by one. A memory system connectable to a host,
a non-volatile memory including a plurality of blocks each including a plurality of pages;
a controller electrically connected to the nonvolatile memory and controlling the nonvolatile memory;
The controller is configured to manage the plurality of blocks so that pages for writing data from the host and pages for copying data in the memory system do not coexist in one block. The controller includes:
managing a group of free blocks within the plurality of blocks;
holding blocks allocated from the free block group for writing data from the host and blocks allocated from the free block group for copying data in the memory system, respectively;
The memory system according to claim 7, configured as follows. The controller manages each of a plurality of areas obtained by logically dividing the nonvolatile memory, acquires one free block from the free block group, and divides the acquired free block into the plurality of areas. When allocating to any of the areas, attribute information indicating that the block is a block for writing data from the host, or attribute information indicating that the block is a block for copying data in the memory system. 9. The memory system according to claim 8, wherein the memory system is configured to record attribute information indicating the attribute. When writing data from the host in each of the plurality of areas, the controller writes to a block in which the attribute information indicates that the block is for writing data from the host, and writes the data in the memory system. 10. The memory system according to claim 9, wherein when copying the data, the attribute information is configured to copy to a block indicating that the block is a block for copying data in the memory system.

Images