JP2022179798A - Memory system and control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a memory system capable of improving I/O performance.

SOLUTION: A memory system includes a nonvolatile memory including a plurality of blocks each of which is an erasure operation unit and specified by a block number, and a controller which controls the nonvolatile memory. The controller determines a first position in a first block among the plurality of blocks specified by the first block number, writes first data in the first position in the first block, and notifies a host of a set of a first identifier for identifying the first data, the first block number, and a physical address in the first block indicating the first position according to reception of a write command specifying a command identifier, the first identifier, and the first block number from the host.

SELECTED DRAWING: Figure 2

COPYRIGHT: (C)2023,JPO&INPIT

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.

Recently, new interfaces between hosts and storage have begun to be proposed.

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, in general, the control of NAND flash memory is complicated, so when implementing a new interface to improve I/O performance, consider appropriate division of roles between the host and storage (memory system). is required.

A problem to be solved by the present invention is to provide a memory system and control method capable of improving I/O performance.

According to an embodiment, a memory system connectable to a host includes a nonvolatile memory including a plurality of blocks each being a unit of an erase operation and each designated by a block number; and a controller connected to control the nonvolatile memory. The controller, in response to receiving from the host a write command specifying a command identifier, a first identifier for identifying first data, and a first block number, determining a first position within a first block of the plurality of blocks designated by the block numbers of the blocks, and transferring the first data from the host to the first block within the first block; location to notify the host of a set of the first identifier, the first block number, and the first intra-block physical address indicating the first location.

2 is a block diagram showing the relationship between a host and a memory system (flash storage device) of the embodiment; FIG. FIG. 4 is a diagram for explaining role sharing between a conventional SSD and a host, and role sharing between a flash storage device and a host according to the same embodiment; 1 is a block diagram showing a configuration example of a computer system in which data transfer between multiple hosts and multiple flash storage devices is executed via network equipment; FIG. FIG. 2 is a block diagram showing a configuration example of the memory system of the same embodiment; FIG. 2 is a block diagram showing the relationship between a NAND interface provided in the memory system of the same embodiment and a plurality of NAND flash memory dies; FIG. 4 is a diagram showing a configuration example of a super block constructed by a set of multiple 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 an intra-block physical address (intra-block offset); A diagram for explaining a data read operation specifying and. FIG. 4 is a diagram for explaining write commands 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. 4 is a diagram for explaining a Trim command applied to the memory system of the embodiment; FIG. 4 is a diagram for explaining block numbers and offsets representing physical addresses; FIG. 4 is a diagram for explaining a write operation executed in response to a write command; FIG. FIG. 4 is a diagram for explaining a write operation that skips a defective page; FIG. 10 is a diagram for explaining another example of write operation skipping a defective page; FIG. 4 is a diagram for explaining an operation of writing a logical address and data pair to a page within a block; FIG. 4 is a diagram for explaining the operation of writing data to a user data area of a page within a block and writing the logical address of this data to a redundant area of this page; FIG. 4 is a diagram for explaining the relationship between block numbers and offsets when superblocks are used; FIG. 4 is a diagram for explaining a maximum block number get command applied to the memory system of the embodiment; FIG. 4 is a diagram for explaining a response to a maximum block number get command; FIG. 4 is a diagram for explaining a block size get command applied to the memory system of the embodiment; FIG. 4 is a diagram for explaining a response to a block size get command; FIG. FIG. 4 is a diagram for explaining a block allocate command (block allocation request) applied to the memory system of the embodiment; FIG. 4 is a diagram for explaining a response to a block allocate command; FIG. 4 is a sequence chart showing block information acquisition processing executed by the host and the memory system of the same embodiment; 4 is a sequence chart showing a sequence of write processing executed by the host and the memory system of the same embodiment; FIG. 4 is a diagram showing a data update operation of writing update data to data that has already been written; FIG. 4 is a diagram for explaining an operation of updating a block management table managed by the memory system of the embodiment; FIG. 4 is a diagram for explaining the operation of updating a lookup table (logical-physical address conversion table) managed by a host; FIG. 4 is a diagram for explaining the operation of updating the block management table in response to a notification from the host indicating the block number and physical address corresponding to data to be invalidated; FIG. 4 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 performed by the memory system of the same embodiment; FIG. 4 is a diagram for explaining the operation of reading data portions stored in different physical storage locations in response to a read command from the host; 4 is a sequence chart showing a sequence of read processing executed by the host and the memory system of the same embodiment; FIG. 4 is a diagram for explaining garbage collection (GC) control commands applied to the memory system of the embodiment; FIG. 4 is a diagram for explaining a GC callback command applied to the memory system of the embodiment; 4 is a sequence chart showing the procedure of garbage collection (GC) operations performed by the host and the memory system of the same embodiment; FIG. 4 is a diagram for explaining an example of data copy operation performed for garbage collection (GC); FIG. 38 is a diagram for explaining the contents of a host lookup table updated based on the result of the data copy operation in FIG. 37;

