JP7167291B2 - Memory system and control method - Google Patents

Description

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

In recent years, memory systems with nonvolatile memories have become widespread. As one of such memory systems, a solid state drive (SSD) based on NAND flash technology is known.

SSDs are also used as storage devices in servers in data centers.

High I/O performance is required for storage devices used in host computer systems such as servers.

For this reason, recently, new interfaces between hosts and storage devices have begun to be proposed.

Also, modern storage devices may be required to allow different types of data to be written to different destination blocks.

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

However, when the number of write destination blocks that can be used at the same time increases, it becomes necessary to increase the number of write buffers required for temporarily storing write data to be written to each write destination block. Because the amount of random access memory in a storage device is typically limited, it can be difficult for the storage device to provide a sufficient number of write buffers. As a result, in practice, the number of write destination blocks that can be used simultaneously is limited.

The problem to be solved by the present invention is to provide a memory system and control method that can increase the number of write destination blocks that can be used simultaneously.

According to an embodiment, a memory system connectable to a host includes a non-volatile memory including a plurality of blocks, a controller electrically connected to the non-volatile memory and configured to control the non-volatile memory. Equipped with The controller receives from the host a write request including storage location information indicating a location in a write buffer on memory of the host where first data to be written is stored, and writes the first data to a plurality of When writing to the non-volatile memory by the step program operation, the first data is transferred to the host by transmitting a transfer request including the storage location information to the host for each program operation of the plurality of step program operations. Retrieve from the write buffer, transfer the first data to the non-volatile memory, and write the first data to a destination block of the plurality of blocks.

3 is a block diagram showing the relationship between the host and memory system (flash storage device); FIG. FIG. 2 is a block diagram showing a configuration example of a flash storage device; 2 is a block diagram showing the relationship between multiple channels and multiple NAND flash memory chips used in a flash storage device; FIG. FIG. 2 is a diagram showing an example configuration of a superblock used in a flash storage device; FIG. FIG. 4 is a diagram showing the relationship between multiple write destination blocks corresponding to multiple end users and multiple write buffer areas; FIG. 3 is a block diagram for explaining the relationship between the flash storage device and UWB on the host side, and data write processing executed by the host and the flash storage device; FIG. 4 is a diagram showing an example of the relationship between a plurality of write destination blocks and a plurality of write buffer areas (UWB areas); FIG. 3 is a block diagram for explaining the relationship between the flash storage device and UWB on the host side, and the data read processing executed by the host and the flash storage device; FIG. 4 is a block diagram for explaining the relationship between a flash storage device that supports foggy fine writing and UWB on the host side, and data write processing performed by the host and the flash storage device; FIG. 3 is a block diagram for explaining the relationship between a flash storage device that supports foggy fine writing and UWB on the host side, and data read processing performed by the host and the flash storage device; FIG. 3 is a sequence diagram showing the procedure of data write processing executed by the host and the flash storage device; 4 is a flowchart showing the procedure of notification processing executed by the flash storage device; 4 is a flowchart showing the procedure of host-side processing executed in response to reception of a transfer request; 4 is a flow chart showing the procedure of a data read operation performed by the flash storage device in response to receiving a read request; 4 is a flowchart showing the procedure of host-side processing for reading data; FIG. 4 is a block diagram for explaining the relationship between a flash storage device that supports stream writing and UWB on the host side, and data write processing executed by the host and the flash storage device; FIG. 4 is a diagram showing the relationship between multiple stream IDs and multiple write destination blocks associated with these stream IDs. FIG. 4 is a block diagram for explaining the relationship between a flash storage device that supports stream writing and UWB on the host side, and data read processing executed by the host and the flash storage device; FIG. 4 is a sequence diagram showing the steps of a data write process performed by a flash storage device supporting foggy fine write and a host; 4 is a block diagram showing a configuration example of a host; FIG. 4 is a flowchart showing the procedure of data write processing executed by a processor (CPU) within the host; 4 is a flowchart showing the procedure of data read processing executed by a processor in the host; 4 is a flowchart showing another procedure of data read processing executed by a processor in the host; 4 is a flowchart showing the procedure of UWB area release processing executed by a processor in the host;

Embodiments will be described below with reference to the drawings.

First, the relationship between the host and the memory system will be described with reference to FIG.

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

A host (host device) 2 is configured to control a plurality of flash storage devices 3 . The host 2 is realized by an information processing device configured to use a flash array composed of a plurality of flash storage devices 3 as storage. This information processing device may be a personal computer or a server computer.

Note that the flash storage device 3 may be used as one of a plurality of storage devices provided within the storage array. The storage array may be connected to an information processing device such as a server computer via a cable or network. including. When the flash storage device 3 is applied to a storage array, the controller of this storage array may serve as the host for the flash storage device 3 .

A case where an information processing apparatus such as a server computer functions as the host 2 will be described below as an example.

A host (server) 2 and multiple flash storage devices 3 are interconnected via an interface 50 (internal interconnect). The interface 50 for this interconnection may be, but is not limited to, PCI Express (PCIe) (registered trademark), NVM Express (NVMe) (registered trademark), Ethernet (registered trademark), NVMe over Fabrics (NVMeOF), etc. can be used.

A typical example of a server computer functioning as the host 2 is a server computer (hereinafter referred to as a server) in a data center.

In the case where the host 2 is implemented by a server in a data center, this host (server) 2 may be connected to multiple end-user terminals (clients) 61 via a 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) a platform as a service (PaaS) that provides a system operating platform to each client (each end-user terminal 61), (2) a virtual server and infrastructure as a service (IaaS) that provides each client (each end-user terminal 61) with such an infrastructure.

A plurality of virtual machines may run on the physical server that functions as this host (server) 2 . Each of these virtual machines running on the host (server) 2 can function as a virtual server configured to provide various services to a corresponding number of clients (end-user terminals 61).

The host (server) 2 includes a storage management function that manages a plurality of flash storage devices 3 that make up a flash array, and a front-end function that provides various services including storage access to each end user terminal 61. .

The flash storage device 3 includes non-volatile memory such as NAND flash memory. One flash storage device 3 manages multiple write destination blocks allocated from multiple blocks in the nonvolatile memory. A write destination block means a block to which data is to be written. A write request (write command) sent from the host 2 to the flash storage device 3 includes an identifier associated with one write destination block to which data is to be written. Based on this identifier included in this write request, the flash storage device 3 determines one write destination block to which this data is to be written from a plurality of write destination blocks.

The identifier included in this write request may be a block identifier specifying a specific write destination block. A block identifier may be represented by a block address (block number). Alternatively, in the case where the flash storage device 3 includes multiple NAND flash memory chips, the block identifier may be represented by a combination of block address (block number) and chip number.

In the case where the flash storage device 3 supports stream writing, the identifier included in this write request may be the identifier of one stream (stream ID) among multiple streams. In stream writing, multiple write destination blocks are associated with multiple streams, respectively. In other words, when the flash storage device 3 receives a write request containing a certain stream ID from the host 2, this flash storage device 3 writes the data to the destination block associated with the stream corresponding to this stream ID. When the flash storage device 3 receives a write request containing another stream ID from the host 2, this flash storage device 3 writes data to another write destination block associated with another stream corresponding to this another stream ID. write.

Multiple write destination blocks managed by the flash storage device 3 may be used by multiple end users (clients) sharing this flash storage device 3 . In this case, in the flash storage device 3, as many write destination blocks as or more than the number of end users who share the flash storage device 3 are opened.

Thus, in an environment where a plurality of write destination blocks that can be used simultaneously exist in the flash storage device 3, it is necessary to prepare the same number of write buffers as the number of these write destination blocks.

This is because most of the recent NAND flash memories are configured to write multiple bits of data per memory cell, and each write destination block holds multiple pages of data to be written to this write destination block. This is because it is necessary to keep