Embodiments will be described below with reference to the drawings.

First, the configuration of a computer system including a memory system according to one embodiment 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.

This computer system may include a host (host device) 2 and multiple flash storage devices 3 . The host 2 may be a server configured to use a flash array composed of multiple flash storage devices 3 as storage. A host (server) 2 and multiple flash storage devices 3 are interconnected via an interface 50 (internal interconnect). Interfaces 50 for this internal interconnection include, but are 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 functioning as the host 2 is 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. .

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 has (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-to-physical address translation table; It has (2) a function to hide read/write operations in units of pages and an erase operation in units of blocks, (3) a function to execute garbage collection (GC) of NAND flash memory, and the like. 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 NAND flash memory is also invisible to the host.

On the other hand, a kind of address translation (application level address translation) may also be performed 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 kind of GC (application level GC) that changes the data arrangement on the logical address space for SSD is executed in order to eliminate fragmentation occurring on the logical address space.

However, in a redundant configuration where the host and SSD each have an address translation table (the SSD has a lookup table that acts as a logical-physical address translation table, and the host has an application-level address translation table), these address translations A huge amount of memory resources are consumed to hold the table. Furthermore, double address translation including address translation on the host side and address translation on the SSD side also causes deterioration in I/O performance.

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

In order to solve such problems, it is possible to take a countermeasure to move all the FTL functions of the conventional SSD to the host.

However, implementing this countermeasure requires direct host handling of NAND flash memory blocks and pages. In the NAND flash memory, it is difficult for the host to directly handle the pages due to page write order restrictions. Also, in a NAND flash memory, a block may contain a defective page (bad page). Handling bad pages is even more difficult for the host.

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-to-physical address translation table, but the host 2 only specifies the block number of the block to which data is to be written and the logical address corresponding to this data, The flash storage device 3 determines the position within this block (write destination position) to which is to be written. The flash storage device 3 notifies the host 2 of the intra-block physical address indicating the determined position (write destination position) within the block.

In this way, the host 2 handles only blocks and locations within blocks (eg, pages, locations within pages) are handled by the flash storage device 3 .

When data needs to be written to the flash storage device 3, the host 2 selects a block number (or requests the flash storage device 3 to allocate a free block), the logical address and the block number of the selected block (or 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 the data from the host 2 to the block with the designated block number. In this case, the flash storage device 3 determines the position (write destination position) within this block, and writes the data from the host 2 to this position (write destination position) within this block. Then, the flash storage device 3 notifies the host 2 of the intra-block physical address indicating the position (write destination position) in this block as a response (return value) to the write request. In the following, the FTL functionality moved to host 2 is referred to as global FTL.

The global FTL of the host 2 includes a function for executing storage services, a hardware control function, a function for achieving high availability, and a duplicate elimination (De -duplication) function, garbage collection (GC) block selection function, QoS control function, and the like. 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 a single or a plurality of access units (grains), and the host 2, if the flash storage device 3 supports a plurality of access units, QoS domain-by-QoS domain (or block-by-block ), the flash storage device 3 can be instructed which access unit to use.

Also, the QoS control function includes a function for preventing performance interference between QoS domains as much as possible. This function is basically a function for maintaining stable latency.

On the other hand, the flash storage device 3 can perform low-level abstraction (LLA). LLA is a function for abstraction of NAND flash memory. LLA includes a function to hide defective pages (bad pages) and a function to observe page write order constraints. LLA also includes a GC execution function. 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) within the GC destination block to which valid data should be written, and writes the valid data within the GC source block to the copy destination position within 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 part of FIG. 2 represents the hierarchical structure of the entire computer system including the conventional SSD and the host that executes the virtual disk service.

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

Also, 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, an application level address translation table is also used to translate application level logical addresses into logical addresses for SSD. Additionally, an application level GC 104 is also executed in the host.

The transmission of a command from the host (server) to the conventional SSD and the return of the command completion response from the conventional SSD to the host (server) are performed by the I/O queues 200 that exist in each of the host (server) and the conventional SSD. is executed via

A conventional SSD includes a write buffer (WB) 301 , a lookup 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 resources of a NAND flash memory (NAND flash array) 304 are shared by multiple virtual disk services 103 .

In this configuration, duplicate GCs including the application level GC 104 under the virtual disk service 103 and the garbage collection function 303 (LUT level GC) within the traditional SSD increase the write amplification. Also, in a conventional SSD, an increase in the amount of data written from one end user or one virtual disk service 103 increases the frequency of GC, thereby increasing the I/O performance for other end users or other virtual disk services 103 . can lead to noisy neighbor problems.

Also, a lot of memory resources are consumed due to the existence of redundant resources including the application level address translation table in each virtual disk service and the LUT 302 in the traditional SSD.

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

The host (server) 2 runs a virtual machine service 401 for providing a plurality of virtual machines to a plurality of end users. Each virtual machine on the virtual machine service 401 runs an operating system and user applications 402 used by the corresponding end user.

Also, 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 a key. may be

For LBA-based block I/O services, a LUT 411 that manages the mapping between each logical address (LBA) and each physical address of the flash storage device 3 may be used.

In the key-value store service, each logical address (that is, a tag such as a key) and the data corresponding to these logical addresses (that is, a tag such as a key) are stored in the physical storage device 3. A LUT 411 may be used that manages the mapping between each physical address that indicates a storage location. The LUT 411 may manage the correspondence between the tag, the physical address where the data identified by this tag is stored, and the data length of this data.

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

Each of these LUTs 411 does not translate each logical address from the user application 402 into each logical address for the flash storage device 3, but translates 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 translating a logical address for the flash storage device 3 into a physical address and an application level address translation table are integrated (merged).

Each I/O service 403 also includes a GC block selection function. The GC block selection function can use the corresponding LUT to manage the effective data amount of each block and thereby select the GC source block.

In the host (server) 2, an I/O service 403 may exist for each QoS domain described above. For I/O services 403 belonging to a certain QoS domain, each logical address used by the user application 402 in the corresponding QoS domain and each block number of the block group belonging to the resource group assigned to the corresponding QoS domain. may manage the mapping of

Sending a command from the host (server) 2 to the flash storage device 3 and returning a command completion response from the flash storage device 3 to the host (server) 2 are sent to the host (server) 2 and the flash storage device 3 respectively. It is executed through existing I/O queues 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 a NAND flash memory (NAND flash array) 603. include.

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

On the other hand, the position within the block to which the data should be written is determined by the flash storage device 3, not by the upper hierarchy (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.

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 of FIG. 3, the storage management function of host (server) 2 of FIG. 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 integrated (merged) logical-physical address conversion table described above. 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 resource assigned to itself. do. This configuration thus allows the system to be easily scaled out.

The global FTL of each host 2A has a lookup 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 consumption of each flash storage device 3, a NAND resource allocation function for allocating reserved storage resources (NAND resources) to each host 2A, a QoS control function, and a global clock management function. function, etc.

A low-level abstraction (LLA) of each flash storage device 3 has a function to hide defective pages (bad pages), a function to observe page write order restrictions, a function to manage write buffers, a GC execution function, and the like.

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 I/O requests to one or more flash storage devices 3 assigned to itself. and the operation of receiving a response from the flash storage device 3 need only be performed. In other words, data transfer between multiple hosts 2A and multiple flash storage devices 3 is executed only through network switch 1, and manager 2B is not involved in this data transfer. Also, as described above, the contents of the LUTs managed by each host 2A are independent of each other. Therefore, the number of hosts 2A can be easily increased, and a scale-out system configuration can be realized.

FIG. 4 shows a configuration example of the flash storage device 3. As shown in FIG.

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 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 NAND interface 13 such as Toggle, an open NAND flash interface (ONFI). The controller 4 is a memory controller (control circuit) configured to control the NAND flash memory 5 .

The NAND flash memory 5 includes multiple NAND flash memory dies, as shown in FIG. Each NAND-type flash memory die is a non-volatile memory die that includes a memory cell array including a plurality of blocks BLK and peripheral circuits that control the memory cell array. Individual NAND flash memory dies can operate independently. Thus, a NAND flash memory die functions as a parallel operation unit. NAND flash memory dies are also referred to as "NAND flash memory chips" or "non-volatile memory chips." 5, 16 channels Ch1, Ch2, . . . Ch16 are connected to the NAND interface 13, and each of these channels Ch1, Ch2, . The case where each flash memory die is connected is illustrated. 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-#32 via channels Ch1, Ch2, . . . Ch16. The controller 4 can drive channels Ch1, Ch2, . . . Ch16 simultaneously.

The 16 NAND flash memory dies #1-#16 connected to channels Ch1-Ch16 may be organized as a first bank, and the remaining 16 NAND flash memory dies connected to channels Ch1-Ch16. Memory die #17-#32 may be organized as a second bank. A bank functions as a unit for operating a plurality of 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 super blocks), each of which is composed of a plurality of blocks BLK, and may perform an erase operation in units of super blocks. .

A 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-#32 has a multi-plane configuration including two planes, then one super block is 64 superblocks corresponding to the NAND flash memory dies #1-#32. A total of 64 blocks BLK selected one by one from the planes may be included. In FIG. 6, one super block SB is a total of 32 blocks BLK (blocks BLK surrounded by thick frames in FIG. 5) selected one by one from NAND flash memory dies #1 to #32. The case where it consists of is illustrated.

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 .

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). 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 , NAND interface 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 write operation control section 21 , a read operation control section 22 and a GC operation control section 23 . The write operation control unit 21, the read operation control unit 22, and the GC operation control unit 23 are equipped with an application program interface (API) for realizing the system configuration shown in the right part of FIG.

The write operation control unit 21 receives from the host 2 a write request (write command) specifying a block number and a logical address. A logical address is an identifier that can identify data (user data) to be written, and may be, for example, an LBA, a tag such as a key in a key-value store, or a key. It may be a hash value. A block number is an identifier that specifies the block to which this data is to be written. Various values that can uniquely identify any one of a plurality of blocks can be used as the block number. A block designated by a block number may be a physical block or a super block as described above. When a write command is received, the write operation control unit 21 first determines the position (write destination position) within the block (write destination block) having the specified block number where the data from the host 2 should be written. . Next, the write operation control unit 21 writes the data (write data) from the host 2 to the write destination position of 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 intra-block physical address indicating the write destination position of the write destination block. This intra-block physical address is represented by an intra-block offset that indicates the write destination position within this write destination block.

In this case, the intra-block offset indicates the offset from the beginning of the write destination block to the write destination location, that is, the offset of the write destination location relative to the beginning of the write destination block. The size of the offset from the beginning of the write destination block to the write destination position is indicated by a multiple of the granularity (Grain) having a size different from the page size. Granularity (Grain) is the access unit described above. 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 location in multiples of granularity having a size different from the page size.

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

Alternatively, the grain 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.

Thus, 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, a block number, and an intra-block physical address (intra-block offset). may be notified to

Therefore, the flash storage device 3 can hide page write order restrictions, bad pages, page sizes, etc., while allowing the host 2 to handle block numbers.

As a result, the host 2 can recognize block boundaries, but can manage which user data exists in which block number without being aware of page write order restrictions, 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 offset within the block) from the host 2, based on the block number and the offset within the block, the read operation control unit 22 selects a read target. Read data from the physical storage location to be read within the block. A block to be read is specified by a 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 to the number of grains representing the page size (when the page size is 16 Kbytes and the grain is 4 Kbytes). Alternatively, the number of granularities representing the page size may be divided by 4), and the quotient and remainder resulting from this division may be determined as the page number to be read and the offset within the page to be read, respectively.

The GC operation control unit 23 receives a GC control command specifying 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 from the host 2. When received, a block having a specified copy source block number and a block having a specified copy destination block number are transferred from a plurality of blocks in the NAND flash memory 5 to 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 within the GC destination block to which the valid data stored in the selected GC source block should be written, and copies the valid data to the copy destination position within 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 in 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 example, for each block. The block management table 32 corresponding to a certain block stores bitmap flags indicating validity/invalidity of each data in the block. Here, valid data means data that is linked as the latest data from the logical address and that may be read from the host 2 later. Invalid data means data that can no longer be read from the host 2 . For example, data associated with a logical address is valid data, and data 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 valid data stored in the copy source block (GC source block) should be written. and copy the valid data to this determined location (destination location) of the destination block (GC destination block). In this case, the GC operation control unit 23 may copy both 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, the GC operation control unit 23 can easily acquire the logical address of each data in the copy source block (GC source block) from this copy source block (GC source block), so that the copied valid data can easily notify the host 2 of the logical address of

The NAND interface 13 is a memory control circuit configured to control the NAND flash memory 5 under control of the 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 the write buffer (WB) 31 . Another part of the storage area of the DRAM 6 is used for storing the block management table 32. FIG. The write buffer (WB) 31 and block management table 32 may be stored in an SRAM (not shown) within the controller 4 .

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