In addition, in recent NAND flash memories, in order to reduce program disturb, write data is written into the NAND flash memory through a multi-stage program operation that involves transferring the write data to the NAND flash memory multiple times. There are cases where the write method is applied. A typical example of such a write method is the foggy fine program operation. Even in this case, it is necessary to hold the write data until the program operation in multiple stages is completed, so it is necessary to prepare the same number of write buffers as the number of write destination blocks.

In the foggy fine program operation, for example, first write data for multiple pages is transferred to the NAND flash memory, and the first write data is transferred to the first physical page (memory cells connected to a certain word line). ) (First stage write: Foggy write). After that, foggy write is performed to another physical page (memory cell group connected to another word line) adjacent to the first physical page. Then, the above-described first write data for multiple pages is transferred to the NAND flash memory again, and this first write data is written in the first physical page (second stage writing: fine writing). After this, the fine write to another physical page as described above is performed.

However, since the random access memory capacity within the flash storage device 3 is limited, it may be difficult to provide a sufficient number of write buffers on the random access memory within the flash storage device 3 . Also, even if a large capacity random access memory is provided in the flash storage device 3, if the number of end users sharing the flash storage device 3 is small, the large capacity random access memory will be wasted. .

Therefore, in this embodiment, a predetermined storage area on the memory of the host 2 is used as a write buffer (hereinafter referred to as UWB: Unified Write Buffer) 2A. The UWB 2A on the host 2 side includes multiple write buffer areas corresponding to multiple write destination blocks.

The host 2 stores write data to be written to one write destination block in the UWB 2A (write buffer area corresponding to this write destination block). Then, the host 2 flushes a write request including an identifier (block identifier or stream ID) associated with this one write destination block and storage location information indicating the location within the UWB 2A where this write data is stored. Send to the storage device 3 .

The flash storage device 3 receives this write request from the host 2 and holds the identifier and storage location information. When writing this write data to the NAND flash memory, the flash storage device 3 acquires the above write data from the UWB 2A by sending a transfer request including the above storage location information to the host 2 . For example, if the NAND flash memory is a TLC (triple level cell) flash memory that stores 3-bit data per memory cell, write data for 3 pages to be written to the same physical page is UWB2A. obtained from Three page addresses may be assigned to one physical page. Then, the flash storage device 3 writes this write data to one write destination block (physical page containing this write destination block).

The flash storage device 3 may write this write data to one write destination block by a full sequence program operation.

Alternatively, the flash storage device 3 stores the write data (for example, 3 pages worth of write data) by a multi-step program operation (for example, foggy fine program operation) that involves transferring the write data to the NAND flash memory multiple times. may be written to a single destination block. In this case, the flash storage device 3 first executes the first stage write operation. After that, when the timing for executing the second-stage write operation comes, the flash storage device 3 sends the transfer request including the above-described storage location information to the host 2 again. The host 2 transfers this write data from the UWB 2A to the flash storage device 3 each time it receives a transfer request including the storage location information described above from the flash storage device 3 . When the above write data is obtained again from the UWB 2A, the flash storage device 3 executes the second stage write operation.

When the writing of this write data is finished and this write data can be read from the NAND flash memory (in the full sequence program operation, when the full sequence program operation is finished, the flash storage device 3 When both the foggy write operation and the fine write operation are finished in the foggy fine program operation), the host 2 is notified that the write data held in the UWB 2A is no longer needed.

Therefore, in this embodiment, it is possible to simultaneously use a large number of write destination blocks without preparing a large number of write buffers in the flash storage device 3 . Therefore, since there is no need to provide a large-capacity random access memory in the flash storage device 3, it is possible to easily increase the number of end users who share the flash storage device 3 without increasing the cost of the flash storage device 3. becomes.

FIG. 2 shows a configuration example of the flash storage device 3 .

The flash storage device 3 has a controller 4 and a nonvolatile memory (NAND type flash memory) 5 . Flash storage device 3 may also comprise 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.

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

The controller 4 is electrically connected to a NAND flash memory 5, which is a non-volatile memory, via a flash programming controller 13 such as Toggle, an open NAND flash interface (ONFI). Controller 4 operates as a memory controller configured to control NAND flash memory 5 . This controller 4 may be implemented by a circuit such as a System-on-a-chip (SoC).

The NAND flash memory 5 may include a plurality of NAND flash memory chips (NAND flash memory dies), as shown in FIG. Individual NAND flash memory chips can operate independently. Therefore, the NAND flash memory chip functions as a unit capable of parallel operation. 3, the flash programming controller 13 has 16 channels Ch. 1 to Ch. 16 are connected, and 16 channels Ch. 1 to Ch. 16 are connected to two NAND flash memory chips. In this case, channel Ch. 1 to Ch. 16 NAND flash memory chips #1 to #16 connected to channel Ch.16 may be organized as bank #0, and channel Ch. 1 to Ch. The remaining 16 NAND flash memory chips #17-#32 connected to 16 may be organized as bank #1. A bank functions as a unit for operating a plurality of memory modules in parallel by bank interleaving. In the configuration example of FIG. 3, a maximum of 32 NAND flash memory chips can be operated in parallel by 16 channels and bank interleaving using two banks.

The erase operation may be performed in units of one block (physical block), or may be performed in units of super blocks including a set of a plurality of physical blocks capable of parallel operation. One super block may include, but is not limited to, a total of 32 physical blocks selected one by one from NAND flash memory chips #1 to #32. Each of the NAND flash memory chips #1 to #32 may have a multiplane configuration. For example, when each of the NAND flash memory chips #1 to #32 has a multiplane configuration including two planes, one super block is 64 superblocks corresponding to the NAND flash memory chips #1 to #32. It may contain a total of 64 physical blocks selected one by one from the planes.

FIG. 4 shows 32 physical blocks (here, physical block BLK2 in NAND flash memory chip #1, physical block BLK3 in NAND flash memory chip #2, physical block BLK3 in NAND flash memory chip #3). Block BLK7, physical block BLK4 in NAND flash memory chip #4, physical block BLK6 in NAND flash memory chip #5, . . . physical block BLK3 in NAND flash memory chip #32). SB) are exemplified.

The write destination block may be one physical block or one super block. A configuration in which one superblock includes only one physical block may be used, in which case one superblock is equivalent to one physical block.

Next, the configuration of the controller 4 shown in FIG. 1 will be described.

Controller 4 includes host interface 11, CPU 12, flash programming controller 13, DRAM interface 14, and the like. These CPU 12 , flash programming controller 13 and DRAM interface 14 are interconnected via bus 10 .

The 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). Alternatively, in configurations where the flash storage device 3 is connected to the host 2 via Ethernet (registered trademark), the host interface 11 may be an NVMe over Fabrics (NVMeOF) controller. The configuration in which the flash storage devices 3 are connected to the host 2 via Ethernet (registered trademark) makes it possible to easily increase the number of flash storage devices 3 as required. Furthermore, it is also possible to easily increase the number of hosts 2 .

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

CPU 12 is a processor configured to control host interface 11 , flash programming controller 13 and 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 various processes by executing this firmware. Note that the firmware may be loaded onto an SRAM (not shown) within the controller 4 . This CPU 12 can execute command processing and the like for processing various commands from the host 2 . The operation of CPU 12 is controlled by the aforementioned firmware executed by CPU 12 . Part or all of the command processing may be executed by dedicated hardware within the controller 4 .

The CPU 12 can function as a block identifier/buffer address receiver 21 , a transfer request transmitter 22 and a notifier 23 .

A block identifier/buffer address receiving unit 21 receives a write request including a block identifier and a buffer address from the host 2 and holds the block identifier and buffer address in a predetermined storage area. The block identifier included in the write request may be a block address specifying a particular write destination block. Alternatively, the write request may contain the stream ID instead of the block identifier. A block identifier or stream ID functions as an identifier associated with one write destination block. The buffer address included in the write request is storage location information indicating the location within the UWB 2A where the data to be written (write data) is stored. Alternatively, the write request may contain an offset within the buffer as storage location information instead of the buffer address. The intra-buffer offset indicates the offset position within the UWB 2A in which the write data is stored.