A data write operation is performed in the following procedure.

(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 free blocks. good. The controller 4 of the flash storage device 3 includes a block allocator 701 that manages the free block group 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 where 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 to the flash storage device 3 a write request 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 writing data. When the page allocation unit 702 receives a write request, the page allocation unit 702 assigns an intra-block physical address (intra-block PBA) indicating a write destination location in a block (write destination block) having a block number specified by the write request. to decide. An 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 the logical address (LBA) corresponding to the write data, the block number (BLK#) of the write destination block, and the intra-block PBA (offset) indicating the write destination position as a response to the write request. may be notified to the host 2 as In other words, the controller notifies the host 2 of either an intra-block physical address or a set of a logical address, a block number, and an intra-block physical address. In the host 2, the LUT 411 is updated so that the physical address (block number, intra-block physical address (in-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.

A data read operation is executed in the following procedure.

(1) 'When the host 2 needs to read data from the flash storage device 3, the host 2 refers to the LUT 411 and refers to the physical address (block number, within the block) corresponding to the logical address of the data to be read. Physical address (offset within block)) is obtained from the LUT 411 .

(2)' The host 2 sends to the flash storage device 3 a read request designating the acquired 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 physical address in the block. Data is read from the read target physical storage location in the read target block.

FIG. 8 shows write commands applied to the flash storage device 3 .

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

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 write commands.

The block number BLK# is an identifier (block address) that can uniquely identify a block into which data is to be written.

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

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 its size by bytes.

Upon receiving a write command from the host 2, the controller 4 determines the write destination location 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 responses to the write commands of FIG.

This response includes the physical address within the block and the length. The intra-block physical address indicates the location (physical storage location) within the block where the data is written. An intra-block physical address can be specified by an intra-block offset, as described above. Length indicates the length of the data written. This length (data length) may be specified by the number of grains, the number of LBAs, or its size by bytes.

Alternatively, this response may further include not only the intra-block physical address and length, 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. As shown in FIG.

This Trim command is a command containing a block number and an intra-block physical address (intra-block offset) indicating a physical storage location where data to be invalidated is stored. In other words, this Trim command can specify a physical address instead of a logical address like 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 by bytes.

The controller 4 uses the block management table 32 to manage flags (bitmap flags) indicating validity/invalidity of each data included in each of the plurality of blocks. When a Trim command including a block number and an offset (intra-block offset) indicating a physical storage location where data to be invalidated is received from the host 2, the controller 4 updates the block management table 32 to perform a Trim command. The flag (bitmap flag) corresponding to the data in the physical storage location corresponding to the block number and intra-block offset included in the command is changed to a value indicating invalid.

FIG. 11 shows intra-block offsets that define intra-block physical addresses.

The block number designates 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. be.

Offset +0 indicates the first 4 KB region of page 0, Offset +1 indicates the second 4 KB region of page 0, Offset +2 indicates the third 4 KB region of page 0, Offset +3 indicates the fourth 4 KB region of page 0 A 4 KB region is shown.

Offset +4 indicates the first 4 KB region of page 1, offset +5 indicates the second 4 KB region of page 1, offset +6 indicates the third 4 KB region of page 1, offset +7 indicates the fourth 4 KB region of page 1. A 4 KB region is shown.

FIG. 12 shows a write operation performed in response to a write command.

Assume now that the block BLK#1 is assigned as the write destination block. The controller 4 writes data to the block BLK#1 page by page in the order of page 0, page 1, page 2, . . . page n.

In FIG. 11, 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. It is assumed that a write command to write is received from the host 2 . The controller 4 determines page 1 of block BLK#1 as the write destination position, and writes 16 Kbytes worth of write data received from the host 2 to page 1 of block BLK#1. Then, the controller 4 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 (intra-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 (offset within block) is +5, and the length is four.

FIG. 13 illustrates a write operation that skips defective pages (bad pages).

In FIG. 13, the block number (=BLK#1), the logical address (LBAx+1) and the length (=4) are specified with data already written to page 0 and page 1 of block BLK#1. It is assumed that a write command is received from host 2 . If page 2 of block BLK#1 is a defective page, controller 4 determines page 3 of block BLK#1 as the write destination position, and writes 16 Kbytes of write data received from host 2 to block BLK. Write to page 3 of #1. Then, the controller 4 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 (intra-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 (offset within block) is +12, and the length is four.

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. Assume that data has already been written to page 0 and page 1 of block BLK#2, and 8 Kbytes of unwritten write data remains in the write buffer 31. FIG. In this state, if a write command specifying a block number (=BLK#2), a logical address (LBAy) and a length (=6) is received, the controller 4 outputs unwritten 8 Kbyte write data, Using the first 8 Kbyte write data in the 24 Kbyte write data newly received from the host 2, prepare 16 Kbyte write data corresponding to the page size. The controller 4 then writes the prepared 16-Kbyte write data to page 2 of block BLK#2.

If next page 3 of block BLK#2 is a bad page, controller 4 determines page 4 of block BLK#2 as the next write destination location and write the remaining 16 Kbytes of write data to page 4 of block BLK#2.

The controller 4 then 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 responds to this write command with LBAy, block number (=BLK#2), offset (=+10), length (=2), block number (=BLK#2), offset (=+16). ) and the length (=4) may be returned to the host 2 .

15 and 16 show the operation of writing a logical address and data pair to a page 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 4 KB user data and the logical address (for example, LBA) corresponding to this 4 KB user data to the write destination block BLK. In this case, as shown in FIG. 15, four data sets, each containing LBA and 4KB user data, may be written to the same page. Intra-block offsets may indicate set boundaries.

Alternatively, as shown in FIG. 16, four 4 KB user data are written to the user data area within the page, and four LBAs corresponding to these four 4 KB user data are written to the redundant area within this page. may

FIG. 17 shows the relationship between block numbers and offsets (intra-block offsets) when superblocks are used. In the following, intra-block offsets are also referred to simply 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, page 1 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 4 KB area of page 0 of block BLK#11, offset +1 indicates the second 4 KB area of page 0 of block BLK#11, and offset +2 indicates the third of page 0 of block BLK#11. offset +3 indicates the fourth 4 KB area of page 0 of block BLK#11.

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

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

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

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

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

FIG. 18 shows the maximum block number get command applied to the flash storage device 3 .

The maximum block number get command is a command for obtaining 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 get maximum block number command contains the command ID for the get maximum block number command and does not contain any parameters.

FIG. 19 shows the 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. This response includes a parameter indicating the maximum block number (ie total number of available blocks contained in flash storage device 3).

FIG. 20 shows the get block size command applied to the flash storage device 3 .

A block size get command is a command for acquiring a 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 get block size command may include a parameter specifying the block number. When receiving a block size get command specifying a certain block number from the host 2, the flash storage device 3 returns to the host 2 the block size of the block having this block number. As a result, even if the block sizes of the blocks included in the NAND flash memory 5 are uneven, the host 2 can recognize the block size of each individual block.

FIG. 21 shows the response to the get block size command.

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

FIG. 22 shows the block allocation commands applied to the flash storage device 3. FIG.

A 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). can be done.

In the case where the flash storage device 3 manages the free block group by the free block list and the host 2 does not manage the free block group, the host 2 requests the flash storage device 3 to allocate the free block, thereby get the number. On the other hand, in the case where the host 2 manages the free block group, 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 a 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 flash storage device 3 controller returns the maximum block number to the host 2 . Maximum block number indicates the total number of blocks available. Note that in the case where superblocks are used as described above, the maximum block number may indicate the total number of superblocks available.

The host 2 then sends a get block size command to the flash storage device 3 to get the block size. In this case, the host 2 sends a block size get command designating block number 1, a block size get command designating block number 2, a block size get command designating block number 3, . to obtain the block size of each block individually.

By this block information acquisition processing, the host 2 can recognize the number of usable blocks and the block size of each block.

FIG. 25 shows the sequence of write operations performed by the host 2 and the 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. demand. Then, the host 2 sends a write command including the block number BLK# of the block selected by itself (or the block number BLK# of the free block assigned by the flash storage device 3), the logical address (LBA), and the length. It 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 selects the write destination location within the block (write destination block BLK#) having this block number BLK# where the write data from the host 2 should be written. is determined, and the 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 sets a bitmap flag corresponding to the written data (that is, a bit corresponding to the offset (in-block offset) to which this data is written). map flag) is changed from 0 to 1 (step S12).

For example, as shown in FIG. 26, assume that 16K bytes of update data with a starting LBA of LBAx were written to physical storage locations corresponding to offsets +4 to +7 of block BLK#1. In this case, as shown in FIG. 27, the bitmap flags corresponding to offsets +4 to +7 are changed from 0 to 1 in the block management table for block BLK#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 to map the 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 (eg, LBAs). An entry corresponding to a certain logical address (for example, a certain LBA) contains a physical address PBA indicating the location (physical storage location) in the NAND flash memory 5 where the data corresponding to this LBA is stored, that is, block number, offset (offset in block) is stored. As shown in FIG. 26, if 16K bytes of update data with a starting LBA of LBAx were written to physical storage locations corresponding to offsets +4 to +7 of block BLK#1, then FIG. , the LUT 411 is updated so that the entry corresponding to LBAx stores BLK#1 and offset +4, the entry corresponding to LBAx+1 stores BLK#1 and offset +5, and the entry corresponding to LBAx+2 stores BLK#1. , 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 thereafter sends a Trim command to the flash storage device 3 to invalidate the previous data that has become unnecessary due to the above-described writing of the update data. As shown in FIG. 26, if the previous data is stored at positions corresponding to offset +0, offset +1, offset +2, and offset +3 of block BLK#0, as shown in FIG. A Trim command specifying a 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 according to this Trim command (FIG. 25, step S14). In step S15, as shown in FIG. 29, bitmap flags corresponding to offsets +0 to +3 are changed from 1 to 0 in the block management table for block BLK#0.

FIG. 30 shows read commands applied to the flash storage device 3 .

A 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 read commands.

Physical address PBA indicates the first physical storage location from which data is to be read. A 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 memory location within the host 2 to which the read data should be transferred.

One read command can specify multiple sets 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), offset (=+5), and 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 data for one page size from page 1 of BLK#2, and extracts data d1 to data d3 from this read data. Controller 4 then transfers data d1 to data d3 to 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 block number (=BLK#2), offset (=+10), length (=2), block number (=BLK#2), offset (=+16), and length (=4) are specified. It is assumed that a command is received from host 2 . The controller 4 of the flash storage device 3 reads data of one page size from page 2 of BLK#2 based on the block number (=BLK#2), offset (=+10), and length (=2). , data d1 to data d2 are extracted from this read data. Next, based on the block number (=BLK#2), the offset (=+16), and the length (=4), the controller 4 generates data for one page size from page 4 of BLK#2 (data d3 to data d6 ). Then, the controller 4 transfers read data of length (=6) obtained by combining data d1 to data d2 and data d3 to data d6 in the host memory specified by the transfer destination pointer in the read command. transfer to

This allows the data portion to be read from a separate physical storage location without causing a read error even if there are bad pages in the block. Also, even if data is written across two blocks, this data can be read by issuing one read command.

FIG. 33 shows a read processing sequence executed by the host 2 and the 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. The host 2 then sends a read command designating 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 specifies the block by this read command. A page to be read is determined based on the obtained offset (step S31). In step S31, the controller 4 may first divide the offset specified by the read command by the number of granularities representing the page size (here, 4). Then, the controller 4 may determine the quotient and remainder obtained by this division as the page number to be read and the offset position within the page to be read, 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. FIG.

The GC control command is used to notify the flash storage device 3 of the GC source block number and 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. Also, the host 2 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 so on.

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 GC control commands.

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

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

FIG. 35 shows callback commands for GC.

The GC callback command is used to notify the host 2 of the logical address of valid data copied by GC and the block number and offset indicating the copy destination position of this valid data.

A GC callback command may include a command ID, a logical address, a length, and a 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 the command ID for the GC callback command.

The logical address indicates the logical address of valid data copied by the GC from the GC source block to the GC destination block.

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 to which valid data was copied. The destination physical address is specified by block number and offset (intra-block offset).

FIG. 36 shows the procedure of garbage collection (GC) operation.

For example, host 2 selects a GC source block and a GC destination block when the number of remaining free blocks contained in the free block list managed by host 2 drops below a threshold, and the selected GC A GC control command specifying the source block and the selected GC destination block is sent to the flash storage device 3 (step S41). Alternatively, in a configuration in which the write processing unit 412 manages the free block group, when the number of remaining free blocks falls below the 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 transmission of 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 and copying the valid data to the copy destination location in the GC destination block (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) to the GC. Copy to the destination block (destination block). As a result, pairs of data and logical addresses can be held in the GC destination block (copy destination block).

Also, in step S51, the data copy operation is repeatedly executed until copying of all valid data in the GC source block is completed. 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 have been copied.

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

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

FIG. 37 shows an example of a data copy operation performed for GC.

In FIG. 37, the valid data (LBA=10) stored at the position corresponding to the offset +4 of the GC source block (block BLK#50 here) is the offset of the GC destination block (block BLK#100 here). The valid data (LBA=20) copied to the position corresponding to +0 and stored in the position corresponding to offset +10 of the GC source block (here, block BLK#50) is copied to the GC destination block (here, block BLK#50). #100) is copied to a position corresponding to offset +1. In this case, the controller 4 notifies {LBA10, BLK#100, offset (=+0), LBA20, BLK#100, offset (=+1)} to the host (GC callback processing).

FIG. 38 shows the contents of the LUT 411 of host 2 updated based on the results of the data copy operation of FIG.

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 the offset (=+4) to the flash storage device 3, and stores it at the position corresponding to the offset (=+4) of BLK#50. You may invalidate the data that is Further, the host 2 transmits a Trim command specifying BLK#50 and offset (=+10) to the flash storage device 3, and trims the data stored at the position corresponding to the offset (=+10) of BLK#50. You can disable it. Alternatively, without sending the Trim command from the host 2, the controller 4 may update the block management table 32 as part of the GC processing to invalidate these data.

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

Therefore, the host 2 handles the block number, and the flash storage device 3 considers page write order constraints/bad pages, etc., and writes the destination location (intra-block offset) within the block with the block number specified by the host 2. can be realized. By handling the block number by the host 2, it is possible to merge the application level address translation table of the upper hierarchy (host 2) and the LUT level address translation table of the conventional SSD. Also, the flash storage device 3 can control the NAND flash memory 5 considering the features/constraints of the NAND flash memory 5 . Furthermore, since the host 2 can recognize block boundaries, user data can be written into each block taking into account block boundaries/block sizes. As a result, the host 2 can perform control such as invalidating data in the same block all at once by data update or the like, so it is possible to reduce the frequency with which GC is executed. As a result, the write amplification is lowered, the performance of the flash storage device 3 is improved, and the life of the flash storage device 3 is maximized.

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

Further, when a control command specifying a copy source block number and a copy destination block number for garbage collection is received from the host 2, the controller 4 of the flash storage device 3 selects the first block number having the copy source block number from a plurality of blocks. 2 and a third block having the destination block number, determine the destination location within the third block where the valid data stored in the second block is to be written, and copy the valid data to the third block. Copy to the copy destination position of the block of 3. The controller notifies the host 2 of the logical address of the valid data, the copy destination block number, and the second intra-block physical address indicating the copy destination position within the third block. As a result, even in GC, a configuration can be realized in which the host 2 handles only 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 the storage array. A storage array may be connected to an information processing device such as a server computer via a cable or network. The storage array includes a controller that controls multiple flash storage devices 3 within the storage array. When 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.

Moreover, in this embodiment, the 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, 3 Flash Storage Device, 4 Controller, 5 NAND Flash Memory, 21 Write Operation Control Unit, 22 Read Operation Control Unit, 23 GC Operation Control Unit.

Claims (20)

A memory system connectable to a host,
a nonvolatile memory including a plurality of blocks each being a unit of an erase operation and each designated by a block number;
a controller electrically connected to the nonvolatile memory and controlling the nonvolatile memory;
The controller is
In response to receiving from the host a write command specifying a command identifier, a first identifier for identifying first data, and a first block number,
determining a first location within a first block of the plurality of blocks designated by the first block number;
writing the first data from the host to the first location in the first block;
A memory system configured to notify the host of a set of the first identifier, the first block number, and a first intra-block physical address indicating the first location. The controller further writes the first identifier to the first location in the first block in response to the write command;
When the controller receives a control command designating a copy source block number and a copy destination block number from the host, the controller selects a second block having the copy source block number and the copy destination block number from the plurality of blocks. determining a copy destination location within the third block to which valid data stored in the second block is to be written; reading valid data and an identifier of the valid data, copying the read valid data and the identifier of the valid data to the copy destination location of the third block, and copying the identifier of the valid data and the copy destination block; 2. The memory system according to claim 1, further configured to notify said host of a set of a number and a second intra-block physical address indicating said copy destination location. 3. The memory system according to claim 2, wherein the offset from the beginning of said second block to the location where said valid data was stored and the offset from the beginning of said third block to said copy destination location are different from each other. When the controller receives a read command designating the first block number and the first intra-block physical address from the host, the controller reads the read command based on the first block number and the first intra-block physical address. 2. The memory system of claim 1, further configured to read data from said first location within said first block. each of the plurality of blocks includes a plurality of pages;
The first intra-block physical address is represented by a first intra-block offset that indicates an offset from the beginning of the first block to the first location in multiples of granularity having a size different from a page size. 2. The memory system of claim 1. The controller is
managing a free block group among the plurality of blocks;
2. The apparatus is further configured to allocate one free block of the free block group to the host and notify the host of the block number of the allocated block when a block allocation command is received from the host. The described memory system. The controller is
if a first command requesting a maximum block number is received from the host, notifying the host of the maximum block number indicating the number of the plurality of blocks;
2. The memory system of claim 1, further configured to notify the host of the block size of each of the plurality of blocks when a second command requesting a block size is received from the host. The controller is configured to, if a block number is included in the second command, notify the host of a block size of a block having the block number included in the second command. 8. The memory system of claim 7. 2. The memory system of claim 1, wherein said block number is specified as a physical address. 2. The memory system of claim 1, wherein said first identifier is specified as a logical address. A control method for controlling, by a controller, a nonvolatile memory including a plurality of blocks, each of which is a unit of erase operation and each of which is designated by a block number, comprising:
In response to receiving from the host a write command specifying a command identifier, a first identifier for identifying first data, and a first block number,
determining a first location within a first block of the plurality of blocks designated by the first block number;
writing the first data from the host to the first location within the first block;
and notifying the host of a set of the first identifier, the first block number, and the first intra-block physical address indicating the first location. further writing the first identifier to the first location within the first block in response to the write command;
When a control command specifying a copy source block number and a copy destination block number is received from the host,
selecting a second block having the copy source block number and a third block having the copy destination block number from the plurality of blocks;
determining a destination location within the third block to which valid data stored in the second block is to be written;
reading the valid data and the identifier of the valid data stored in the second block, and copying the read valid data and the identifier of the valid data to the copy destination location of the third block; When,
12. The control method according to claim 11, further comprising notifying said host of a set of said valid data identifier, said copy destination block number, and a second intra-block physical address indicating said copy destination position. . 13. The control method according to claim 12, wherein the offset from the beginning of said second block to the location where said valid data was stored and the offset from the beginning of said third block to said copy destination location are different from each other. When a read command designating the first block number and the first intra-block physical address is received from the host, the first block number and the first intra-block physical address are read based on the first block number and the first intra-block physical address. 12. The control method of claim 11, further comprising reading data from said first location within a block. each of the plurality of blocks includes a plurality of pages;
The first intra-block physical address is represented by a first intra-block offset that indicates an offset from the beginning of the first block to the first location in multiples of granularity having a size different from a page size. 12. The control method according to claim 11. managing a free block group among the plurality of blocks;
12. Allocating one free block of the free block group to the host and notifying the host of the block number of the allocated block when a block allocation command is received from the host. Described control method. notifying the host of a maximum block number indicating the number of the plurality of blocks when a first command requesting a maximum block number is received from the host;
12. The control method according to claim 11, further comprising notifying said host of the block size of each of said plurality of blocks when a second command requesting a block size is received from said host. 18. The control method according to claim 17, wherein when the second command includes a block number, the host is notified of the block size of the block having the block number included in the second command. 12. The control method according to claim 11, wherein said block number is specified as a physical address. 12. A control method according to claim 11, wherein said first identifier is specified as a logical address.

Images