When writing the above-mentioned write data to the NAND flash memory 5, the transfer request transmission unit 22 sends a transfer request including storage position information (for example, buffer address) to the host 2, thereby acquiring the write data from the UWB 2A. .

When the writing of the above-mentioned write data is completed and the above-mentioned write data can be read from the NAND flash memory 5, the notification unit 23 notifies that the above-mentioned write data held in the UWB 2A is no longer necessary. Notify host 2.

Flash programming controller 13 is a memory control circuit configured to control NAND flash memory 5 under the control of CPU 12 .

DRAM interface 14 is a DRAM control circuit configured to control DRAM 6 under the control of CPU 12 . A part of the storage area of the DRAM 6 is used for storing a read buffer (RB) 30, a write buffer (WB) 31, a block management table 32, and a defect information management table 33. FIG. The read buffer (RB) 30, write buffer (WB) 31, block management table 32, and defect information management table 33 may be stored in an SRAM (not shown) within the controller 4. FIG. The block management table 32 manages whether the data stored in each block is valid data or invalid data. The defect information management table 33 manages a list of defect blocks.

FIG. 5 shows the relationship between multiple write destination blocks corresponding to multiple end users and multiple write buffer areas.

In the flash storage device 3, the states of blocks are roughly divided into active blocks storing valid data and free blocks not storing valid data. Each block that is an active block is managed by a list called the active block pool. On the other hand, each block that is a free block is managed by a list called free block pool.

In this embodiment, the controller 4 allocates a plurality of blocks (free blocks) selected from the free block pool as write destination blocks to which write data received from the host 2 should be written. In this case, the controller 4 first performs an erase operation on each selected block (free block), thereby putting each block into a writable erased state. A writable erased block becomes an open write destination block. When a certain write destination block is entirely filled with write data from the host 2, the controller 4 moves this write destination block to the active block pool and creates a new block (free block) from the free block pool. Allocate as a write destination block.

In the flash storage device 3, the same number of write destination blocks (flash blocks) as the number of end users (end user terminals) sharing the flash storage device 3 or more are opened. The UWB 2A on the host 2 side may include the same number of write buffer areas (UWB areas) as these write destination blocks (flash blocks).

In FIG. 5, write buffer area #1 is associated with write destination block #1, and all data to be written to write destination block #1 is stored in write buffer area #1. Write buffer area #2 is associated with write destination block #2, and all data to be written to write destination block #2 is stored in write buffer area #2. Write buffer area #3 is associated with destination block #3, and all data to be written to destination block #4 is stored in write buffer area #3. Similarly, write buffer area #n is associated with write destination block #n, and all data to be written to write destination block #n is stored in write buffer area #n.

The host 2 stores write data from the end user terminal #1 in the write buffer area #1, stores write data from the end user terminal #2 in the write buffer area #2, and stores write data from the end user terminal #3 in the write buffer area #2. Data is stored in write buffer area #3, write data from end user terminal #4 is stored in write buffer area #4, and write data from end user terminal #n is stored in write buffer area #n. .

The host 2 flushes a write request including an identifier associated with the write destination block #1 and storage location information indicating the location within the write buffer area #1 where the write data from the end user terminal #1 is stored. Send to the storage device 3 . The identifier associated with the write destination block #1 may be a block identifier (block address) specifying the write destination block #1, or may be a stream ID associated with the write destination block #1.

The flash storage device 3 sends write data corresponding to the size of one physical page (for example, write data for three pages in the case of TLC-flash memory) by sending a transfer request including this storage location information to the host 2. is obtained from the write buffer area #1. Note that this transfer request includes not only the storage location information but also an identifier associated with the write destination block #1 (for example, a block identifier specifying the write destination block #1, or a stream ID associated with the write destination block #1). may contain As a result, the host 2 can easily specify the write buffer area in which the write data to be transferred to the flash storage device 3 is stored and the position (storage position) within this write buffer area.

The host 2 receives an identifier associated with the write destination block #2 (for example, a block identifier specifying the write destination block #2 or a stream ID associated with the write destination block #2) and a write from the end user terminal #2. A write request is sent to the flash storage device 3, which includes storage position information indicating the position in the write buffer area #2 where the data is stored.

The flash storage device 3 sends write data corresponding to the size of one physical page (for example, write data for three pages in the case of TLC-flash memory) by sending a transfer request including this storage location information to the host 2. is obtained from write buffer area #2. Note that this transfer request includes not only the storage position information but also an identifier associated with the write destination block #2 (for example, a block identifier specifying the write destination block #2, or a stream ID associated with the write destination block #2). may contain As a result, the host 2 can easily specify the write buffer area in which the write data to be transferred to the flash storage device 3 is stored and the position (storage position) within this write buffer area.

Similarly, the host 2 stores an identifier associated with the write destination block #n (for example, a block identifier specifying the write destination block #n or a stream ID associated with the write destination block #n) and an end user terminal #n. A write request is sent to the flash storage device 3, which includes storage position information indicating the position within the write buffer area #n where the write data from is stored.

The flash storage device 3 sends write data corresponding to the size of one physical page (for example, write data for three pages in the case of TLC-flash memory) by sending a transfer request including this storage location information to the host 2. is obtained from the write buffer area #n. Note that this transfer request includes not only the storage position information but also an identifier associated with the write destination block #n (for example, a block identifier specifying the write destination block #n, or a stream ID associated with the write destination block #n). may contain As a result, the host 2 can easily specify the write buffer area in which the write data to be transferred to the flash storage device 3 is stored and the position (storage position) within this write buffer area.

FIG. 6 shows the relationship between the flash storage device 3 and the host-side UWB 2A and data write processing executed by the host 2 and the flash storage device 3. As shown in FIG.

Here, in order to simplify the illustration, the data write processing for one write destination block BLK will be described as an example. Also, here, it is assumed that write data is written to one write destination block BLK by a full sequence program operation.

(1) The host 2 executes a flash storage manager, which is host software for managing the flash storage device 3 . A flash storage manager may be embedded within the device driver for the flash storage device 3 . A flash storage manager manages UWB2A. In response to a request to write data from upper software (application program or file system), the flash storage manager stores a write request with data to be written, tags and block identifiers in UWB2A. A tag is an identifier that can identify this data. A tag can be a logical address such as a logical block address (LBA), a key in a key-value store, or a file identifier such as a filename. The block identifier may be the block address of the write destination block BLK. Note that this write request may include the length of the data to be written (Length), and in the case of requesting writing of fixed-length write data, this write request must not include the length (Length). good too. This write request may also include a page address indicating the page to which the data should be written. The upper software may issue this write request, and the flash storage manager may receive this write request from the upper software and store the received write request in the UWB 2A.

(2) The flash storage manager sends a write request (write command) to the flash storage device 3 . This write request includes a tag, block identifier (block address), buffer address (or offset within the buffer). The buffer address indicates the location within the UWB 2A where the data to be written is stored. This write request may also include a page address indicating the page to which the data should be written. The controller 4 of the flash storage device 3 receives this write request and holds the tag, block identifier and buffer address (or buffer offset) included in this write request.

(3) When the flash programming controller 13 writes this data to the write destination block BLK, the controller 4 of the flash storage device 3 sends a Transfer Request to the host 2 . This transfer request includes the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include the retained tag and the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include a retained buffer address (or offset within the buffer) and a retained block identifier (block address).

(4) When the flash storage manager of the host 2 receives a transfer request including at least a buffer address (or an offset within the buffer), the transfer request is stored at a location within the UWB 2A specified by this buffer address (or an offset within the buffer). Data is transferred from the UWB 2A to the flash storage device 3. For example, if the NAND flash memory 5 is a TLC-flash memory, 3 pages worth of data are transferred from the UWB 2A to the flash storage device 3 . The transfer request may contain the length of the data to be transferred.

(5) The controller 4 of the flash storage device 3 receives this data and transfers this data to the NAND flash memory 5 via the flash programming controller 13 and writes this data to the write destination block BLK. In the case of writing 3 pages of data to a certain physical page by the full sequence program operation, the flash programming controller 13 sequentially transfers the 3 pages of data to the page buffer group in the NAND flash memory 5, and A write instruction is sent to the NAND flash memory 5 . The flash programming controller 13 can determine whether the write operation (full sequence program operation) has ended by monitoring the status from the NAND flash memory 5 .

(6) When the write operation is finished and it becomes possible to read this data (three pages worth of data here), that is, when the full sequence program operation is finished successfully, the controller 4 stores data in the UWB 2A. The host 2 is notified that this data (three pages worth of data in this case) is no longer needed. In this case, the controller 4 of the flash storage device 3 may send a write completion (Write Done) including a tag, page address and length to the host 2, or an invalidate request (invalidate).
Request) may be sent to the host 2 . The invalidate request includes the buffer address (or offset within the buffer) where the data that has been made readable is stored. Alternatively, the invalidation request may include the tag of the data that has been made readable and the buffer address (or offset within the buffer) where the data that has been made readable is stored. Alternatively, when the full sequence program operation to the last physical page of this write destination block BLK is completed and the entire write destination block BLK is filled with data, the controller 4 writes to the write destination block BLK. Notify the host 2 that the corresponding UWB area is no longer needed. In this case, the controller 4 sends a Close Request to the host 2 . The close request may include the block identifier (block address) of the write destination block BLK. Upon receiving the close request containing the block identifier of the write destination block BLK, the flash storage manager of host 2 releases the UWB area associated with this write destination block BLK and uses this UWB area for other purposes. . In this case, the flash storage manager may reuse this released UWB area as a UWB area for other write destination blocks (eg, newly opened write destination blocks).

FIG. 7 shows an example of the relationship between multiple write destination blocks and multiple write buffer areas (UWB areas).

A write buffer area (UWB area #1) corresponding to a certain write destination block BLK#1 may include, for example, multiple storage areas for temporarily storing multiple pages of data. In this case, each storage area may include a tag field, a valid/invalid field, a data storage field, and a page address field. A tag field stores the tag of the corresponding data. The valid/invalid field holds a valid/invalid flag indicating whether it is necessary to hold the corresponding data. The data storage field stores data to be written to the write destination block BLK#1. A data storage field may have the size of a page. The page address field is an optional field, and if the write request contains a page address, this page address is stored in the page address field.

When the flash storage device 3 notifies that certain data held in the UWB area #1 is no longer needed, the host 2 (flash storage manager) validates/invalidates the data in the storage area corresponding to this data. Update the flag to a value indicating invalid. The storage area whose valid/invalid flag has been updated to a value indicating invalidity is reused to store other data to be written to the write destination block BLK#1.

The data structure of the UWB area shown in FIG. 7 is an example, and for example, data (write data) may be managed in the UWB area in a size different from the page size.

FIG. 8 shows the relationship between the flash storage device 3 and the host-side UWB 2A, and data read processing executed by the host 2 and the flash storage device 3. As shown in FIG.

(1) In response to a request to read data from upper software, the flash storage manager of the host 2 sends a read request to the flash storage device 3 to read this data. This read request may include, for example, a tag, block identifier (block address), page address and length.

(2) If the write operation of the data specified by this read request to the write destination block BLK has already been completed and this data can be read, the controller 4 of the flash storage device 3 writes through the flash programming controller 13 This data is read from the write destination block BLK.

(3) The controller 4 of the flash storage device 3 sends the read data to the host 2 together with the tag of this data.

(3') If the data specified by this read request is not readable, that is, the host 2 issues a read request to read this data during the period from the start of writing this data until this data becomes readable. , the controller 4 of the flash storage device 3 sends a transfer request to the host 2 requesting that this data be returned from the UWB 2A as a response to the read request. This transfer request may contain both a buffer address corresponding to this data, or a buffer address corresponding to this data and a block identifier corresponding to this data as information that can identify the data within the UWB 2A to be transferred. good. Alternatively, this transfer request may contain a tag corresponding to this data, or may contain a block identifier and page address corresponding to this data.

(4') The flash storage manager of the host 2 reads this data from the UWB 2A and returns the read data together with the tag of this data to the upper software.

Alternatively, the flash storage manager of the host 2 responds to the request from the upper software to read the data stored in the UWB 2A until the flash storage device 3 notifies that the data is no longer needed. Then, without sending a read request to the flash storage device 3, the data may be read directly from the UWB 2A. In this case, data read processing is executed as follows.

(1") Until the flash storage device 3 notifies that certain data stored in the UWB 2A is no longer needed, the flash storage manager of the host 2 receives a request from the upper software to read this data. , a read request is sent to the UWB 2A to read this data from the UWB 2A.The read request may include, for example, a tag, a buffer address, and a length.

(2'') The flash storage manager returns the data read from UWB2A to the upper software together with the tag of this data.

FIG. 9 shows the relationship between the flash storage device 3 supporting foggy fine writing and the host-side UWB 2A, and the data write process performed by the host 2 and the flash storage device 3 .

Here, it is assumed that write data is written to one write destination block BLK by a multi-step write operation (foggy fine program operation).

(1) In the host 2, the flash storage manager stores a write request accompanied by data to be written, a tag, and a block identifier in the UWB 2A in response to a data write request from upper software. Note that this write request may include the length of the data to be written (Length), and in the case of requesting writing of fixed-length write data, this write request must not include the length (Length). good too. This write request may also include a page address indicating the page to which the data should be written. The upper software may issue this write request, and the flash storage manager may receive this write request from the upper software and store the received write request in the UWB 2A.

(2) The flash storage manager sends a write request (write command) to the flash storage device 3 . This write request includes a tag, block identifier (block address), buffer address (or offset within the buffer). This write request may also include a page address indicating the page to which the data should be written. The controller 4 of the flash storage device 3 receives this write request and holds the tag, block identifier and buffer address (or buffer offset) included in this write request.

(3) When the flash programming controller 13 starts the first stage write operation (foggy write) of this data, the controller 4 of the flash storage device 3 sends a transfer request (Transfer Request) to the host 2 . This transfer request includes the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include the retained tag and the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include a retained buffer address (or offset within the buffer) and a retained block identifier (block address).

(4) When the flash storage manager of the host 2 receives a transfer request including at least a buffer address (or an offset within the buffer), the transfer request is stored at a location within the UWB 2A specified by this buffer address (or an offset within the buffer). Transfer the data (here illustrated as “Foggy Data”) from the UWB 2A to the flash storage device 3 . For example, if the NAND flash memory 5 is a TLC-flash memory, 3 pages of data are transferred from the UWB 2A to the flash storage device 3 as Foggy Data. The transfer request may contain the length of the data to be transferred.

(5) The controller 4 of the flash storage device 3 receives this data, transfers this data to the NAND flash memory 5 via the flash programming controller 13, and transfers this data to the write destination physical page of the write destination block BLK. (First stage write: Foggy write). In the case of writing 3 pages of data to a certain write destination physical page by foggy write, the flash programming controller 13 sequentially transfers the 3 pages of data to the page buffer group in the NAND flash memory 5, and then A second write instruction is sent to the NAND flash memory 5 . The flash programming controller 13 can determine whether the write operation (first-stage write operation) is completed by monitoring the status from the NAND flash memory 5 . Foggy fine program operations are typically performed to reduce program disturb, e.g. Like writing, it is executed while going back and forth between a plurality of word lines (a plurality of physical pages).

(6) When the timing for executing the second stage write (fine write) to this write destination physical page arrives, the controller 4 of the flash storage device 3 writes the data to be written by fine write (the data to be written by foggy write). In order to acquire the same data as the data), the transfer request (Transfer Request) is sent to the host 2 again. This transfer request contains the same buffer address as the buffer address held above, that is, the buffer address contained in the transfer request sent in process (3).

(7) When the flash storage manager of the host 2 receives a transfer request including at least a buffer address (or an offset within the buffer), the transfer request is stored at a location within the UWB 2A specified by this buffer address (or an offset within the buffer). Data (shown here as “Fine Data”) is transferred from the UWB 2A to the flash storage device 3 . Fine Data is the same data as Foggy Data. For example, if the NAND flash memory 5 is a TLC-flash memory, the data for the three pages described above is transferred from the UWB 2A to the flash storage device 3 as Fine Data. The transfer request may contain the length of the data to be transferred. The host 2 does not need to recognize whether the data to be transferred is Foggy Data or Fine Data.

(8) The controller 4 of the flash storage device 3 receives this data, transfers this data to the NAND flash memory 5 via the flash programming controller 13, and transfers this data to the aforementioned write destination of the write destination block BLK. Write to the physical page (second stage write: fine write). In the case of writing 3 pages of data to this write destination physical page by fine writing, the flash programming controller 13 writes the same 3 pages of data to the NAND flash memory 5 as the 3 pages of data used in the foggy writing. , and a second stage write instruction is sent to the NAND flash memory 5 . The flash programming controller 13 can determine whether the write operation (second stage write operation) is completed by monitoring the status from the NAND flash memory 5 .

(9) When the second stage write operation is completed and it becomes possible to read this data (three pages of data here), that is, when all the foggy fine program operations are completed successfully, the controller 4 notifies the host 2 that this data held in the UWB 2A (here, data for three pages) is no longer needed. In this case, the controller 4 of the flash storage device 3 may send a write completion (Write Done) including a tag, page address and length to the host 2, or send an invalidate request to the host 2. You may The invalidate request includes the buffer address (or offset within the buffer) where the data that has been made readable is stored. Alternatively, the invalidation request may include the tag of the data that has been made readable and the buffer address (or offset within the buffer) where the data that has been made readable is stored. Alternatively, when the foggy fine program operation to the last physical page of this write destination block BLK is completed and the entire write destination block BLK is filled with data, the controller 4 writes to the write destination block BLK. Notify the host 2 that the corresponding UWB area is no longer needed. In this case, the controller 4 sends a Close Request to the host 2 . The close request may include the block identifier (block address) of the write destination block BLK. Upon receiving the close request containing the block identifier of the write destination block BLK, the flash storage manager of host 2 releases the UWB area associated with this write destination block BLK and uses this UWB area for other purposes. . In this case, the flash storage manager may reuse this released UWB area as a UWB area for other write destination blocks (eg, newly opened write destination blocks).

FIG. 10 shows the relationship between the flash storage device 3 supporting foggy fine writing and the host-side UWB 2A, and the data read processing performed by the host 2 and the flash storage device 3 .

(1) In response to a request to read data from upper software, the flash storage manager of the host 2 sends a read request to the flash storage device 3 to read this data. This read request may include, for example, a tag, block identifier (block address), page address and length.

(2) If the write operation of the data specified by this read request to the write destination block BLK has already been completed and this data is readable, that is, both the foggy write of this data and the fine write of this data are possible. If so, controller 4 of flash storage device 3 reads this data from destination block BLK via flash programming controller 13 .

(3) The controller 4 of the flash storage device 3 sends the read data to the host 2 together with the tag of this data.

(3') If the data specified by this read request is not readable, that is, the host 2 issues a read request to read this data during the period from the start of writing this data until this data becomes readable. , the controller 4 of the flash storage device 3 sends a transfer request to the host 2 requesting that this data be returned from the UWB 2A as a response to the read request. This transfer request may include the buffer address corresponding to this data.

(4') The flash storage manager of the host 2 reads this data from the UWB 2A and returns the read data together with the tag of this data to the upper software.

Alternatively, the flash storage manager of the host 2 responds to the request from the upper software to read the data stored in the UWB 2A until the flash storage device 3 notifies that the data is no longer needed. Then, without sending a read request to the flash storage device 3, the data may be read directly from the UWB 2A. In this case, data read processing is executed as follows.

(1") Until the flash storage device 3 notifies that certain data stored in the UWB 2A is no longer needed, the flash storage manager of the host 2 receives a request from the upper software to read this data. , a read request is sent to the UWB 2A to read this data from the UWB 2A.The read request may include, for example, a tag, a buffer address, and a length.

(2'') The flash storage manager returns the data read from UWB2A to the upper software together with the tag of this data.

The sequence diagram of FIG. 11 shows the procedure of data write processing executed by the host 2 and the flash storage device 2 .

The host 2 stores data (write data) to be written to a certain write destination block in the UWB area associated with this write destination block, and flushes a write request including a block identifier and a buffer address (or an offset within the buffer). It is sent to the storage device 3 (step S11). The block identifier is the block address of the write destination block to which this write data is to be written. The buffer address indicates the position within the UWB area where this write data is stored.

The controller 4 of the flash storage device 3 receives this write request from the host 2 and holds the block identifier and buffer address (or buffer offset) in this write request (step S21). In this case, the controller 4 may retain these block identifiers and buffer addresses by storing them in the write buffer 31 on the DRAM 6 .

When writing the write data corresponding to this write request to the write destination block specified by the held block identifier, the controller 4 of the flash storage device 3 performs transfer including the held buffer address (or buffer offset). A request is sent to the host 2 (step S22).

When the host 2 receives this transfer request, the host 2 transfers this write data from the UWB area to the flash storage device 3 (step S12).

The controller 4 of the flash storage device 3 receives this write data transferred from the host 2 (step S23). The controller 4 holds the received write data by storing it in, for example, the write buffer 31 on the DRAM 6 (step S24).

The controller 4 transfers the received write data to the NAND flash memory 5 (step S25). The controller 4 holds the write data until the transfer of the write data to the NAND flash memory 5 is completed. The controller 4 then writes this write data to the write destination block specified by the held block identifier (step S26). In this case, the controller 4 determines the write destination page in the write destination block to which the write data is to be written. Note that the write request may include a page address specifying the write destination page.

When this write data write operation is completed and this write data becomes readable (when the full sequence program operation is completed in the full sequence program operation), the controller 4 stores the write data in the UWB area. The host 2 is notified that this write data stored is no longer needed (step S27).

The flowchart in FIG. 12 shows the procedure of notification processing executed by the flash storage device 3 .

The controller 4 of the flash storage device 3 determines whether or not the data write operation to the write destination block has been completed and the data can be read (step S31).

When the data write operation is completed and this data becomes readable (YES in step S31), the controller 4 completes the write operation to the last page (last physical page) of this write destination block. It is determined whether or not the entire write destination block is filled with data (step S32).

If there are physical pages (unwritten physical pages) that can be used in this write destination block (NO in step S32), the controller 4 makes the readable data held in the UWB area unnecessary. In order to notify the host 2 of the fact, write completion (Write Done) or invalidate request (invalidate Request) is sent to the host 2 (step S33).

If the write operation to the last page (last physical page) of this write destination block is completed and the entire write destination block is filled with data (YES in step S32), the controller 4 A Close Request is sent to the host 2 to notify the host 2 that the entire UWB area corresponding to the block is no longer needed (step S34).

The flowchart in FIG. 13 shows the procedure of host-side processing executed in response to reception of a transfer request.

The host 2 sends a write request including a block identifier and a buffer address (or offset within the buffer) to the flash storage device 3 (step S40). The host 2 determines whether or not a transfer request has been received from the flash storage device 3 (step S41).

If a transfer request is received from the flash storage device 3 (YES in step S41), the host 2 is stored at a location within the UWB area specified by the buffer address (or buffer offset) in the transfer request. The data is transferred to the flash storage device 3 (step S42). Then, the host 2 determines whether or not the flash storage device 3 has notified unnecessary data in the UWB area, or whether or not a Close Request has been received from the flash storage device 3 (steps S43 and S44). ).

If unnecessary data in the UWB area is notified from the flash storage device 3 (YES in step S43), the host 2 updates the valid/invalid flag corresponding to this unnecessary data to a value indicating invalidity. One storage area in the UWB area in which unnecessary data is stored is released (step S44). The host 2 can reuse this released storage area as a storage area for new write data to be written to the write destination block corresponding to this UWB area.

Thus, in this embodiment, when the write operation of certain data is completed and this data becomes readable, the flash storage device 3 notifies the host 2 that this data in the UWB area is no longer needed. . Therefore, this data is held in the UWB area until it becomes readable from the NAND flash memory 5 .

If a close request (Close Request) is received from the flash storage device 3 (YES in step S45), the host 2 releases the entire UWB area associated with the write destination block of the block identifier included in the close request ( step S46). The host 2 can reuse this released UWB area as a UWB area for a write destination block newly allocated by the flash storage device 3 .

The flowchart of FIG. 14 shows the procedure of data read operation performed by the flash storage device 3 in response to receiving a read request.

The controller 4 of the flash storage device 3 receives a read request from the host 2 (step S51). The controller 4 determines whether or not the data to be read specified by the read request is data that has been written to the write destination block and is readable (step S52).

If the data to be read has been written to the write destination block and is readable data (YES in step S52), the controller 4 reads the data to be read from the NAND flash memory 5 ( Step S53), and returns the read data to the host 2 (step S54).

On the other hand, if the data to be read has completed the write operation to the write destination block and is not readable data, that is, if the data is read within the period from the start of writing the data until the data becomes readable. If a read request is received from the host 2 (NO in step S52), the controller 4 sends a transfer request to the host 2 requesting that this data be returned from the UWB area as a response to the read request (step S55). ).

The flowchart of FIG. 15 shows the procedure of host-side processing for reading data.

The host 2 sends a read request to the flash storage device 3 to read the data regardless of whether the data to be read exists in the UWB area (step S61).

Then, the host 2 determines whether or not a transfer request requesting to return (read) this data from the UWB area has been received from the flash storage device 3 (step S62).

If this transfer request is received from the flash storage device 3 (YES in step S62), the host 2 reads this data from the UWB area (step S63).

FIG. 16 shows the relationship between the flash storage device 3 that supports stream writing and the host-side UWB 2A, and data write processing performed by the host 2 and the flash storage device 3 .

Here, it is assumed that write data is written to one write destination block BLK by a full sequence program operation.

(1) In the host 2, in response to a data write request from upper software (application program or file system), the flash storage manager sends a write request with data to be written, stream ID, LBA, and length to UWB 2A. Store. A stream ID is an identifier of a stream in multiple streams associated with multiple destination blocks. The upper software may issue this write request, and the flash storage manager may receive this write request from the upper software and store the received write request in the UWB 2A.

(2) The flash storage manager sends a write request (write command) to the flash storage device 3 . This write request includes stream ID, LBA, length, buffer address (or offset within buffer). The buffer address indicates the location within the UWB 2A where the data to be written is stored. The controller 4 of the flash storage device 3 receives this write request and holds the stream ID, LBA, length and buffer address included in this write request.

(3) When the flash programming controller 13 writes this data to the write destination block BLK, the controller 4 of the flash storage device 3 sends a Transfer Request to the host 2 . This transfer request includes the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include the retained LBA and the retained buffer address (or offset within the buffer). Alternatively, the transfer request may include the retained buffer address (or offset within the buffer) and the retained stream ID. Alternatively, the transfer request may include the retained buffer address (or offset within the buffer) and the block identifier (block address) of the destination block associated with the retained stream ID.

(4) When the flash storage manager of the host 2 receives a transfer request including at least a buffer address (or an offset within the buffer), the transfer request is stored at a location within the UWB 2A specified by this buffer address (or an offset within the buffer). Data is transferred from the UWB 2A to the flash storage device 3. For example, if the NAND flash memory 5 is a TLC-flash memory, 3 pages worth of data are transferred from the UWB 2A to the flash storage device 3 . The transfer request may contain the length of the data to be transferred.

(5) The controller 4 of the flash storage device 3 receives this data and transfers this data to the NAND flash memory 5 via the flash programming controller 13 and writes this data to the write destination block BLK. In the case of writing 3 pages of data to a certain physical page by the full sequence program operation, the flash programming controller 13 sequentially transfers the 3 pages of data to the page buffer group in the NAND flash memory 5, and A write instruction is sent to the NAND flash memory 5 . The flash programming controller 13 can determine whether the write operation (full sequence program operation) has ended by monitoring the status from the NAND flash memory 5 .

(6) When the write operation is finished and it becomes possible to read this data (three pages worth of data here), that is, when the full sequence program operation is finished successfully, the controller 4 stores data in the UWB 2A. The host 2 is notified that this data (three pages worth of data in this case) is no longer needed. In this case, the controller 4 of the flash storage device 3 may send a write completion (Write Done) including LBA and length to the host 2, or may send an invalidate request to the host 2. good. The invalidate request includes the buffer address (or offset within the buffer) where the data that has been made readable is stored. Alternatively, the invalidation request may include the LBA of the data that was made readable and the buffer address (or offset within the buffer) where the data that was made readable is stored. Alternatively, when the full sequence program operation to the last physical page of this write destination block BLK is completed and the entire write destination block BLK is filled with data, the controller 4 writes to the write destination block BLK. Notify the host 2 that the corresponding UWB area is no longer needed. In this case, the controller 4 sends a Close Request to the host 2 . The close request may include the block identifier (block address) of the write destination block BLK. Upon receiving the close request containing the block identifier of the write destination block BLK, the flash storage manager of host 2 releases the UWB area associated with this write destination block BLK and uses this UWB area for other purposes. . In this case, the flash storage manager may reuse this released UWB area as a UWB area for other write destination blocks (eg, newly opened write destination blocks).

FIG. 17 shows the relationship between multiple stream IDs and multiple write destination blocks associated with these stream IDs.

Here, the stream with stream ID #1 is associated with the write destination block BLK#1, the stream with stream ID #2 is associated with the write destination block BLK#2, and the stream with stream ID #3 is associated with the write destination block BLK#1. A case is exemplified in which block BLK#3 is associated, and write destination block BLK#n is associated with the stream of stream ID#n.

The write data specified by the write request including stream ID #1 is written to the write destination block BLK#1. The write data specified by the write request including stream ID #2 is written to write destination block BLK#2. The write data specified by the write request including stream ID #3 is written to write destination block BLK#3. Write data specified by a write request including stream ID#n is written to write destination block BLK#n.

FIG. 18 shows the relationship between the flash storage device 3 that supports stream writing and the host-side UWB 2A, and data read processing performed by the host 2 and the flash storage device 3 .

(1) In response to a request to read data from upper software, the flash storage manager of the host 2 sends a read request to the flash storage device 3 to read this data. This read request may include, for example, LBA, length.

(2) If the write operation of the data specified by this read request to the write destination block BLK has already been completed and this data can be read, the controller 4 of the flash storage device 3 writes through the flash programming controller 13 This data is read from the write destination block BLK.

(3) The controller 4 of the flash storage device 3 sends the read data to the host 2 together with the LBA of this data.

(3') If the data specified by this read request is not readable, that is, the host 2 issues a read request to read this data during the period from the start of writing this data until this data becomes readable. , the controller 4 of the flash storage device 3 sends a transfer request to the host 2 requesting that this data be returned from the UWB 2A as a response to the read request. This transfer request may include the buffer address corresponding to this data.

(4') The flash storage manager of the host 2 reads this data from the UWB 2A and returns the read data together with the LBA of this data to the upper software.

Alternatively, the flash storage manager of the host 2 responds to the request from the upper software to read the data stored in the UWB 2A until the flash storage device 3 notifies that the data is no longer needed. Then, without sending a read request to the flash storage device 3, the data may be read directly from the UWB 2A. In this case, data read processing is executed as follows.

(1") Until the flash storage device 3 notifies that certain data stored in the UWB 2A is no longer needed, the flash storage manager of the host 2 receives a request from the upper software to read this data. in response to send a read request to UWB 2A to read this data from UWB 2A.This read request may include, for example, LBA, length.

(2″) The flash storage manager returns the data read from UWB2A to the upper software together with the LBA of this data.

The sequence diagram of FIG. 19 shows the procedure of data write processing executed by the flash storage device 3 and the host 2 that support foggy fine write.

Here, a case where the write request includes a block identifier and a buffer address (or an offset within the buffer) will be described as an example.

The host 2 stores data (write data) to be written to a certain write destination block in the UWB area associated with this write destination block, and flushes a write request including a block identifier and a buffer address (or an offset within the buffer). It is sent to the storage device 3 (step S71). The block identifier is the block address of the write destination block to which this write data is to be written. The buffer address indicates the position within the UWB area where this write data is stored.

The controller 4 of the flash storage device 3 receives this write request from the host 2 and holds the block identifier and buffer address (or buffer offset) in this write request (step S81). In this case, the controller 4 may retain these block identifiers and buffer addresses by storing them in the write buffer 31 on the DRAM 6 .

When writing the write data corresponding to this write request to the write destination block specified by the held block identifier by a multi-stage program operation (foggy fine program operation), the controller 4 of the flash storage device 3 first , to acquire write data (foggy data) used for foggy writing from the UWB area, a transfer request including the held buffer address (or buffer offset) is sent to the host 2 (step S82). .

When the host 2 receives this transfer request, the host 2 transfers this write data from the UWB area to the flash storage device 3 (step S72).

The controller 4 of the flash storage device 3 receives this write data transferred from the host 2 as foggy data (step S83). The controller 4 holds the received write data (foggy data) by storing it in, for example, the write buffer 31 on the DRAM 6 (step S84).

The controller 4 transfers the received write data (foggy data) to the NAND flash memory 5 (step S85). The controller 4 holds the write data (foggy data) until the transfer of the write data (foggy data) to the NAND flash memory 5 is completed. Then, the controller 4 writes this write data (foggy data) to the write destination physical page of the write destination block specified by the held block identifier (first stage write: foggy write) (step S86).

After that, when the timing for executing the second stage write (fine write) to this write destination physical page arrives, the controller 4 of the flash storage device 3 writes the write data (fine data) used for the fine write. from the UWB area, a transfer request including the retained buffer address (or offset in the buffer) is sent to the host 2 again (step S87). Fine data is the same data as foggy data.

When the host 2 receives this transfer request, the host 2 transfers this write data from the UWB area to the flash storage device 3 (step S73).

The controller 4 of the flash storage device 3 receives this write data transferred from the host 2 as fine data (step S88). The controller 4 holds the received write data (fine data) by storing it in, for example, the write buffer 31 on the DRAM 6 (step S89).

The controller 4 transfers the received write data (fine data) to the NAND flash memory 5 (step S90). The controller 4 holds the write data (fine data) until the transfer of the write data (fine data) to the NAND flash memory 5 is completed. Then, the controller 4 writes this write data (fine data) to this write destination physical page of this write destination block (second stage write: fine write) (step S91).

When the write operation is finished and this write data becomes readable (that is, when both the foggy write operation and the fine write operation are finished), the controller 4 does not need this write data stored in the UWB area. The host 2 is notified that it has become (step S92).

FIG. 20 shows a configuration example of the host 2 (information processing device).

This host 2 includes a processor (CPU) 101, a main memory 102, a BIOS-ROM 103, a network controller 105, a peripheral interface controller 106, a controller 107, an embedded controller (EC) 108, and the like.

A processor 101 is a CPU configured to control the operation of each component in this information processing apparatus. This processor 101 executes various programs on the main memory 102 . The main memory 102 consists of random access memory such as DRAM. Programs executed by processor 101 include an application software layer 41, an operating system (OS) 42, a file system 43, device drivers 44, and the like.

Various application programs run on the application software layer 41 . As is generally known, the OS 42 manages the entire information processing apparatus, controls hardware within the information processing apparatus, and enables software to use the hardware and the flash storage device 3. is software configured to perform the control of The file system 43 is used to control file operations (create, save, update, delete, etc.).

A device driver 44 is a program for controlling and managing the flash storage device 3 . This device driver 44 includes the flash storage manager mentioned above. This flash storage manager 45 receives a command group for managing the UWB 2A on the main memory 102, a command group for sending write requests, read requests, etc. to the flash storage device 3, and transfer requests from the flash storage device 3. A group of instructions for transferring data from the UWB 2A to the flash storage device 3 each time, reading this data from the UWB 2A until the flash storage device 3 notifies that the data stored in the UWB 2A is no longer needed. commands to do so, etc. The processor 101 executes data write processing, data read processing, UWB area release processing, and the like by executing the instruction group of the flash storage manager 45 in the device driver 44 .

Network controller 105 is a communication device such as an ethernet controller. Peripheral interface controller 106 is configured to perform communications with peripheral devices, such as USB devices.

Controller 107 is configured to communicate with devices connected to a plurality of connectors 107A. In this embodiment, multiple flash storage devices 3 may be connected to multiple connectors 107A, respectively. Controller 107 may be a SAS expander, PCIe Switch, PCIe expander, flash array controller, or RAID controller. Alternatively, multiple flash storage devices 3 may be connected to the network controller 105 via ethernet.

The flowchart in FIG. 21 shows the procedure of data write processing executed by the processor 101 .

In the data write process, the processor 101 stores write data to be written to one write destination block in the UWB 2A (UWB area corresponding to this write destination block) (step S101). The processor 101 sends a write request to the flash storage device 3, which includes an identifier associated with this write destination block and storage position information indicating the position within the UWB 2A where the write data is stored (the position where there is no UWB area). Send out (step S102). The identifier associated with the destination block may be the block identifier (block address) of the destination block, as described above. The storage location information may be the buffer address (or offset within the buffer), as described above. In this case, the processor 101 may send a write request to the flash storage device 3 including the tag, block identifier, and buffer address (or offset within the buffer). Also, in a configuration in which the host 2 specifies not only blocks but also pages, the write request may include tags, block identifiers (block addresses), page addresses, and buffer addresses (or buffer offsets).

Alternatively, in the case of using stream writing, stream IDs may be used instead of block identifiers (block addresses). In this case, the write request may include the stream ID, LBA, buffer address (or offset within the buffer).

After the processor 101 has sent a write request to the flash storage device 3, every time the processor 101 receives a transfer request including a buffer address (or an offset within the buffer) from the flash storage device 3, the above write data is converted to UWB2A (UWB area) to the flash storage device 3 (steps S103 and S104). More specifically, the processor 101 determines whether a transfer request including a buffer address (or an offset within the buffer) has been received from the flash storage device 3 (step S103). Then, if this transfer request is received from the flash storage device 3 (YES in step S103), the processor 101 transfers the above write data from the UWB 2A (UWB area) to the flash storage device 3.

As described above, in a case where write data is written to a write destination block in a multi-step program operation (foggy fine program operation), the processor 101 outputs a transfer request including the same buffer address (or the same buffer offset). is received from the flash storage device 3 multiple times. Then, each time this transfer request is received, the processor 101 transfers the write data described above from the UWB 2A (UWB area) to the flash storage device 3 .

The flowchart of FIG. 22 shows the procedure of data reading processing executed by the processor 101 .

Until the flash storage device 3 notifies that the data stored in the UWB 2A (UWB area) is no longer needed, the processor 101 reads this data in response to a request from upper software. Data is read from UWB2A (UWB area), and the read data is returned to the upper software.

That is, if a data read request has been issued by upper software (YES in step S111), the processor 101 has already been notified by the flash storage device 3 that this data on the UWB 2A (UWB area) is no longer needed. It is determined whether or not there is (step S112).

If it has not been notified that this data is no longer necessary (NO in step S112), the processor 101 reads this data from the UWB2A (UWB area) and returns the read data to the upper software (step S112). ).

On the other hand, if it has already been notified that this data is no longer needed (YES in step S112), the processor 101 sends a read request for reading this data to the flash storage device 3, thereby Data is read from the flash storage device 3 (step S114).

The flowchart of FIG. 23 shows another procedure of data reading processing executed by the processor 101 .

If a request to read data is received from upper software (YES in step S121), processor 101 determines whether this data exists in UWB2A (UWB area), that is, whether or not this data is unnecessary. A read request for reading this data is sent to the flash storage device 3 regardless of whether or not it has already been notified from the flash storage device 3 that it has become (step S122).

If the data specified by this read request has not yet become readable, the flash storage device 3 sends a transfer request to the host 2 requesting that this data be returned from the UWB 2A (UWB area).

If this transfer request is received from the flash storage device 3 (YES in step S123), the processor 101 reads this data from the UWB 2A (UWB area) and returns this read data to the upper software (step S124). .

If this transfer request has not been received from the flash storage device 3 (NO in step S123), the processor 101 receives data returned from the flash storage device 3 as a response to the read request, and returns this data to the upper software. (Step S125).

The flowchart of FIG. 24 shows the procedure of UWB area release processing executed by the processor 101 .

When the processor 101 receives from the flash storage device 3 a notification (close request) indicating that the entire UWB area associated with one write destination block is no longer needed (YES in step S131), the processor 101 closes this UWB area. The entire area is released (step S132). At step S132, the processor 101 can use the memory space corresponding to this released UWB area for any other purpose. For example, the processor may reuse this released UWB area as a UWB area associated with a newly allocated write destination block by the controller 4 of the flash storage device 3 . When it is necessary to write data to this newly allocated write destination block, processor 101 first stores this data in the UWB area associated with this newly allocated write destination block, and then A write that includes an identifier (block identifier, or stream ID) associated with a newly allocated write destination block and storage location information (e.g., buffer address) indicating the location within this UWB area where this data is stored. Send the request to the flash storage device 3 .

As described above, according to the present embodiment, the controller 4 of the flash storage device 3 uses the first identifier (block identifier or stream ID) associated with one write destination block and the first identifier to be written. A write request including storage location information (buffer address or intra-buffer address) indicating the location in the write buffer (UWB2A) on the memory of the host 2 where data is stored is received from the host 2 . When writing the first data to the NAND flash memory 5, the controller 4 acquires the first data from the write buffer (UWB2A) by sending a transfer request including storage location information to the host 2. FIG. Therefore, since the data necessary for the write operation can be obtained from the write buffer (UWB2A) of the host 2, the number of write destination blocks that can be used at the same time can be increased without preparing a large number of write buffers in the flash storage device 3. be able to. Therefore, it is possible to easily increase the number of end users sharing the flash storage device 3 without increasing the cost of the flash storage device 3 .

Further, when the writing of the first data is finished and the first data can be read from the NAND flash memory 5, the controller 4 does not need the first data held in the write buffer (UWB2A). notifies the host 2 that the In response to this notification, the host 2 can discard this data if necessary. Therefore, until the data to be written becomes readable from the NAND flash memory 5, the controller 4 can repeatedly acquire this data from the write buffer (UWB2A) as necessary. Therefore, even when executing a multi-stage program operation such as the foggy fine program operation, the controller 4 transfers necessary data from the write buffer (UWB2A) each time a program operation of each stage is started. can be obtained.

In addition, in this embodiment, a NAND flash memory is exemplified as the nonvolatile memory. However, the function of this embodiment is, for example, MRAM (Magnetoresistive
Random Access Memory), PRAM (Phase change
Random Access Memory), ReRAM (Resistive Random Access Memory), or FeRAM (Ferroelectric Random Access Memory).

While several embodiments of the invention have been described, these embodiments have been 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, replacements, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the scope of the invention described in the claims and equivalents thereof.

2 Host 2A Write buffer 3 Flash storage device 4 Controller 5 NAND flash memory 21 Block identifier/buffer address receiver 22 Transfer request transmitter 23 Notifier.

Claims (16)

A memory system connectable to a host,
a non-volatile memory including a plurality of blocks;
a controller electrically connected to the non-volatile memory and configured to control the non-volatile memory;
The controller is
receiving from the host a write request including storage location information indicating a location within a write buffer in the memory of the host where first data to be written is stored;
When writing the first data to the nonvolatile memory by a multi-stage program operation,
At each program operation of the multi-stage program operation,
obtaining the first data from the write buffer by transmitting a transfer request including the storage location information to the host;
transferring the first data to the non-volatile memory;
A memory system configured to write the first data to a destination block of one of the plurality of blocks. When the controller receives a read request for reading the first data from the host during a period from the start of writing the first data until the first data becomes readable, the write 2. The memory system of claim 1, wherein the memory system is configured to send a retrieval request to the host to retrieve the first data from a buffer. the write buffer includes a plurality of write buffer areas corresponding to the plurality of blocks;
The controller notifies the host that a write buffer area in the write buffer corresponding to the one write destination block is no longer needed when the one write destination block is entirely filled with data. 2. The memory system of claim 1, wherein the memory system is configured as: 2. The memory system according to claim 1, wherein said memory system is connected to said host via Ethernet (registered trademark). 2. The memory system according to claim 1, wherein said write request includes a block identifier designating a write destination block. the plurality of blocks are each associated with a plurality of streams;
2. The memory system according to claim 1, wherein said write request includes an identifier of one of said plurality of streams. the write buffer includes a plurality of write buffer areas corresponding to the plurality of blocks;
2. The memory system according to claim 1, wherein said transfer request includes an identifier of said one write destination block and said storage location information. The controller no longer needs the first data stored in the write buffer when the multi-stage program operation is finished and the first data can be read from the nonvolatile memory. 2. The memory system of claim 1, configured to notify the host that A control method for controlling a non-volatile memory including a plurality of blocks, comprising:
receiving a write request from the host that includes storage location information indicating a location in a write buffer in the host's memory where the first data to be written is stored;
When writing the first data to the nonvolatile memory by a multi-stage program operation,
At each program operation of the multi-stage program operation,
obtaining the first data from the write buffer by transmitting a transfer request including the storage location information to the host;
transferring the first data to the non-volatile memory;
and writing the first data to a destination block of the plurality of blocks. When a read request for reading the first data is received from the host during a period from the start of writing the first data until the first data becomes readable, the write buffer outputs the first data. 10. The control method according to claim 9, further comprising sending an acquisition request requesting acquisition of one data to the host. the write buffer includes a plurality of write buffer areas corresponding to the plurality of blocks;
Further comprising notifying the host that the write buffer area in the write buffer corresponding to the one write destination block is no longer needed when the entire one write destination block is filled with data. The control method according to claim 9. 10. The control method according to claim 9, wherein said write request is received from said host via Ethernet (registered trademark). 10. The control method according to claim 9, wherein said write request includes a block identifier specifying a write destination block. the plurality of blocks are each associated with a plurality of streams;
10. The control method according to claim 9, wherein said write request includes an identifier of one of said plurality of streams. the write buffer includes a plurality of write buffer areas corresponding to the plurality of blocks;
10. The control method according to claim 9, wherein said transfer request includes an identifier of said one write destination block and said storage location information. When the multi-stage program operation is finished and the first data can be read from the nonvolatile memory, the host notifies that the first data stored in the write buffer is no longer needed. 10. The control method of claim 9, further comprising notifying the .

Images