Storage system and method for controlling nonvolatile memory

Abstract

An embodiment of the present invention realizes a storage system capable of obtaining useful information related to the control of a non-volatile memory and a method for controlling a non-volatile memory. The storage system of the embodiment performs a first allocation action of allocating a plurality of first blocks in a plurality of blocks of a non-volatile memory to a first namespace. In response to receiving a command from a host for reading, writing or deleting one of the plurality of first blocks, the controller performs a read action, a write action, or a delete action on one of the plurality of first blocks, counts the number of delete actions performed on the plurality of first blocks, and in response to receiving a command from the host requesting the host to obtain the number of delete actions associated with the first namespace, notifies the host of the count value of the number of delete actions.

Description

[0001] Information about divisional applications

[0002] This case is a divisional application. The parent case of the divisional application is an invention patent application with application date of July 25, 2016, application number 201610592346.4, and invention name “storage system, information processing system and control method of non-volatile memory”.

[0003] [Related applications]

[0004] The present application claims the priority of Japanese Patent Application No. 2016-44261 (filing date: March 8, 2016) as a basic application, and the present application incorporates the entire contents of the basic application by reference. Technical Field

[0005] Embodiments of the present invention relate to a storage system, an information processing system, and a control method for a non-volatile memory. Background Art

[0006] In recent years, storage systems with non-volatile memory have been widely used. As one of such storage systems, solid-state drives (SSDs) based on NAND flash memory technology are well known. SSDs are used as main storage for various computers due to their low power consumption and high performance.

[0007] Recently, attempts have been made to control nonvolatile memories using a host.

[0008] However, in order to allow the host to control the nonvolatile memory, it is required to realize a new function for obtaining useful information related to the control of the nonvolatile memory. Summary of the invention

[0009] Embodiments of the present invention provide a storage system, an information processing system, and a control method for a nonvolatile memory capable of acquiring useful information related to the control of a nonvolatile memory.

[0010] The storage system of the embodiment comprises a nonvolatile memory including a plurality of blocks, and a controller electrically connected to the nonvolatile memory. The controller performs a first allocation action of allocating a plurality of first blocks in the plurality of blocks to a first namespace. In response to receiving a command from a host for reading, writing or deleting one of the plurality of first blocks, the controller performs a read action, a write action, or a delete action on one of the plurality of first blocks, counts the number of delete actions performed on the plurality of first blocks, and in response to receiving a command from the host requesting to obtain the number of delete actions associated with the first namespace, notifies the host of the count value of the number of delete actions. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 This is a block diagram showing a configuration example of an information processing system including a storage system according to an embodiment.

[0012] Figure 2 is a block diagram showing host software for controlling the storage system of the embodiment.

[0013] Figure 3 This is a block diagram showing the relationship between a NAND interface and a plurality of NAND memory chips in the storage system of the embodiment.

[0014] Figure 4 The diagram shows a block group for a physical NAND access management application program interface (API) and a block group for a virtual NAND access management application program interface (API) managed by the storage system of the embodiment.

[0015] Figure 5 This is a diagram showing the structure of a virtual block managed by the storage system according to the embodiment.

[0016] Figure 6 This is a diagram showing a deletion count management table maintained in the storage system of the embodiment for managing the deletion count of each block.

[0017] Figure 7 This is a diagram showing another deletion count management table maintained in the storage system of the embodiment for managing the deletion count of each virtual block.

[0018] Figure 8 This is a diagram showing another deletion count management table maintained in the storage system of the embodiment for managing the deletion count of each name space.

[0019] Fig. 9 It is a diagram showing a physical block structure information table maintained in the storage system of the embodiment.

[0020] Fig.10 It is a diagram showing a virtual block structure information table maintained in the storage system of the embodiment.

[0021] Fig.11 It is a diagram showing a namespace information table for a physical NAND access management API maintained in the storage system of the embodiment.

[0022] Fig.12 It is a diagram showing a namespace information table for a virtual NAND access management API maintained in the storage system of the embodiment.

[0023] Fig.13This is a diagram for explaining the relationship between a virtual block in the storage system of the embodiment and the block addresses of each block constituting the virtual block.

[0024] Fig.14 This is a diagram for explaining a bad block replacement operation performed by the storage system of the embodiment.

[0025] Fig.15 This is a diagram showing a bad block command used in a physical NAND access management API of the storage system according to the above embodiment.

[0026] Fig.16 This is a diagram showing a bad block command used in a virtual NAND access management API of the storage system according to the above embodiment.

[0027] Fig.17 This is a flowchart showing the procedure of bad block processing executed by the storage system of the embodiment.

[0028] Fig.18 This is a diagram showing a processing sequence for physical NAND access and virtual NAND access executed by the storage system and the host according to the above embodiment.

[0029] Fig.19 This is a diagram showing a processing sequence of a write process for physical NAND access executed by the storage system and the host according to the above-described embodiment.

[0030] Fig. 20 This is a diagram showing a processing sequence of a write process for virtual NAND access executed by the storage system and the host according to the above embodiment.

[0031] Fig.21 This is a diagram showing a processing sequence of a read process for physical NAND access executed by the storage system and the host according to the above-described embodiment.

[0032] Fig. 22 This is a diagram showing a processing sequence of a read process for virtual NAND access executed by the storage system and the host according to the above-described embodiment.

[0033] Fig.23 This is a diagram showing a processing sequence of a delete process for physical NAND access executed by the storage system and the host according to the above-described embodiment.

[0034] Fig.24 This is a diagram showing a processing sequence of a deletion process for virtual NAND access executed by the storage system and the host according to the above-described embodiment.

[0035] Fig.25 This is a diagram for explaining the command priority management operation executed by the storage system of the embodiment.

[0036] Fig.26 It is a diagram showing block allocation and deletion commands applied to the storage system of the embodiment.

[0037] Fig. 27 The diagram shows an in-use block list, a free block list, an in-use virtual block list, and a free virtual block list managed by the storage system of the embodiment.

[0038] Fig.28 This is a diagram showing a processing sequence of block allocation and deletion processing executed by the storage system and the host according to the above-described embodiment.

[0039] Fig.29 It is a diagram showing a write command used in a physical NAND access management API applied to the storage system of the above-described embodiment.

[0040] Fig.30 It is a diagram showing a write command for a virtual NAND access management API applied to the storage system of the above-described embodiment.

[0041] Fig.31 This is a diagram for explaining constraints on the order of writing data to a plurality of pages within a block.

[0042] Fig.32 This is a diagram for explaining constraints on the timing of reading data from a page.

[0043] Fig.33 This is a diagram for explaining an example of a programming operation including a plurality of writing phases executed by the NAND memory of the storage system according to the above-described embodiment.

[0044] Fig.34 This is a flowchart showing the procedure of data writing processing executed by the storage system of the embodiment.

[0045] Fig.35 Detailed Description of the Invention This is a flowchart showing the order of processing performed by the host in response to reception of a command completion response to a write command.

[0046] Fig.36 is a flowchart showing the order of processing performed by the host in response to receiving a command completion response to a write command including a name space identifier (NSID).

[0047] Fig.37 It is a diagram showing a read command used in a physical NAND access management API of the storage system according to the above-described embodiment.

[0048] Fig.38It is a diagram showing a read command for a virtual NAND access management API applied to the storage system of the above-described embodiment.

[0049] Fig.39 This is a diagram showing a processing sequence of a data read process executed by the storage system and the host according to the above-described embodiment.

[0050] Fig.40 This is a flowchart showing the procedure of data read processing executed by the storage system of the embodiment.

[0051] Fig.41 This is a diagram for explaining an example of a data copy operation executed by the storage system according to the above embodiment when the number of valid data to be copied is designated as a termination condition.

[0052] Fig.42 This is a diagram for explaining an example of a data copy operation executed by the storage system of the embodiment when the number of invalid data to be detected is designated as a termination condition.

[0053] Fig.43 This is a diagram for explaining an example of a data copy operation executed by the storage system of the embodiment when a plurality of copy source blocks are designated and the number of valid data to be copied is designated as a termination condition.

[0054] Fig.44 This is a diagram for explaining an example of a data copy operation executed by the storage system of the embodiment when a plurality of copy source blocks are designated and the number of invalid data to be detected is designated as a termination condition.

[0055] Fig.45 This is a diagram for explaining an example of a data copy operation executed by the storage system of the embodiment when the data size is smaller than the page size and the number of valid data to be copied is designated as a termination condition.

[0056] Fig.46 This is a diagram for explaining an example of a data copy operation executed by the storage system of the embodiment when the data size is smaller than the page size and the number of invalid data to be detected is specified as a termination condition.

[0057] Fig.47 This is a diagram showing input parameters of a data copy command applied to the storage system of the embodiment.

[0058] Fig.48 This is a diagram showing output parameters (return values) of a data copy command applied to the storage system of the embodiment.

[0059] Fig.49This is a flowchart showing the procedure of a data copy operation executed by the storage system of the embodiment when the number of valid data to be copied is designated as a termination condition.

[0060] Fig.50 This is a flowchart showing the procedure of a data copy operation executed by the storage system of the embodiment when the number of invalid data to be detected is designated as a termination condition.

[0061] Fig.51 This is a flowchart showing the procedure of a data copy operation executed by the storage system of the embodiment when the data size is smaller than the page size and the number of valid data to be copied is designated as a termination condition.

[0062] Fig.52 This is a flowchart showing the procedure of a data copy operation executed by the storage system of the embodiment when the data size is smaller than the page size and the number of invalid data to be detected is designated as a termination condition.

[0063] Fig.53 This is a diagram for explaining the namespace management function of the storage system according to the above-described embodiment.

[0064] Fig.54 It is a diagram showing a namespace management architecture of a storage system according to the embodiment.

[0065] Fig.55 It is a diagram showing a namespace allocation command applied to the storage system of the embodiment.

[0066] Fig.56 This is a flowchart showing the procedure of namespace allocation processing executed by the storage system of the embodiment.

[0067] Fig.57 This is a diagram showing block allocation and deletion commands including a namespace identifier (NSID) applied to the storage system of the embodiment.

[0068] Fig.58 The flowchart shows the procedure of block allocation and deletion processing executed by the storage system of the embodiment in response to receiving a block allocation and deletion command including a name space identifier (NSID).

[0069] Fig.59 This is a diagram showing a delete command for a namespace applied to the storage system of the above-described embodiment.

[0070] Fig.60 The present invention is a flowchart showing the sequence of a deletion process performed by the storage system of the embodiment in response to receipt of a deletion command including a namespace identifier (NSID).

[0071] Fig.61 It is a diagram showing a block return command including a namespace identifier (NSID) applied to the storage system of the embodiment.

[0072] Fig.62 The flowchart shows the sequence of block return processing executed by the storage system of the embodiment in response to receiving a block return command including a namespace identifier (NSID).

[0073] Fig.63 This is a diagram showing a deletion count acquisition command including a name space identifier (NSID) applied to the storage system of the embodiment.

[0074] Fig.64 This is a flowchart showing the procedure of the deletion count notification process executed by the storage system of the embodiment.

[0075] Fig.65 This is a block diagram illustrating an example configuration of a host computer.

[0076] Fig.66 This is a block diagram showing a configuration example of a computer including a storage system and a host computer according to the above-described embodiment. DETAILED DESCRIPTION

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

[0078] [System Configuration]

[0079] First, refer to Figure 1 The configuration of an information processing system 1 including a storage system according to one embodiment will be described.

[0080] In the information processing system 1, the storage system can function as the main storage (external storage device) of the information processing system 1. The storage system is configured to write data to the non-volatile memory and read data from the non-volatile memory. The storage system is implemented, for example, as a solid state drive (SSD) 3 based on NAND flash memory technology. The SSD 3 is a storage device having a NAND flash memory as a non-volatile memory.

[0081] The information processing system 1 manages data of various files, for example, using the SSD 3 as a storage system. The information processing system 1 can function as a computer system configured to control the read operation, write operation, and delete operation of the nonvolatile memory in the SSD 3.

[0082] This information processing system 1 includes a host (host device) 2 and an SSD 3. The host 2 is an information processing device configured to store data in the SSD 3. Examples of the information processing device include a server computer, a personal computer, and the like.

[0083] The SSD 3 may be built in an information processing device that functions as the host 2 , or may be connected to the information processing device via a cable or a network.

[0084] As an interface for connecting the host 2 and the SSD 3 to each other, SCSI, Serial Attached SCSI (SAS), ATA, Serial ATA (SATA), PCI Express (PCIe), NVM Express (NVMe), Ethernet (registered trademark), Fibre channel, etc. can be used.

[0085] The SSD 3 may include a controller 4, a nonvolatile memory (NAND memory) 5, and a DRAM 6. The NAND memory 5 is not limited, and may include a plurality of NAND flash memory chips.

[0086] The NAND memory 5 includes a memory cell array including a plurality of NAND blocks (blocks) B0 to Bm-1. The blocks B0 to Bm-1 function as erase units. A block is also called a "physical block" or an "erase block".

[0087] Blocks B0 to Bm-1 include multiple pages (physical pages). That is, blocks B0 to Bm-1 include pages P0 to Pn-1 respectively. Multiple memory cells connected to the same word line are organized as one page (physical page). In the NAND memory 5, data reading and data writing are performed in page units. Data deletion is performed in block units including multiple pages.

[0088] The controller 4 is electrically connected to the NAND memory 5 as a non-volatile memory via a NAND interface 13 such as Toggle or ONFI. The controller 4 may also have a physical resource management function for managing the physical resources of the SSD 3, namely, the NAND memory 5. The physical resource management function of the controller 4 can be used to help the host 2 directly access the physical resources of the SSD 3.

[0089] In order to directly control and access the physical resources of SSD3, host 2 may also execute flash translation layer (FTL) 44 in host 2. Host 2 having a system configuration of flash translation layer (FTL) 44 enables host 2 to directly control and access the physical resources of SSD3 and reduce the processing load of SSD3.

[0090] The flash translation layer (FTL) 44 may also perform data management and block management of the NAND memory 5 .

[0091] Data management can include (1) management of mapping information indicating the correspondence between each logical block address (LBA) and each physical address of the NAND memory 5, (2) processing for hiding the read / write operation performed in page units and the delete operation performed in block units, etc. The management of the mapping between each LBA and each physical address is performed using a lookup table (LUT) 45 functioning as a logical-physical address conversion table.

[0092] FTL44 can also support a multi-namespace function for managing multiple namespaces. The multi-namespace function can manage multiple logical address spaces (LBA spaces) corresponding to multiple namespaces in order to treat a storage device (here SSD3) as multiple drives. An LBA range (LBA0~LBAn-1) is assigned to each namespace. The size of the LBA range (i.e., the number of LBAs) can be variable for each namespace. Each LBA range starts from LBA0.

[0093] The FTL 44 can also manage the mapping between each LBA and each physical address for each namespace by using the number of created namespaces and the same number of lookup tables (LUTs) 45 .

[0094] In the lookup table (LUT) 45 corresponding to a specific namespace, the mapping between each LBA and each physical address within the LAB range associated with the specific namespace can also be managed. The management of the mapping between the LBA and the physical address is performed in a specific management size unit. The specific management size unit can use various sizes corresponding to the system design. The example of the specific management size unit is not limited, for example, it can be 4K bytes.

[0095] The physical address corresponding to a specific LBA indicates the location (physical storage location) in the NAND memory 5 where the data of the specific LBA is stored. The physical address can also be expressed by a combination of a block address and a page address. The block address is an address that specifies each block, also called a "physical block address" or a "block number". The page address is an address that specifies each page within a block, also called a "physical page address" or a "page number".

[0096] Data can be written to a page only once in one erase cycle. In other words, data can only be written to a page in the erased state (available page). The page after data is written becomes a valid page.

[0097] On the other hand, the minimum unit of data deletion is a block containing multiple pages.

[0098] Therefore, the FTL 44 maps the write (rewrite) to the same LBA to a different page on the NAND memory 5. That is, the FTL 44 writes the data (write data) to the next available page regardless of the LBA of the data. Then, the FTL 44 updates the lookup table (LUT) 45 to associate the LBA with the physical address corresponding to the page where the data is actually written. The original page (i.e., the old data associated with the LBA) is invalidated.

[0099] FTL44 can manage valid data and invalid data. Valid / invalid data can also be managed using a page management table that maintains valid / invalid flags corresponding to each physical address. Each valid / invalid flag can indicate whether the data corresponding to each physical address is valid or invalid in a specific management size unit (e.g., 4K bytes). The so-called valid data means that the data is the latest data. The so-called invalid data means that the data is updated (overwritten) and is no longer used.

[0100] Examples of block management performed by FTL 44 may also include wear leveling and garbage collection. Wear leveling is an action used to level the number of deletions of each block. Garbage collection is an action used to create free space in the NAND memory 5. The garbage collection copies all valid data in several blocks that are mixed with valid data and invalid data to another block (copy target free block). In addition, the garbage collection updates the lookup table (LUT) 45 to map each LBA of the copied valid data to the correct physical address. By copying the valid data to another block, the block with only invalid data is released as a free block. As a result, the block can be reused after deletion.

[0101] The host 2 sends various commands (access requests) such as a write command, a read command, and a delete command to the SSD 3. As described above, in the information processing system 1, the FTL 44 is executed on the host 2, so each command can include a physical address (block address, page address) that specifies a location on the NAND memory 5 instead of an LBA.

[0102] Next, the configuration of the controller 4 will be described.

[0103] The controller 4 includes a host interface 11 , a CPU 12 , a NAND interface 13 , a DRAM interface 14 , etc. The CPU 12 , the NAND interface 13 , and the DRAM interface 14 are connected to each other via a bus 10 .

[0104] The host interface 11 receives various commands (write command, read command, delete command, etc.) from the host 2 .

[0105] The CPU 12 is a processor configured to control the host interface 11, the NAND interface 13, and the DRAM interface 14. The CPU 12 performs physical resource management processing for managing the NAND memory 5, command processing for processing various commands received from the host 2, and the like. The physical resource management processing and the command processing may also be controlled by firmware executed by the CPU 12.

[0106] The firmware can execute processing for assisting the host 2 in controlling the NAND memory 5 .

[0107] The firmware enables CPU12 to function as a physical NAND access management application program interface (API) 21, a virtual NAND access management application program interface (API) 22, a block information management unit 23, a bad block management unit 24, a block allocation and deletion control unit 25, a write control unit 26, a read control unit 27, a data copy control unit 28, and a namespace control unit 29.

[0108] <Physical NAND access management API and virtual NAND access management API>

[0109] The physical NAND access management API 21 and the virtual NAND access management API 22 are software interfaces related to the communication between the host 2 and the SSD 3, respectively. The host 2 can directly control the blocks in the NAND memory 5. In the physical NAND access management API 21, the host 2 controls the blocks in the NAND memory 5 in units of individual blocks, that is, physical blocks. On the other hand, in the virtual NAND access management API 22, the host 2 controls the blocks in the NAND memory 5 basically in units of block groups obtained by gathering multiple blocks (multiple physical blocks). Hereinafter, a block group including multiple blocks will also be referred to as a "virtual block".

[0110] In either the physical NAND access management API 21 or the virtual NAND access management API 22 , the location on the NAND memory 5 to be accessed can be specified by the physical address (block address, page address) included in the command from the host 2 .

[0111] The CPU 12 classifies a plurality of blocks (physical blocks) in the NAND memory 5 into a plurality of first blocks and a plurality of second blocks.

[0112] The plurality of first blocks are blocks for the physical NAND access management API 21, and these blocks are used as blocks for accessing the NAND memory 5 in units of a single block (a single physical block).

[0113] The plurality of second blocks are blocks used by the virtual NAND access management API 22 and are organized as a plurality of block groups (a plurality of virtual blocks) each including a plurality of blocks. These second blocks are used as blocks for accessing the NAND memory 5 in units of a block group obtained by gathering a plurality of blocks (a plurality of physical blocks).

[0114] When the host 2 uses the physical NAND access management API 21 to access the SSD 3, the CPU 12 responds to the receipt of the first read, write, or delete command from the host 2 containing the physical address of a block (physical block) within multiple first blocks, and performs a read action, a write action, or a delete action on the first block.

[0115] When the host 2 uses the virtual NAND access management API 22 to access the SSD 3, the CPU 12 performs a read action, a write action, or a delete action on a virtual block in response to receipt of a second read, write, or delete command including a physical address of a virtual block within a plurality of virtual blocks.

[0116] In the virtual NAND access management API 22, a read action, a write action, or a delete action can be performed not in units of a single block but in units of a collection of multiple blocks constituting a virtual block. Thus, the virtual NAND access management API 22 can be used as an interface that can read / write / delete relatively large data such as user data at high speed. For example, when the page size is 16K bytes and one virtual block contains 4 blocks (4 physical blocks), a maximum bandwidth of 64K bytes can be achieved. In addition, for example, when the page size is 16K bytes and one virtual block contains 8 blocks, a maximum bandwidth of 128K bytes can be achieved.

[0117] On the other hand, in the physical NAND access management API 21, a read operation, a write operation, or a delete operation is performed on a single block. The maximum bandwidth that can be guaranteed by the physical NAND access management API 21 is narrower than the maximum bandwidth that can be guaranteed by the virtual NAND access management API 2. On the contrary, the physical NAND access management API 21 can control read / write / delete with a smaller granularity than the virtual NAND access management API 22. Thus, the physical NAND access management API 21 is used as an interface for data configuration control, for example, to configure relatively small data such as metadata at a desired location on the NAND memory 5, and for access (read / write / delete) with a smaller data size granularity.

[0118] The host 2 can obtain in advance from SSD3 the physical addresses of each block used for the designated physical NAND access management API 21 and the physical addresses of each virtual block used for the designated virtual NAND access management API 22, or it can obtain from SSD3 the physical address of a designated block or the physical address of a designated virtual block by requesting SSD3 to allocate a certain block or a certain virtual block.

[0119] The combination of multiple blocks included in one virtual block is not limited. For example, one virtual block may be formed by multiple blocks (multiple physical blocks) that can be accessed in parallel (simultaneously).

[0120] For example, when the NAND interface 13 has multiple channels and each channel is connected to more than one NAND flash memory chip, a virtual block can be formed using blocks of the number of channels selected one by one from the NAND flash memory chips connected to different channels. In this way, an access speed corresponding to the maximum bandwidth of the NAND memory 5 can be guaranteed.

[0121] The metadata may also be file management information. The file management information may also include at least one of data indicating the storage location of data in the file, data indicating the creation date of the file, data indicating the update date of the file, or data indicating the last read date of the file.

[0122] The read command, write command, and delete command used by the physical NAND access management API 21 may have an operation code different from that of the read command, write command, and delete command used by the virtual NAND access management API 22 .

[0123] <Block Information Management>

[0124] The block information management unit 23 can manage information related to each block and each virtual block in the NAND memory 5, and provide the information related to each block and each virtual block to the host 2. The information related to each block and each virtual block may also include the number of deletions of each block and the number of deletions of each virtual block.

[0125] In a data center or the like, an SSD connected to a certain server computer may be replaced with another SSD that was previously used in another server computer or the like.

[0126] When the SSD 3 is moved from a certain server computer to another server computer, the block information management unit 23 of the SSD 3 can provide the other server computer with information (such as the current number of deletions) related to the usage history of each block and each virtual block in the NAND memory 5. As a result, the other server computer can correctly understand the actual number of deletions of each block or each virtual block in consideration of the past usage history of the SSD 3, and can therefore perform wear leveling processing with high accuracy based on the information on the number of deletions obtained from the SSD 3.

[0127] <Bad Block Management>

[0128] The bad block management unit 24 can perform processing for managing unusable bad blocks (primary bad blocks) specified by a primary defect list (also called a "factory delivery defect list") and bad blocks (growing bad blocks) specified by the host 2 during system operation.

[0129] For example, when a block in a certain virtual block is designated as an unusable bad block (bad block) by the primary defect list or the host 2, the bad block management unit 24 may also perform a process of replacing the bad block in the virtual block with another block used by the virtual NAND access management API 22. The other block may be selected from all other blocks in the virtual block except the bad block and a block group that can be accessed in parallel.

[0130] <Block allocation and deletion>

[0131] The block allocation and deletion control unit 25 can manage each block containing valid data and each block not containing valid data (free block). The so-called block containing valid data refers to a block used by a user using the SSD 3 via the host 2. When a plurality of user-side terminals 51 are connected to the host 2 via the network 50, the users of these user-side terminals 51 can be users who use the SSD 3 via the host 2. The so-called block not containing valid data refers to a block that cannot be used by any user.

[0132] Furthermore, the block allocation and deletion control unit 25 can also manage virtual blocks including valid data and virtual blocks not including valid data (free virtual blocks).

[0133] When the host 2 requests the allocation of a block, the block allocation and deletion control unit 25 allocates a block (physical block) from the free blocks to the host 2, and then notifies the host 2 of the physical address (block address) specifying the allocated block. Thereafter, the host 2 can access (read / write / delete) the allocated block using the notified physical address.

[0134] When the host 2 requests the allocation of a virtual block, the block allocation and deletion control unit 25 can allocate a virtual block from the free virtual blocks to the host 2, and then notify the physical address (virtual block address) of the allocated virtual block to the host 2. After that, the host 2 can access (read / write / delete) the allocated virtual block using the notified physical address.

[0135] The physical address used to access the virtual block may also include a virtual block address, a block number within the virtual block, and a page address. The virtual block address specifies any one of the virtual block numbers assigned to each virtual block. The block number within the virtual block specifies which block the access target block is within the virtual block. The page address indicates the page number within the access target block.

[0136] The block allocation and deletion control unit 25 can allow the host 2 to obtain a block without valid data when the host 2 itself does not manage the block containing valid data and the block without valid data. This can reduce the management cost of the NAND memory 5 caused by the host 2.

[0137] The block (or virtual block) allocation request may be a command that only requests the allocation of a block (or virtual block). Alternatively, a command that requests both the allocation of a block (or virtual block) and the deletion of a block (or virtual block), i.e., a block allocation / deletion command or a virtual block allocation / deletion command may be used.

[0138] The block allocation and deletion command is a command that combines the functions of the command requesting block allocation and the command requesting block deletion. Similarly, the virtual block allocation and deletion command is a command that combines the functions of the command requesting virtual block allocation and the command requesting virtual block deletion.

[0139] In response to receiving a block allocation or deletion command from the host 2, the block allocation or deletion control unit 25 allocates a block from the free blocks to the host 2, then automatically deletes the allocated block, and notifies the host 2 of the physical address (block address) of the allocated or deleted block.

[0140] There are cases where each free block does not contain valid data but holds old data written by a user in the past. Therefore, by the function of automatically deleting the allocated block, leakage of user data can be prevented in advance. In addition, the host 2 can immediately start writing data to the allocated block without sending a delete command for deleting the allocated block to the SSD 3.

[0141] In response to receiving a virtual block allocation or deletion command from the host 2, the block allocation or deletion control unit 25 allocates a virtual block from the free virtual blocks to the host 2, then automatically deletes the allocated virtual block, and notifies the host 2 of the physical address (virtual block address) of the allocated and deleted virtual block.

[0142] <Write control>

[0143] The write control unit 26 receives a write command including a block address specifying a specific block and a page address specifying a specific page in a plurality of pages in the specific block, and writes the data specified by the write command to a specific page in the specific block (direct address specification mode). The write control unit 26 supports both the physical NAND access management API 21 and the virtual NAND access management API 22. In the physical NAND access management API 21, the specific block is a specific physical block, and in the virtual NAND access management API 22, the specific block is an access target block in a specific virtual block.

[0144] The write control unit 26 has a "readable page notification function" for notifying the host 2 of the latest page in the block holding readable data. Depending on the type of NAND memory used as the NAND memory 5, even if data is written to the initial page of a block, data cannot be normally read from the initial page of the block before further data is written to several subsequent pages in the block. If the initial page has been read and accessed by the host 2 before data is written to several subsequent pages of the initial page, erroneous data that cannot be corrected by the ECC is read from the initial page, and a status indicating a read error is returned to the host 2. Even if the data of the initial page can be read normally after data is written to several subsequent pages, the host 2 may mistake the read error as being caused by a physical memory defect.

[0145] Similarly, there are cases where data written into the second page of the block cannot be read normally before data is written into a plurality of pages following the second page. The timing at which data of each page can be read differs depending on the NAND memory.

[0146] The write control unit 26 can notify the host 2 of the latest page in the block holding readable data. For example, when data is written to a plurality of pages in the write target block and the first page in the write target block becomes readable, the write control unit 26 can notify the host 2 of the page address of the first page as the latest page holding readable data. When further writing is performed to the write target block and the second page in the write target block becomes readable, the write control unit 26 can notify the host 2 of the page address of the second page as the latest page holding readable data.

[0147] More specifically, the write control unit 26 performs the following operations.

[0148] The write control unit 26 receives a write command including a block address specifying a first block in a plurality of blocks of the NAND memory 5 and a page address specifying a first page in a plurality of pages in the first block from the host 2. The write control unit 26 writes the data specified by the write command to the first page in the first block. Furthermore, the write control unit 26 notifies the host 2 of the page address of the latest page that becomes readable due to the writing of data to the first page among the page group in the first block to which data was written by the host 2 before the writing of data to the first page.

[0149] Based on this notification, the host 2 can recognize which page in the block where the data is written is in a readable state. Thus, the "readable page notification function" can help the host 2 directly access the NAND memory 5.

[0150] The write control unit 26 also has an "incorrect write order warning" function. The "incorrect write order warning" function is a function that returns an incorrect write order warning to the host 2 when the host 2 does not comply with the write order constraint that data must be written continuously from the first page to the last page in a block.

[0151] The host 2 can specify the physical address (block address and page address) to which data should be written. This means that the host 2 may perform write access in an incorrect write order. The "incorrect write order warning" function can support the host 2 to directly control the writing to the NAND memory 5.

[0152] More specifically, the write control unit 26 performs the following operations.

[0153] The write control unit 26 receives a write command including a block address of a first block in a plurality of blocks of a designated NAND memory 5 and a page address of a first page in a plurality of pages in the first block from the host 2. The write control unit 26 determines whether the write command satisfies a write order-related constraint that data is written in the order from the first page to the last page in a plurality of pages in the first block based on the page address in the write command. When the write command satisfies the write order-related constraint, the write control unit 26 writes the data specified by the write command to the first page in the first block. When the write command does not satisfy the write order-related constraint, the write control unit 26 does not write the data specified by the write command to the first page in the first block, but instead notifies the host 2 of a command completion response including a warning of an improper write order.

[0154] The write control unit 26 may further support an "automatic address generation mode" in addition to the above-mentioned "direct address specification mode".

[0155] The direct address designation mode is a write mode in which the host 2 directly designates both the block in the NAND memory 5 and the page in the block to which data is to be written. In the direct address designation mode, the host 2 sends a write command including both the block address and the page address to the SSD 3.

[0156] On the other hand, the automatic address generation mode is a write mode in which the host 2 only specifies a block on the NAND memory 5 to which data is to be written. The specified block may be a physical block or an access target block in a virtual block.

[0157] The write command used in the automatic address generation mode contains only the block address, not the page address. The page address of the write target page in the specified block is automatically issued by SSD 3. The page address of the page to which the data is written, i.e., the automatically issued page address, is notified from SSD 3 to host 2.

[0158] The "readable page notification function" can be used in the automatic address generation mode. In the automatic address generation mode, the writing control unit 26 can perform the following operations.

[0159] The write control unit 26 receives a write command including a block address but not a page address from the host 2. The write control unit 26 automatically issues a page address that specifies the next available page in the plurality of pages in the first block in accordance with a write order in which data is written from the first page to the last page in the plurality of pages in the first block specified by the block address. The write control unit 26 writes the data specified by the write command to the next available page in the first block (the page specified by the automatically issued page address). The write control unit 26 notifies the host 2 of the page address of the latest page that becomes readable due to writing data to the next available page among the page group in the first block to which data is written by the host 2 before writing data to the next available page.

[0160] The write control unit 26 also has a function of notifying the host 2 that the page to be written data has reached the last page of the current write target block. Based on this notification, the host 2 can recognize that a new block must be allocated.

[0161] The write control unit 26 also has a function of notifying the host 2 that the number of pages in the current write target block of the write data has reached a specific number of pages. The host 2 may desire to write specific management information (such as metadata) to a specific page in each block, such as the last page. Therefore, by notifying the host 2 that the number of pages of the write data in the current write target block has reached the "specific number of pages", it is possible to help the host 2 perform operations such as writing specific management information to the last page of the write target block. The "specific number of pages" can be specified by a write command from the host 2.

[0162] <Readout control>

[0163] When the read control unit 27 receives a read command from the host 2, the read control unit 27 reads data from a page in a block specified by the block address and page address in the read command. The specified block may be a physical block used by the physical NAND access management API 21 or an access target block in a virtual block used by the virtual NAND access management API 22.

[0164] <Data copy control>

[0165] The data copy control unit 28 performs a data copy operation to support the host 2 in performing garbage collection. The data copy operation is performed locally in the SSD 3 based on the data copy command received from the host 2. That is, the data transfer operation for copying data from a specific copy source block of the NAND memory 5 to a specific copy target block is not performed via the host 2 but in the SSD 3.

[0166] Therefore, even without performing the process of transferring the data read from the specific copy source block of the NAND memory 5 to the memory of the host 2 and writing the valid data therein from the memory of the host 2 to the specific copy target block of the NAND memory 5, the action of gathering the valid data necessary for garbage collection in a specific block in the NAND memory 5 can be performed locally in the SSD 3.

[0167] The data copy command can specify a copy source block, a copy start page within the copy source block, a copy target block, a transfer start page within the copy target block, and a copy end condition (the number of valid data to be copied to the copy target block, or the number of invalid data to be detected before the copy ends). Here, the number of valid data may be the number of valid pages, and the number of invalid data may be the number of invalid pages. The copy source block may be a physical block used by the physical NAND access management API 21, or a block within a virtual block used by the virtual NAND access management API 22. Similarly, the copy target block may be a physical block used by the physical NAND access management API 21, or a block within a virtual block used by the virtual NAND access management API 22.

[0168] The copy start page indicates the first page of the copy object in the copy source block. The transfer start page indicates the first page of the transfer object in the copy target block. By specifying the copy start page and the transfer start page, it is possible to perform a very fine copy operation such as copying (moving) valid data within an arbitrary page range in the copy source block to an arbitrary page range in the copy target block.

[0169] In addition, during the data copy operation, the data copy control unit 28 automatically skips the copy of invalid data and only copies valid data within a specific page range to the copy target block. Thus, the host 2 can copy valid data required for garbage collection without specifying which data can be copied to where.

[0170] <Namespace Control>

[0171] The namespace control unit 29 can support a multi-namespace function for individually processing a plurality of namespaces. The multi-namespace function can manage a plurality of namespaces to which a plurality of logical address spaces (LBA spaces) are respectively allocated so as to logically divide the NAND memory 5 into a plurality of areas. Each namespace functions as an area within the NAND memory 5. Data associated with a particular namespace is written into a block group allocated to the particular namespace.

[0172] The namespace control unit 29 supports namespace allocation commands and the like.

[0173] The namespace allocation command requests the SSD 3 to allocate the number of blocks to be allocated for each namespace. The number of blocks to be allocated may be the number of physical blocks used by the physical NAND access management API 21 or the number of virtual blocks used by the virtual NAND access management API 22.

[0174] In response to receiving the namespace allocation command from the host 2 , the namespace control unit 29 can reserve (allocate) the number of blocks specified by the host 2 for a specific namespace.

[0175] The namespace allocation command enables host 2 (host software) to ensure that a number of blocks suitable for the workload in host 2 is used for each namespace. For example, for a namespace associated with a workload that uses more random write access, a number of blocks equivalent to a capacity greater than the capacity corresponding to the number of logical block addresses (LBAs) used for the namespace can also be ensured. For example, if the capacity corresponding to the number of logical block addresses (LBAs) used for a certain namespace (LBA range) is 100G bytes, by ensuring a number of blocks equivalent to 150G bytes for the namespace, an over-provisioned area of ​​50% of the capacity corresponding to the LBA range (the capacity of the user space) can be ensured.

[0176] Over-provisioning means allocating storage capacity to host 2 that is not considered as its available user space (user accessible LBA space) from the host 2 side. The space allocated with storage capacity that is not considered as user accessible LBA space from the host 2 side is the over-provisioning area. Through over-provisioning, a block group that exceeds the capacity of the user accessible LBA space (the capacity of the user area) can be allocated to a specific namespace.

[0177] In the namespace that handles data with a high update frequency, data overwrites occur multiple times, resulting in a large number of block fragments. As a result, the number of garbage collection executions increases, which increases write amplification and the number of deletions of each block. The increase in the number of deletions is the main reason for the deterioration of the durability and life of SSD3.

[0178] For namespaces that are allocated with more over-provisioned areas, the start timing of garbage collection can be delayed. For example, assume that for a specific namespace with a user space (LBA range) of 100G bytes, blocks (or virtual blocks) equivalent to 150G bytes are ensured. In this case, even when the blocks of 100G bytes are filled with data, resulting in these blocks becoming a state where there are no deletable blocks and no usable pages, the blocks corresponding to the over-provisioned areas can be used to write data instead of these blocks. Thus, the timing of executing the garbage collection action for the specific namespace can be delayed. As data is written to the block group in the over-provisioned area, the data in the block group in the user space may be invalidated due to its update. All blocks whose data are invalidated can be reused without garbage collection. Thus, by optimizing the size of the over-provisioned area, the increase in the number of deletions can be suppressed.

[0179] Furthermore, the namespace control unit 29 can count the number of deletions (also referred to as the total number of deletions) for each namespace, and notify the host 2 of the counted number of deletions for each namespace.

[0180] The host 2 (the administrator of the host 2) can use the total number of deletions corresponding to a specific namespace as an indicator for determining how much the NAND memory 5 is consumed by the specific namespace (the user using the namespace). The host 2 can utilize the total number of deletions corresponding to each namespace for the management of the plurality of namespaces.

[0181] For example, for a namespace with a large number of total deletions, the host 2 can add the number of blocks to be secured to the namespace. In this case, the host 2 can request the SSD 3 to add a specific number of blocks by sending a namespace allocation command to the SSD 3. By adding a specific number of blocks to the namespace, the amount of the over-provisioned area of ​​the namespace increases, so that the write amplification corresponding to the namespace can be suppressed, and as a result, the life of the SSD 3 can be maximized.

[0182] In data centers and the like, there are cases where rental services are provided to users for a fee to rent each storage space. In this case, the NAND memory 5 is logically divided into a plurality of areas (storage spaces) corresponding to a plurality of namespaces. A certain user accesses a storage space of an identifier associated with a certain namespace, and another user accesses another storage space of an identifier associated with another namespace. The data center provider may also reflect the total number of deletions of each namespace, that is, the consumption of each namespace, in the usage fee (rental fee) of each storage space. For example, for users who use a namespace with a very large total number of deletions, in addition to paying a basic usage fee determined by the capacity of the namespace (equivalent to the capacity of the number of blocks required to ensure the namespace), an additional fee corresponding to the consumption must also be paid.

[0183] Next, other components in the controller 4 will be described.

[0184] The NAND interface 13 is a NAND controller configured to control the NAND memory 5 under the control of the CPU 12. The NAND interface 13 may have a plurality of channels. Each channel is connected to a plurality of NAND memory chips. The controller 4 can access a plurality of NAND memory chips connected to different channels of the NAND interface 13 in parallel.

[0185] The DRAM interface 14 is a DRAM controller configured to control the DRAM 6 under the control of the CPU 12 .

[0186] A part of the storage area of ​​DRAM 6 can be used as a write buffer (WB) 31 for temporarily storing data to be written into NAND memory 5. In addition, the storage area of ​​DRAM 6 can be used as a copy buffer 32 for temporarily storing data read from the copy source block in the data copy operation. In addition, the storage area of ​​DRAM 6 can be used to store system management information 33 including various management tables. The system management information 33 can be loaded from NAND memory 5 to DRAM 6 when the power of SSD 3 is turned on. When the power of SSD 3 needs to be disconnected, the updated system management information 33 can be saved to NAND memory 5. The system management information 33 can include the block structure (or virtual block structure) of NAND memory 5, and the usage history information of NAND memory 5 such as the number of deletions.

[0187] Next, the configuration of the host computer 2 will be described.

[0188] The host 2 is an information processing device capable of executing various programs. The programs executed by the host 2 include an application software layer 41, an operating system (OS) 42, a file system 43, and the FTL 44.

[0189] As is known to all, the operating system (OS) 42 is generally configured to execute the following control software: manage the entire host 2, control the hardware in the host 2, and enable applications and each user terminal 51 to use the hardware of the host 2 and the SSD 3.

[0190] The role of the file system 43 is to perform file operations (create, save, update, delete, etc.) control. For example, the file system 43 can use ZFS (Zettabyte File System), Btrfs, XFS, ext4, NTFS (New Technology File System), etc. Alternatively, the file system 43 can also use a file object system, a key value store system.

[0191] Various application software threads are executed on the application software layer 41. Examples of application software threads include client software, database software, virtual machines, and the like.

[0192] When the application software layer 41 needs to send a request such as a read request, a write request, or a delete request to the SSD 3, the application software layer 41 will send the request to the OS 42. The OS 42 sends the request to the FTL 44 via the file system 43. The FTL 44 transcodes the request into a command (a read command, a write command, a delete command, etc.). In this case, the FTL 44 performs a logical-physical address conversion, converting the LBA contained in the request into a physical address of the NAND memory 5. Multiple FTLs 44 corresponding to multiple namespaces can be executed. In this case, the management of the mapping between each logical address (LBA) and each physical address can be performed using different LUTs 45 for each namespace.

[0193] The FTL 44 sends the command to the SSD 3 . When receiving a response from the SSD 3 , the FTL 44 sends the response to the OS 42 via the file system 43 . The OS 42 sends the response to the application software layer 41 .

[0194] [Host Software]

[0195] Figure 2 An example of software (host software) executed on the host 2 is shown.

[0196] There is a case where a certain application processes multiple files. For each file, write access for data writing is performed by continuous writing. If the continuous writes corresponding to these files are merged by one FTL44, the write target LBAs of these continuous writes are mixed together. Therefore, the merged continuous writes may be sent to SSD3 as random writes. The increase in random writes will become the cause of the increase in write amplification of SSD3.

[0197] like Figure 2 As shown, in the host 2, several FTLs 44 corresponding to these files can be executed simultaneously.

[0198] exist Figure 2 In the example, it is assumed that four FTL44A, FTL44B, FTL44C, and FTL44D are executed. The FTL44A, FTL44B, FTL44C, and FTL44D can perform actions independently of each other. For example, FTL44A manages the mapping between each LBA corresponding to NSID#1 and each physical address, FTL44B manages the mapping between each LBA corresponding to NSID#2 and each physical address, FTL44C manages the mapping between each LBA corresponding to NSID#3 and each physical address, and FTL44D manages the mapping between each LBA corresponding to NSID#4 and each physical address.

[0199] A plurality of write requests for writing data associated with NSID#1 (e.g., data of file "A") are sent to FTL44A via file system 43A. FTL44A sends a plurality of write commands corresponding to the plurality of write requests to SSD3. SSD3 can write the data specified by the plurality of write commands to the blocks allocated to NSID#1. Thus, the data of file "A" associated with a certain LBA range can be continuously written to the blocks allocated to NSID#1.

[0200] Similarly, a plurality of write requests for writing data associated with NSID#2 (e.g., data of file "B") are sent to FTL44B via file system 43B. FTL44B sends a plurality of write commands corresponding to the plurality of write requests to SSD3. SSD3 can write the data specified by the plurality of write commands to the block allocated for NSID#2.

[0201] Therefore, it is possible to prevent the continuous writing of data used to write file "A" from being merged with the continuous writing of data used to write file "B", so the increase in write amplification of SSD3 can be suppressed.

[0202] [Channel]

[0203] Figure 3 The relationship between the NAND interface 13 and a plurality of NAND memory chips is shown.

[0204] exist Figure 3 , an example is shown in which four NAND memory chips are connected to each of the eight channels (Ch#1 to Ch#8) of the NAND interface 13. Under the control of the controller 4, the NAND interface 13 simultaneously drives the eight NAND memory chips connected to the eight channels (Ch#1 to Ch#8), thereby enabling the reading, writing, and deleting of eight blocks to be performed in parallel (simultaneously).

[0205] [Physical blocks and virtual blocks]

[0206] Figure 4 The block group used by the physical NAND access management API 21 and the block group used by the virtual NAND access management API 22 managed by the SSD 3 are shown.

[0207] Here, it is assumed that the NAND interface 13 has four channels (Ch.A to Ch.D).

[0208] One or more NAND memory chips are connected to each of Ch. A to Ch. B. The one or more NAND memory chips connected to each channel include a plurality of blocks, for example, 111 blocks (block addresses 0 to 110).

[0209] The controller 4 of the SSD 3 classifies the plurality of blocks (physical blocks) in the NAND memory 5 into a block group #X for the virtual NAND access management API 22 and a block group #Y for the physical NAND access management API 21. The block group #X may include, for example, 101 blocks (block addresses 0 to 100) per channel. The block group #Y may include, for example, 10 blocks (block addresses 101 to 110) per channel.

[0210] The blocks in group #X are organized as a plurality of virtual blocks. Each of the plurality of virtual blocks includes a plurality of blocks. Each of the plurality of virtual blocks may include a combination of a plurality of blocks that can be accessed in parallel.

[0211] More specifically, a virtual block may include a block accessible via Ch.A, a block accessible via Ch.B, a block accessible via Ch.C, and a block accessible via Ch.D. Figure 5 As shown, when NAND memory chips #0 to #3 are connected to channels Ch.A to Ch.D, a virtual block may include a block in chip #0, a block in chip #1, a block in chip #2, and a block in chip #3. The order of writing data to the virtual block is page P0 in the block in chip #0, page P0 in the block in chip #1, page P0 in the block in chip #2, page P0 in the block in chip #3, page P1 in the block in chip #0, page P1 in the block in chip #1, page P1 in the block in chip #2, page P1 in the block in chip #3….

[0212] When writing 64K bytes of write data, the four data parts of 16K bytes each constituting the write data can be written in parallel, for example, page P0 in a block within chip #0, page P0 in a block within chip #1, page P0 in a block within chip #2, and page P0 in a block within chip #3.

[0213] Figure 4 The blocks in the group #Y shown are used as blocks for the physical NAND access management API 21, that is, blocks (physical blocks) accessed as single blocks.

[0214] In this way, the plurality of blocks in the NAND memory 5 are classified into the group #X of blocks for the virtual NAND access management API 22 and the group #Y of blocks for the physical NAND access management API 21, so that the same block can be prevented from being shared by the blocks for the physical NAND access management API 21 and the blocks for the virtual NAND access management API 22. That is, each block for the physical NAND access management API 21 does not belong to any virtual block. As a result, it is possible to prevent a specific block for the physical NAND access management API 21 from being erroneously accessed (read, written, deleted) due to access to the virtual block, so that security can be improved.

[0215] [Physical block information, virtual block information, namespace information]

[0216] Figure 6 The deletion count management table 33A maintained in SSD3 is shown.

[0217] The deletion count management table 33A manages the deletion count of each block (physical block) in group #Y. For example, when a specific block (e.g., block address 0) used by the physical NAND access management API 21 is deleted due to a command (delete command, block allocation, delete command) from the host 2, the controller 4 in the SSD 3 increments the deletion count of the specific block (e.g., block address 0) by 1.

[0218] Figure 7 Another deletion count management table 33B maintained in SSD3 is shown.

[0219] The deletion count management table 33B manages the deletion count of each virtual block in group #X. For example, when a specific virtual block (e.g., virtual block address 0) used by the virtual NAND access management API 22 is deleted due to a command (delete command, virtual block allocation, delete command) from the host 2, the controller 4 in the SSD 3 increments the deletion count of the specific virtual block (e.g., virtual block address 0) by 1. In the virtual NAND access management API 22, multiple blocks included in one virtual block are deleted at the same time. Therefore, the deletion count is managed in units of virtual blocks.

[0220] Figure 8 It shows another deletion count management table 33C maintained in SSD3.

[0221] The deletion count management table 33C manages the total deletion count corresponding to each namespace ID (NSID). The total deletion count of a certain NSID is the cumulative value of the deletion actions performed on the namespace (area) of the NSID, and the total deletion count increases by one each time a deletion action is performed on any block in the namespace assigned to the NSID. The blocks assigned to the NSID are physical blocks in the physical NAND access management API 21 and virtual blocks in the virtual NAND access management API 22.

[0222] For example, when a specific block (e.g., block address 0) is deleted due to a command (delete command, or block allocation, deletion command) from the host 2, the controller 4 in the SSD 3 specifically allocates the NSID of the specific block (e.g., block address 0), and increments the number of deletions of the specific NSID by 1. Similarly, when a specific virtual block (e.g., virtual block address 0) is deleted due to a command (delete command, or virtual block allocation, deletion command) from the host 2, the controller 4 in the SSD 3 specifically allocates the NSID of the specific virtual block (e.g., virtual block address 0), and increments the number of deletions of the specific NSID by 1.

[0223] Fig. 9 Indicates the physical block structure information table 33D maintained in SSD3.

[0224] The physical block structure information table 33D is information indicating the structure of each block (physical block) in the NAND memory 5. The physical block structure information table 33D includes block size, page size, estimated write time, delete time, etc. The block size indicates the size (capacity) of one block. The page size indicates the size (capacity) of one page. The estimated write time indicates the time (tProg) required to program data from the page buffer to the memory cell.

[0225] Fig.10 Indicates the virtual block structure information table 33E maintained in SSD3.

[0226] The virtual block structure information table 33E is information indicating the structure of each virtual block. The virtual block structure information table 33E includes equivalent block size, page size, estimated write time, delete time, number of blocks contained in one virtual block, etc. The equivalent block size may be the total capacity of each block contained in one virtual block.

[0227] Fig.11 The namespace information table 33F used by the physical NAND access management API 21 maintained in the SSD 3 is shown.

[0228] The namespace information table 33F manages (1) the total number of existing namespaces, (2) the number of blocks allocated to each namespace, (3) a list of block addresses of each namespace, and (4) the total number of deletions of each namespace.

[0229] For example, regarding NSID#1, the block allocation number corresponding to NSID#1 may indicate the total number of blocks (physical blocks) reserved for NSID#1. The list of block addresses corresponding to NSID#1 indicates the block addresses of each block actually used by NSID#1 and allocated thereto.

[0230] Fig.12 The namespace information table 33G used by the virtual NAND access management API 22 maintained in the SSD 3 is shown.

[0231] The namespace information table 33G manages (1) the total number of existing namespaces, (2) the number of virtual block allocations for each namespace, (3) a list of virtual block addresses for each namespace, and (4) the total number of deletions for each namespace.

[0232] For example, regarding NSID#1, the virtual block allocation number corresponding to NSID#1 may indicate the total number of virtual blocks reserved for NSID#1. The list of virtual block addresses corresponding to NSID#1 indicates the virtual block addresses of each virtual block actually used by NSID#1 and allocated to it.

[0233] [Virtual Block Management]

[0234] Fig.13 The relationship between multiple virtual blocks in the SSD 3 and the block addresses of each block (physical block) constituting the multiple virtual blocks is shown.

[0235] The combination of block addresses of the plurality of blocks (physical blocks) belonging to each virtual block is uniquely determined using the virtual block address of each virtual block based on mathematical rules. By using a method of uniquely determining the combination of block addresses using virtual block addresses based on mathematical rules, it is not necessary to use a dedicated management table for each virtual block to store the block address to which the virtual block belongs, and the combination of block addresses belonging to the virtual block can be easily specified by using each virtual block address.

[0236] As the mathematical rule, any rule that can uniquely determine a combination of block addresses using virtual block addresses can be used.

[0237] exist Fig.13For example, the following mathematical rule is applied: virtual block addresses VB0~VB100 are assigned in ascending order to block addresses 0~100 associated with Ch.A, virtual block addresses VB0~VB100 are assigned in descending order to block addresses 0~100 associated with Ch.B, virtual block addresses VB0~VB100 are assigned in ascending order to block addresses 0~100 associated with Ch.C, and virtual block addresses VB0~VB100 are assigned in descending order to block addresses 0~100 associated with Ch.D.

[0238] In this case, for example, the combination of the block addresses of the plurality of blocks belonging to the virtual block having the virtual block address VB0 is determined as the block address 0 of Ch.A, the block address 100 of Ch.B, the block address 0 of Ch.C, and the block address 100 of Ch.D. Similarly, the combination of the block addresses of the plurality of blocks belonging to the virtual block having the virtual block address VB1 is determined as the block address 1 of Ch.A, the block address 99 of Ch.B, the block address 1 of Ch.C, and the block address 99 of Ch.D.

[0239] Examples of mathematical rules that can be applied are not limited to these, and for example, a mathematical rule for selecting a block address having the same value as the value of the virtual block address from each channel may be applied. In this case, for example, a combination of block addresses of a plurality of blocks belonging to a virtual block of virtual block address VB0 is determined as block address 0 of Ch.A, block address 0 of Ch.B, block address 0 of Ch.C, and block address 0 of Ch.D. Similarly, a combination of block addresses of a plurality of blocks belonging to a virtual block of virtual block address VB1 is determined as block address 1 of Ch.A, block address 1 of Ch.B, block address 1 of Ch.C, and block address 1 of Ch.D.

[0240] The host 2 only needs to recognize the physical address (virtual block address) that can specify each virtual block, and does not need to recognize the block address itself of each block included in each virtual block.

[0241] For example, in a virtual block at virtual block address VB0, VB0-0 represents a combination of the virtual block address (VB0) and the block number (0) of the first block in the virtual block. When VB0-0 is specified by the host 2, the SSD 3 can convert VB0-0 into the block address 0 of Ch.A and access the block address 0 of Ch.A.

[0242] [Bad block management of virtual blocks]

[0243] Fig.14 Indicates the bad block replacement action performed by SSD3.

[0244] For example, when a block (VB2-2) of channel Ch.C in a virtual block (virtual block address VB2) is designated as an unusable bad block (bad block), the controller 4 of the SSD 3 can specify the block address (=2) of channel Ch.C using VB2-2 based on a mathematical rule. Furthermore, the controller 4 registers the block of the block address (=2) in the bad block list. Furthermore, the controller 4 replaces the block of the block address (=2) with another block that can be accessed in parallel with all other blocks in the virtual block (virtual block address VB2) (here, the block of block address 2 of Ch.A, the block of block address 98 of Ch.B, and the block of block address 98 of Ch.D). For example, a block in the block group of Ch.C that is not currently used for physical NAND access and virtual NAND access, such as the block of block address 102 of Ch.C, can be selected as the other block.

[0245] The controller 4 only needs to manage the replacement of the block address 2 of the channel Ch.C of the virtual block address VB2 with another block address 102 of Ch.C.

[0246] [Bad block command]

[0247] Fig.15 Indicates a bad block command used by the physical NAND access management API 21 applied to the SSD 3.

[0248] The bad block command used by the physical NAND access management API 21 requests the SSD 3 to make a specific block a bad block. The host 2 can specify the block to be bad based on the number of read errors, etc. The bad block command includes the following input parameters.

[0249] (1) Block address: This block address specifies the block (physical block) that should be corrupted.

[0250] The badblock command contains the following output parameters.

[0251] (1) End status: Returns to the host 2 an end status indicating success or error of the bad block command.

[0252] Fig.16 Indicates a bad block command used by the virtual NAND access management API 22 applied to the SSD 3.

[0253] The bad block command used by the virtual NAND access management API 22 requests the SSD 3 to make a block in a specific virtual block a bad block. The host 2 can determine which block in a specific virtual block should be made bad based on the number of read errors, etc. The bad block command includes the following input parameters.

[0254] (1) Virtual block address and block number within the virtual block

[0255] The virtual block address and the block number within the virtual block specify which block in the virtual block should be made bad. The block number within the virtual block can be a value that specifies a channel number.

[0256] The badblock command contains the following output parameters.

[0257] (1) End state

[0258] The host 2 is returned with a completion status indicating success or error of the bad block command.

[0259] [Bad block processing order]

[0260] Fig.17 The flowchart shows the order of the processing used by the virtual NAND access management API 22 and the bad block processing executed by the SSD 3.

[0261] The controller 4 of the SSD 3 classifies the block group in the NAND memory 5 into two groups (group #X and group #Y) (step S1), and organizes the block group of group #X as a plurality of virtual blocks (step S2).

[0262] In step S2, the controller 4 determines the combination of block addresses that should belong to each virtual block based on mathematical rules. If a block in a virtual block is designated as a bad block according to the primary defect list, the controller 4 can select another block connected to the same channel as the bad block from group #Y and replace the bad block with the selected block. The remaining blocks in group #Y are used as blocks for the physical NAND access management API 21.

[0263] In response to receiving a read, write, or delete command including a physical address (virtual block address, block number in the virtual block, page address) specifying a certain virtual block from the host 2, the controller 4 performs a read operation, a write operation, or a delete operation on the virtual block (step S3). In step S3, the controller 4 determines the block address of the access target block in the virtual block of the access target using the physical address (virtual block address, block number in the virtual block) based on a mathematical rule, and performs a read operation, a write operation, or a delete operation on the block.

[0264] If the controller 4 receives a bad block command from the host 2, the controller 4 determines whether the bad block command is a bad block command for the virtual NAND access management API 22 or a bad block command for the physical NAND access management API 21 (steps S4, S5). When the bad block command for the virtual NAND access management API 22 and the bad block command for the physical NAND access management API 21 have different operation codes, the determination is performed based on the operation code. When the bad block command for the virtual NAND access management API 22 and the bad block command for the physical NAND access management API 21 have the same operation code, the determination may also be performed based on the type of address contained in the bad block command (block address / virtual block address and block number within the virtual block).

[0265] If the bad block command is a bad block command for the physical NAND access management API 21 (Yes in step S5), the controller 4 registers the block of the block address specified by the bad block command into the bad block list and manages the block of the block address as a bad block (step S6). The process of replacing the bad block with another block is not performed.

[0266] If the bad block command is a bad block command for the virtual NAND access management API 22 (Yes in step S4), the controller 4 specifies the block address of the block to be bad block based on the mathematical rule used in step S2 using the virtual block address and the block number in the virtual block (step S7).

[0267] The controller 4 registers the block of the identified block address in the bad block list, and manages the block of the identified block address as a bad block (step S8).

[0268] In addition, the controller 4 selects a block that is not currently used for physical NAND access and virtual NAND access from the blocks connected to the same channel as the block (bad block) of the specific block address (step S9), and replaces the block (bad block) of the specific block address with the selected block (step S10).

[0269] [Processing sequence for physical NAND access and virtual NAND access]

[0270] Fig.18 The processing sequence for physical NAND access and virtual NAND access performed by the SSD 3 and the host 2 is shown.

[0271] When the host 2 wishes to access the SSD 3 using the physical NAND access management API 21, the host 2 may request the SSD 3 to allocate a block. The request may be the block allocation and deletion command. The controller 4 of the SSD 3 selects a block without valid data (a block not currently used) from the blocks in group #Y, allocates the selected block to the host 2, and notifies the host 2 of the physical address (block address) of the allocated block.

[0272] When the host 2 wishes to access the SSD 3 using the virtual NAND access management API 22, the host 2 may request the SSD 3 to allocate a virtual block. The request may be the virtual block allocation and deletion command. The controller 4 of the SSD 3 selects a virtual block that does not contain valid data (a virtual block that is not currently in use) from multiple virtual blocks, allocates the selected virtual block to the host 2, and notifies the host 2 of the physical address (virtual block address) of the allocated virtual block.

[0273] The host 2 sends a read, write or delete command including the notified block address, i.e., a read, write or delete command for the physical NAND access management API 21, to the SSD 3. In response to receiving the read, write or delete command including the block address, i.e., a read, write or delete command for the physical NAND access management API 21, the controller 4 performs a read action, a write action, or a delete action on a specific and single block specified by the block address (step S11).

[0274] The host 2 sends a read, write or delete command including the notified virtual block address to the SSD 3. In response to receiving the read, write or delete command including the virtual block address, i.e., the read, write or delete command for the virtual NAND access management API 22, the controller 4 performs a read operation, a write operation, or a delete operation on the collection of blocks included in the specific virtual block specified by the virtual block address (step S12).

[0275] [Write Process]

[0276] Fig.19 The process sequence of the write process of the physical NAND access performed by the SSD 3 and the host 2 to access a single physical block is shown.

[0277] The host 2 sends a write command for the physical NAND access management API 21 to the SSD 3. The write command includes a block address that specifies the block to which data should be written. In the case of the direct address designation mode, the write command includes both the block address and the page address. In response to receiving the write command for the physical NAND access management API 21, the controller 4 of the SSD 3 writes the data specified by the write command to the write target page in the block specified by the block address in the write command (step S13). In the case of the direct address designation mode, the page of the write target is specified by the page address in the write command. In the case of the automatic address generation mode, the page of the write target is specified by the page address automatically generated by the controller 4.

[0278] Furthermore, the controller 4 sends a command completion response of the write command to the host 2 .

[0279] Fig. 20 The process sequence of the virtual NAND access write process executed by the SSD 3 and the host 2 for accessing a virtual block including a plurality of physical blocks is shown.

[0280] The host 2 sends a write command for the virtual NAND access management API 22 to the SSD 3. The write command includes a virtual block address that specifies the virtual block to which data is to be written. In the case of the direct address specification mode, the write command includes both the virtual block address and the page address. As described above, the write command may also include the virtual block address, the block number within the virtual block, and the page address.

[0281] In response to receiving the write command for the virtual NAND access management API 22, the controller 4 of the SSD 3 writes the data specified by the write command to the write target page in the virtual block specified by the virtual block address in the write command (step S14). In the case of the direct address specification mode, the page of the write target is specified by the page address in the write command. In the case of the automatic address generation mode, the page of the write target is specified by the page address automatically generated by the controller 4. In addition, in the automatic address generation mode, both the block number in the virtual block and the page address can also be automatically generated.

[0282] Furthermore, the controller 4 sends a command completion response of the write command to the host 2 .

[0283] [Reading Process]

[0284] Fig.21 The flowchart shows a processing sequence of a read process executed by the SSD 3 and the host 2 for performing a physical NAND access.

[0285] The host 2 sends a read command for the physical NAND access management API 21 to the SSD 3. The read command includes a block address and a page address. In response to receiving the read command for the physical NAND access management API 21, the controller 4 of the SSD 3 reads data from the read target page in the block specified by the block address and the page address in the read command (step S15). In addition, the controller 4 sends the read data and the command completion response of the read command to the host 2.

[0286] Fig. 22 The flowchart shows a processing sequence of a read process executed by the SSD 3 and the host 2 for performing a virtual NAND access.

[0287] The host 2 sends a read command for the virtual NAND access management API 22 to the SSD 3. The read command includes a virtual block address and a page address. The read command may also include a virtual block address, a block number within a virtual block, and a page address.

[0288] In response to receiving the read command for the virtual NAND access management API 22, the controller 4 of the SSD 3 reads data from the read target page in the virtual block specified by the virtual block address, the block number in the virtual block, and the page address in the read command (step S16). The controller 4 then sends the read data and a command completion response of the read command to the host 2.

[0289] [Delete Process]

[0290] Fig.23 This figure shows the processing sequence of the delete processing executed by the SSD 3 and the host 2 for performing physical NAND access.

[0291] The host 2 sends a delete command for the physical NAND access management API 21 to the SSD 3. The delete command includes a block address. In response to receiving the delete command for the physical NAND access management API 21, the controller 4 of the SSD 3 deletes the block specified by the block address in the delete command and sets all pages in the block to a deleted state (step S17). In addition, the controller 4 sends a command completion response of the delete command to the host 2.

[0292] Fig.24 The following diagram shows a processing sequence of a delete process executed by the SSD 3 and the host 2 for performing virtual NAND access.

[0293] The host 2 sends a delete command for the virtual NAND access management API 22 to the SSD 3. The delete command includes a virtual block address. In response to receiving the delete command for the virtual NAND access management API 22, the controller 4 of the SSD 3 simultaneously deletes multiple blocks in the virtual block specified by the virtual block address in the delete command, and sets all pages in the multiple blocks to a deleted state (step S18). In addition, the controller 4 sends a command completion response of the delete command to the host 2.

[0294] [Priority Management]

[0295] Fig.25 Indicates the management action of the command priority of the controller 4.

[0296] Among all commands received from the host 2, a value (priority) indicating the priority order (priority level) of execution of the plurality of commands may be assigned by the host 2. Each command may have an input parameter indicating its priority.

[0297] The number of types of priority order (priority level) may be any number greater than or equal to 2. The types of priority levels may include, for example, "high" indicating the highest priority, "low" indicating the lowest priority, and "medium" indicating an intermediate priority.

[0298] In the priority management performed by the controller 4, a command with a higher priority can be executed before a command with a lower priority. The execution order between commands with the same priority can be determined by a first-in-first-out method. For a command such as a delete command that requires a long time until the processing of the command is completed, the execution of this command (such as the delete command) can be interrupted, and the command with a higher priority can be executed first. When the command with a higher priority is completed, the processing of the interrupted command (such as the delete command) can be continued.

[0299] For priority management, priority queues 61, 62, and 63 may be set for each NAND chip. In order to identify which command is to be executed, queue IDs may be assigned to all commands and all command completion responses. The host 2 may assign queue IDs to all commands.

[0300] Each command assigned a "high" priority is stored in the priority queue 61 (queue). Each command assigned a "medium" priority is stored in the priority queue 62. Each command assigned a "low" priority is stored in the priority queue 63. The command fetched from the priority queue 61 is executed with priority priority over the command fetched from the priority queue 62 and the command fetched from the priority queue 63. The command fetched from the priority queue 62 is executed with priority priority over the command fetched from the priority queue 63.

[0301] [Block allocation and deletion commands]

[0302] Reference Fig.26 , block allocation and deletion commands used by the physical NAND access management API 21 and block allocation and deletion commands used by the virtual NAND access management API 22 are explained.

[0303] The block allocation and deletion commands used by the physical NAND access management API 21 include the following input parameters.

[0304] (1) Block Type = Block: Block Type indicates the type of block to be allocated. The block type of the block allocation and deletion commands used by the physical NAND access management API 21 is block (physical block). A block is allocated to the host 2 from the free blocks, and the block is automatically deleted.

[0305] (2) Processing priority: The processing priority indicates the priority of the command.

[0306] (3) NSID (optional): NSID represents the ID of the namespace to which the block should be allocated.

[0307] The block allocation and deletion commands used by the physical NAND access management API 21 include the following output parameters.

[0308] (1) End status: Returns to host 2 the end status indicating success or error of the block allocation or deletion command.

[0309] (2) Block address: Returns the block address of the allocated block to host 2.

[0310] (3) Number of remaining blocks: Only when an NSID is specified, the number of remaining blocks to ensure that the NSID is used is returned to the host 2.

[0311] The block allocation and deletion commands (also referred to as "virtual block allocation and deletion commands") used by the virtual NAND access management API 22 include the following input parameters.

[0312] (1) Block type = virtual block: The block type of the block allocation and deletion commands used by the virtual NAND access management API 22 is virtual block. A virtual block is allocated to the host 2 from the free virtual blocks, and multiple blocks in the virtual block are automatically deleted.

[0313] (2) Processing priority: The processing priority indicates the priority of the command.

[0314] (3) NSID (optional): NSID represents the ID of the namespace to which the virtual block should be allocated.

[0315] The block allocation and deletion commands used by the virtual NAND access management API 22 include the following output parameters.

[0316] (1) End status: Returns to host 2 the end status indicating success or error of the block allocation or deletion command.

[0317] (2) Virtual block address: Returns the virtual block address of the allocated virtual block to host 2.

[0318] (3) Number of remaining blocks: When only an NSID is specified, the number of remaining virtual blocks reserved for the NSID is returned to the host 2.

[0319] [Physical block management and virtual block management]

[0320] Fig. 27 The in-use block list 71A, the free block list 71B, the in-use virtual block list 72A, and the free virtual block list 72B managed by the controller 4 of the SSD 3 are shown.

[0321] The in-use block list 71A indicates a list of blocks (physical blocks) that hold valid data among the block groups of group #Y, that is, a list of in-use blocks that are being used by the host 2. The free block list 71B indicates a list of blocks (physical blocks) that do not hold valid data among the block groups of group #Y, that is, a list of free blocks that are not being used by the host 2.

[0322] The in-use virtual block list 72A indicates a list of virtual blocks that hold valid data among the virtual block groups of group #X, that is, a list of in-use virtual blocks that are being used by the host 2. The free virtual block list 72B indicates a list of virtual blocks that do not hold valid data among the virtual block groups of group #X, that is, a list of free virtual blocks that are not being used by the host 2.

[0323] [Block allocation and deletion processing]

[0324] Fig.28 It shows the processing sequence of block allocation and deletion processing executed by SSD 3 and host 2.

[0325] First, the block allocation and deletion processing used by the physical NAND access management API 21 will be described.

[0326] When the block (physical block) currently allocated to the host 2 is full of data from the host 2, the host 2 can send a block allocation and deletion command for the physical NAND access management API 21 to the SSD 3.

[0327] When the controller 4 of the SSD 3 receives the block allocation and deletion command from the host 2, the controller 4 selects a block (physical block) from the free block list 71B, and allocates the selected block (physical block) to the host 2 as a write object block (step S21). The controller 4 has the right to select blocks (write object blocks) from the free block list 71B. Therefore, the controller 4 can allocate blocks with high reliability as write object blocks to the host 2. In step S21, the controller 4 can select the block with the minimum number of deletions from the free block list 71B, and allocate the block with the minimum number of deletions as a write object block to the host 2.

[0328] The controller 4 deletes the allocated block and updates the number of deletions of the allocated block (step S22). The controller 4 notifies the host 2 of the block address of the allocated block (step S23). The block address can also be notified to the host 2 as a return value in the command completion response to the block allocation and deletion command.

[0329] Next, the block allocation and deletion processing used by the virtual NAND access management API 22 will be described.

[0330] When the virtual block currently allocated to the host 2 is full of data from the host 2 , the host 2 may send a block allocation and deletion command for the virtual NAND access management API 22 to the SSD 3 .

[0331] When the controller 4 of the SSD 3 receives the block allocation and deletion command from the host 2, the controller 4 selects a virtual block from the free virtual block list 72B, and allocates the selected virtual block as a write-target virtual block to the host 2 (step S21). The controller 4 has the right to select virtual blocks (write-target virtual blocks) from the free virtual block list 72B, so the controller 4 can allocate virtual blocks with high reliability as write-target virtual blocks to the host 2. In step S21, the controller 4 can select a virtual block with the minimum number of deletions from the free virtual block list 72B, and allocate the virtual block with the minimum number of deletions as a write-target virtual block to the host 2.

[0332] The controller 4 deletes the multiple blocks included in the allocated virtual block at the same time, and updates the number of deletions of the allocated virtual block (step S22). The controller 4 notifies the host 2 of the virtual block address of the allocated virtual block (step S23). The virtual block address can also be notified to the host 2 as a return value in the command completion response to the block allocation and deletion command.

[0333] [Write command]

[0334] Fig.29Indicates a write command used by the physical NAND access management API 21 applied to the SSD 3.

[0335] The write command contains the following input parameters.

[0336] (1) Block address, or block address and page address: This input parameter value is a physical address that specifies the location on the NAND memory 5 where data is to be written. When only the block address is specified, the write target page is automatically updated by the SSD 3.

[0337] (2) NSID (optional): If the block address is not specified, specify the NSID. If the NSID is specified, the block address and page address are automatically issued by SSD3. Data is written to the block last assigned to the NSID (the current write target block).

[0338] (3) Processing priority: The processing priority indicates the priority of the write command.

[0339] (4) Starting address of write data: The starting address of write data indicates the starting address on the output buffer (host memory) where the write data is stored.

[0340] (5) Number of written pages: The number of written pages indicates the number of pages to which data should be written, namely the “specific number of pages.” When the number of pages in a block to which data should be written reaches the number of written pages (“specific number of pages”), the host 2 is notified of this fact.

[0341] (6) NAND mode (optional): NAND modes include SLC / MLC / TLC, etc.

[0342] The write command contains the following output parameters.

[0343] (1) End status: Returns to the host 2 an end status indicating success or error of the write command.

[0344] (2) Block address and page address: The block address and page address indicate the location of the write data on the NAND memory 5. When the write command only includes the block address, or only includes the NSID, the host 2 can know the location of the write data on the NAND memory 5 based on the return value.

[0345] (3) Number of written pages: This value indicates the number of pages where data is written.

[0346] (4) Improper write order warning: When an improper write order is detected, a warning or error is returned to the host 2.

[0347] (5) Latest page address that can be read: The latest page address that holds the data that can be read is returned to the host 2. The host 2 can know which page in the block can be read up to.

[0348] Fig.30 Indicates a write command used by the virtual NAND access management API 22 applied to the SSD 3.

[0349] The write command contains the following input parameters.

[0350] (1) Virtual block address, or virtual block address and page address: These addresses are physical addresses that specify the location on the NAND memory 5 where data should be written. The physical address can be represented by a virtual block address, a block number within a virtual block, and a page address. When only a virtual block address is specified, the block number within the virtual block and the page address can be automatically updated by the SSD 3.

[0351] (2) NSID (optional): When the virtual block address is not specified, specify the NSID. When the NSID is specified, the virtual block address, the block number within the virtual block, and the page address can be automatically issued by the SSD3. Data is written to the virtual block assigned to the NSID.

[0352] (3) Processing priority: The processing priority indicates the priority of the write command.

[0353] (4) Starting address of write data: The starting address of write data indicates the starting address on the output buffer (host memory) where the write data is stored.

[0354] (5) Number of pages to be written: The number of pages to be written indicates the number of pages to which data should be written. When the number of pages in a block to which data should be written reaches the number of pages to be written, the host 2 is notified of this fact.

[0355] (6) NAND mode (optional): NAND modes include SLC / MLC / TLC, etc.

[0356] The write command contains the following output parameters.

[0357] (1) End status: Returns to the host 2 an end status indicating success or error of the write command.

[0358] (2) Virtual block address and page address: This value is a physical address indicating the location on the NAND memory 5 where the data is written. The physical address can be represented by a virtual block address, a block number within a virtual block, and a page address. When the write command only includes a virtual block address or only includes an NSID, the host 2 can know the location on the NAND memory 5 where the data is written based on the return value.

[0359] (3) Number of written pages: This value indicates the number of pages where data is written.

[0360] (4) Improper write order warning: When an improper write order is detected, a warning or error is returned to the host 2.

[0361] (5) Latest readable page address: The latest page address holding readable data is returned to the host 2. The host 2 can know which page in the access target block in the virtual block can be read.

[0362] [Write order constraints]

[0363] Fig.31 Indicates constraints on the order in which data is written to multiple pages within a block.

[0364] Here, it is assumed that a block includes pages 0 to 255. With regard to data reading, any number of pages in a block can be read in any order. On the other hand, with regard to data writing, within a certain block, data must be written continuously in the order of page 0, page 1, page 2, page 3, ... page 254, page 255. Therefore, the "incorrect write order warning" function can help the host 2 use the direct address designation mode, that is, help the host 2 control the block address and page address to which data should be written.

[0365] [Restrictions on the timing of reading data from a page]

[0366] There is a situation as follows: even if the NAND memory writes data to a page in a block, the data written to the page cannot be read immediately after being written, and the data written to the page can only be read after the data writing to one or more subsequent pages of the page is completed.

[0367] Fig.32 Indicates constraints related to the timing of reading data from a page.

[0368] Here, the case where page P0 remains in a state where data can be read after data is written to pages P0 to P3 is exemplified. Thus, there is a case where even if writing to a specific page (e.g., page P0) is completed, data cannot be correctly read from the specific page (e.g., page P0) before writing to subsequent pages (e.g., pages P1 to P3) is completed.

[0369] Such timing-related constraints on the reading of data from a page are caused by the programming operation performed in the NAND memory.

[0370] That is, in NAND memory, cells are becoming increasingly miniaturized, and writing data to a cell causes programming disturbances that cause changes in the threshold levels of adjacent cells. Therefore, in NAND memory, there are cases where the programming action of correcting the threshold levels of cells in one or more pages before the writing of data to each cell in a page is performed in consideration of the influence of programming disturbances. If data is read from a page before the correction is completed, erroneous data different from the original data will be read. The timing of correction completion varies depending on the type of NAND memory used.

[0371] The controller 4 can notify the host 2 of the calibration completion timing. In other words, the controller 4 can notify the host 2 of the last page in the block from which the written data can be read.

[0372] In more detail, the controller 4 executes the following processing.

[0373] The controller 4 receives a write command including a block address specifying a certain block and a page address specifying a write target page in the specific block from the host 2. The controller 4 writes data to the write target page in the specific block according to the write command. In addition, the controller 4 notifies the host 2 of the page address indicating the latest page in the specific block (the last page that becomes readable among the page group in the specific block) that becomes readable due to the writing of data to the write target page in the specific block.

[0374] The host 2 can update the readable page address management information on the host 2 indicating the page from which the written data can be read according to the notification. After receiving the notification indicating that the data of a certain page can be read, the host 2 can release the memory area (write buffer) of the host 2 that holds the data of the page. In other words, the host 2 first temporarily stores the data to be written to the NAND memory 5 of the SSD 3 in the memory of the host 2, and then sends the write command for writing the data to be written to the SSD 3. And, the host 2 maintains the data in the memory of the host 2 until the data becomes readable from the non-volatile memory 5.

[0375] In addition, in order to reduce the impact of program disturbance, there are also NAND memories that follow Fig.33 The programming sequence shown here performs the programming actions. Fig.33In the programming operation for writing data to each page, multiple writing stages are included. At least the last writing stage in the multiple writing stages to each page is performed after one or more writing stages to subsequent one or more pages are completed. At this time, there is a case where even if the writing to a specific page (for example, page P0) is completed by transferring data to the NAND memory, data cannot be accurately read from the specific page until the writing to the one or more pages is completed by transferring data to the other one or more pages to the NAND memory.

[0376] In TLC writing of writing 3 bits of data per cell, the programming operation may be performed according to the following programming sequence.

[0377] (1) The first writing stage to page 0 (writing data to the lower page of page 0)

[0378] (2) The first writing stage to page 1 (writing data to the lower page of page 1)

[0379] (3) Second writing stage to page 0 (writing the middle page data to page 0)

[0380] (4) The first writing stage to page 2 (writing data to the lower page of page 2)

[0381] (5) Second writing phase to page 1 (writing the middle page data to page 1)

[0382] (6) The third writing stage to page 0 (writing the upper page data to page 0)

[0383] (7) First writing stage to page 3 (writing data to the lower page of page 3)

[0384] (8) Second writing stage to page 2 (writing the middle page data to page 2)

[0385] (9) The third writing stage to page 1 (writing the upper page data to page 1)

[0386] The usable programming sequence is not limited to this example, and various different programming sequences can be used for each NAND memory.

[0387] [Write Processing Order]

[0388] Fig.34 The flowchart shows the order of the data writing process executed by SSD3.

[0389] In response to receiving the block allocation and deletion command, the controller 4 of the SSD 3 allocates the write target block to the host 2 and sets the write target page to the initial value (page 0) (step S31). If the controller 4 receives a write command from the host 2 (yes in step S32), the controller 4 determines whether the received write command is a write command in the direct address designation mode including the page address (step S33).

[0390] If the received write command is a write command in the direct address designation mode (Yes in step S33 ), the controller 4 determines whether the page address designated by the write command is consistent with the current write target page (here, page 0) (step S34 ).

[0391] If the page address specified by the write command is inconsistent with the current write target page (No in step S34), the controller 4 detects that an improper write sequence has occurred, and notifies the host 2 of a command completion response including a warning of an improper write sequence (step S35). In step S35, the controller 4 does not write data to the page address specified by the write command, but instead notifies the host 2 of a command completion response including a warning of an improper write sequence.

[0392] On the other hand, if the page address specified by the write command is consistent with the current write target page (Yes in step S34), the controller 4 transmits the data specified by the write command to the NAND memory 5, and writes the data to the page in the write target block specified by the page address of the write command (step S36). The controller 4 updates the write target page (here, from page 0 to page 1) based on the constraint related to the write order of writing data in the order from the first page to the last page (step S37).

[0393] If the received write command is not a write command in the direct address designation mode (No in step S33), the controller 4 automatically issues the page address of the current write target page (here page 0), transmits the data specified by the write command to the NAND memory 5, and writes the data to the current write target page in the write target block (step S38). The controller 4 updates the write target page (here, from page 0 to page 1) based on the constraints related to the write order (step S39).

[0394] After step S37 or S39 , the controller 4 specifies the latest page address where data can be read (step S40 ).

[0395] Then, the controller 4 determines whether data is written to the last page in the write target block and whether the number of pages of written data reaches the “number of written pages” (the “specific number of pages”) (steps S41 and S42 ).

[0396] Furthermore, the controller 4 creates a return value and sends a command completion response including the return value to the host 2 .

[0397] If the data is written to the last page in the write target block (Yes in step S41), the controller 4 sends a command completion response including an end status and a return value to the host 2 (step S43). The return value includes the following values.

[0398] (1) A physical address indicating the location on the NAND memory 5 where data is to be written (the physical address may be a block address and a page address, or may be a virtual block address and a page address)

[0399] (2) The latest page address that can be read

[0400] (3) Indicates the status of writing completion of all pages in the block

[0401] If the number of pages of written data reaches the "number of written pages" (the "specific number of pages") (Yes in step S42), the controller 4 sends a command completion response including an end status and a return value to the host 2 (step S44). The return value includes the following values.

[0402] (1) A physical address indicating the location on the NAND memory 5 where the data is to be written (the physical address may be a block address and a page address, or may be a virtual block address and a page address)

[0403] (2) The latest page address that can be read

[0404] (3) Status indicating that writing of a specific number of pages has been completed

[0405] Fig.35 The flowchart represents the order of processing performed by the host 2 in response to reception of a command completion response of a write command.

[0406] In response to receiving the command completion response of the write command from the SSD 3, the host 2 determines whether the command processing of the write command is successful (step S51).

[0407] If the command processing of the write command is successful (Yes in step S51), the host 2 uses the block address and page address contained in the command completion response to update the address conversion table (i.e., the lookup table LUT45), thereby mapping the correct physical address to the LBA corresponding to the data written by the write command (step S52). In addition, the host 2 updates the readable page address management information based on the latest readable page address, and releases the memory area (write buffer) of the host 2 that holds the data written to the latest readable page address (step S53).

[0408] That is, the data written by the write command is maintained in the memory area (write buffer) of the host 2 until the data written by the write command can be read from the SSD 3. After the data written by the write command can be read from the SSD 3, the access target of the read request for the data is switched from the write buffer to the SSD 3.

[0409] Then, the host 2 determines whether writing of a specific number of pages is completed and whether writing is completed up to the last page of the block (steps S54 and S56 ).

[0410] When writing of a specific number of pages is completed (Yes in step S54), the host 2 sends a write command requesting writing of management information such as metadata to the SSD 3 (step S55). Thus, management information such as metadata can be written to the last page of each block.

[0411] When writing is completed up to the last page of the block (Yes in step S56 ), the host 2 sends a block allocation and deletion command to the SSD 3 (step S57 ).

[0412] If the command processing of the write command is erroneous (No in step S51), the host 2 determines whether the error is caused by an improper write order (step S58).

[0413] If the error is due to an improper write order (YES in step S58 ), the host 2 executes an error process including a process for specifying the cause of the improper write order (step S59 ).

[0414] Fig.36 The flowchart represents the order of processing performed by the host 2 in response to reception of a command completion response of a write command including the NSID.

[0415] In response to receiving the command completion response of the write command from the SSD 3 , the host 2 determines whether the command processing of the write command is successful (step S61 ).

[0416] If the command processing of the write command is successful (Yes in step S61), the host 2 identifies the NSID associated with the data written by the write command (step S62). The command completion response may include the same NSID as the NSID in the write command.

[0417] The host 2 uses the block address and page address contained in the command completion response to update the address conversion table (i.e., the lookup table LUT45) corresponding to the specific NSID, thereby mapping the correct physical address to the LBA corresponding to the data (step S63). In addition, the host 2 updates the readable page address management information by storing the latest readable page address in the readable page address management information, and releases the memory area (write buffer) of the host 2 that holds the data written to the latest readable page address (step S64).

[0418] Then, the host 2 determines whether writing of a specific number of pages is completed and whether writing is completed up to the last page of the block (steps S65 and S67 ).

[0419] If writing of the specific number of pages is completed (Yes in step S65 ), the host 2 sends a write command requesting writing of management information such as metadata to the SSD 3 (step S66 ).

[0420] When writing is completed up to the last page of the block (Yes in step S67 ), the host 2 sends a block allocation and deletion command to the SSD 3 (step S68 ).

[0421] If the command processing of the write command is erroneous (No in step S61 ), the host 2 determines whether the error is caused by an improper write order (step S69 ).

[0422] If the error is due to an improper write order (Yes in step S69), the host 2 executes error processing including a process for specifying the NSID associated with the data to be written by the write command and a process for specifying the cause of the improper write order (step S70).

[0423] [Read command]

[0424] Fig.37 Indicates the read command used by the physical NAND access management API 21 applied to the SSD 3.

[0425] The read command contains the following input parameters.

[0426] (1) Block address and page address: This address is a physical address that specifies the location on the NAND memory 5 where data is to be read.

[0427] (2) Processing priority: The processing priority indicates the priority of the read command.

[0428] (3) Transfer destination address of read data: The transfer destination address of read data indicates the position on the input buffer (host memory) to which the read data is to be transferred.

[0429] (4) Number of read pages: The number of read pages indicates the number of pages to be read.

[0430] (5) Allowed waiting time: The allowed waiting time specifies either the minimum waiting time, normal waiting time, or long waiting time.

[0431] The read command contains the following output parameters.

[0432] (1) End status: Returns to the host 2 an end status indicating success or error of the read command.

[0433] (2) Block address and page address: The block address and page address indicate the location on the NAND memory 5 from which data is read.

[0434] (3) Number of pages: This value indicates the number of pages of data to be read.

[0435] (4) Starting address: This address indicates the starting address of the read data.

[0436] Fig.38 Indicates the read command used by the virtual NAND access management API 22 applied to the SSD 3.

[0437] The read command contains the following input parameters.

[0438] (1) Virtual block address and page address: This address is a physical address that specifies the location on the NAND memory 5 where data is to be read.

[0439] (2) Processing priority: The processing priority indicates the priority of the read command.

[0440] (3) Transfer destination address of read data: The transfer destination address of read data indicates the position on the input buffer (host memory) to which the read data is to be transferred.

[0441] (4) Number of read pages: The number of read pages indicates the number of pages to be read.

[0442] (5) Allowed waiting time: The allowed waiting time specifies either the minimum waiting time, normal waiting time, or long waiting time.

[0443] The read command contains the following output parameters.

[0444] (1) End status: Returns to the host 2 an end status indicating success or error of the read command.

[0445] (2) Virtual block address and page address: The virtual block address and page address indicate the location on the NAND memory 5 from which data is read.

[0446] (3) Number of pages: This value indicates the number of pages of data to be read.

[0447] (4) Starting address: This address indicates the starting address of the read data.

[0448] [Reading process order]

[0449] Reference Fig.39 and Fig.40 , indicating the order of data read processing performed by SSD3 and host 2.

[0450] like Fig.39 As shown, the host 2 refers to the address conversion table (ie, the lookup table LUT45) to convert the LBA of the data to be read into the physical address of the NAND memory 5 (step S71). Then, the host 2 sends a read command including the physical address to the SSD 3.

[0451] The controller 4 of the SSD 3 reads data from the page in the block specified by the physical address (step S72). In step S72, the controller 4 executes Fig.40 Processing shown.

[0452] That is, Fig.40 As shown, the controller 4 performs the action of reading data from the physical location specified by the physical address (a certain page in a certain block) and the action of correcting errors in the read data (step S81). Furthermore, the controller 4 determines whether the read data contains errors that cannot be corrected by the ECC (step S82). If the page that has not yet become readable is read, the read data contains a large number of errors that cannot be corrected by the ECC.

[0453] When the read data does not contain an uncorrectable error (No in step S82), the controller 4 transmits the read data to the host 2 and transmits a command completion response indicating success to the host 2 (step S83).

[0454] On the other hand, when the read data includes an error that cannot be corrected (Yes in step S82), the controller 4 transmits a command completion response indicating an error to the host 2 (step S84).

[0455] [Data Copy]

[0456] Fig.41 This figure shows an example of a data copy operation performed by SSD3.

[0457] The controller 4 of the SSD 3 does not copy all the data in the copy source block to the copy target block, but skips the invalid data in the specified page range in the copy source block and only copies the valid data in the page range to the specified page range in the copy target block. The data copying action is performed for the purpose of garbage collection as described above.

[0458] In the data copy operation, as described above, the controller 4 automatically skips copying of invalid pages that do not contain valid data. Thus, the host 2 can copy only valid pages to the copy destination block without individually specifying pages to be copied in units of pages.

[0459] In addition, the host 2 can specify not only the copy source block and the copy destination block, but also the copy start page in the copy source block and the transfer start page in the copy destination block by using the copy command. Thus, it is possible to perform a very fine copy operation such as copying a specific page group in the copy source block to a specific page group in the copy destination block. In addition, multiple copy source blocks can also be specified.

[0460] Furthermore, the host 2 may specify either "the number of valid data to be copied before the copy is completed" or "the number of invalid data to be detected before the copy is completed" as the termination condition of the data copy.

[0461] When "the number of valid data to be copied until the end of copying" is specified as the end condition of the data copying action, the data copying action is continued until the required number of valid data is copied to the copy target block. When the required number of valid data is copied to the copy target block, the data copying action is terminated. For example, if the number of data in a block is specified as "the number of valid data to be copied until the end of copying", the copy target block can be filled with valid data copied from several copy source blocks, and several copy source blocks can be set as free blocks containing only invalid data. In addition, it is not necessary to increase the number of free blocks in one data copying action, and the number of free blocks can be increased in multiple data copying actions. Therefore, the "number of valid data to be copied until the end of copying" can be any number.

[0462] When "the number of invalid data to be detected before the end of copying" is specified as the end condition of the data copying action, the data copying action is continued until the number of times the copying of invalid data is skipped becomes the required number. When the number of times the copying of invalid data is skipped becomes the required number, the data copying action is terminated. Usually, the selected several copy source blocks are blocks in which valid data and invalid data are mixed. In addition, the total number of invalid data contained in these selected several copy source blocks is at least greater than the number of data in one block. Therefore, for example, if the number of data in a block is specified as "the number of invalid data to be detected before the end of copying", at least one copy source block can be set as a free block containing only invalid data until the copying action is terminated. As described above, the number of free blocks can be increased in multiple data copying actions, so the "number of invalid data to be detected before the end of copying" can also be an arbitrary number.

[0463] Fig.41 In order to simplify the description, it is assumed that the following parameters are specified using a data copy command from the host 2.

[0464] (1) Copy source block = block B0

[0465] (2) Copy source start page = P31

[0466] (3) Copy target block = block B10

[0467] (4) Transfer target start page = P11

[0468] (5) Valid / Invalid Bitmap = Bitmap Data 81

[0469] (6) The number of valid data to be copied until the copy is completed = 3

[0470] The bitmap data 81 indicates whether the data of each page within the copy target range is valid or invalid. The controller 4 first determines whether the data of the copy start page P31 of the copy source block B0 is valid or invalid. Fig.41 In the case of , the data of page P31 is valid. Therefore, the controller 4 reads data from page P31 and copies the read data to the transfer target start page P11 of the copy target block B10. The number of valid data copied to the copy target block B10 becomes 1.

[0471] The controller 4 determines whether the data of page P32 of the copy source block B0 is valid or invalid. Fig.41 In this case, the data of page P32 is invalid. Therefore, the controller 4 skips copying the data of page P32. The number of valid data copied to the copy target block B10 remains 1.

[0472] The controller 4 determines whether the data of page P33 of the copy source block B0 is valid or invalid. Fig.41 In the case of , the data of page P33 is valid. Therefore, the controller 4 reads data from page P33 and copies the read data to page P12 of the copy target block B10. The number of valid data copied to the copy target block B10 becomes 2.

[0473] The controller 4 determines whether the data of page P34 of the copy source block B0 is valid or invalid. Fig.41 In this case, the data of page P34 is invalid. Therefore, the controller 4 skips copying the data of page P34. The number of valid data copied to the copy target block B10 remains 2.

[0474] The controller 4 determines whether the data of page P35 of the copy source block B0 is valid or invalid. Fig.41, the data of page P35 is valid. Therefore, the controller 4 reads data from page P35 and copies the read data to page P13 of the copy target block B10. The number of valid data copied to the copy target block B10 becomes 3. Since the number of valid data copied to the copy target block B10 reaches the end condition (the number of valid data to be copied until the copy is completed), the copy operation is terminated.

[0475] Fig.42 An example of a data copy operation is shown in which the number of invalid data to be detected is designated as a termination condition.

[0476] Fig.42 In the example, it is assumed that the following parameters are specified using a data copy command from host 2.

[0477] (1) Copy source block = block B0

[0478] (2) Copy source start page = P31

[0479] (3) Copy target block = block B10

[0480] (4) Transfer target start page = P11

[0481] (5) Valid / Invalid Bitmap = Bitmap Data 81

[0482] (6) Number of invalid data to be detected before copying is completed = 3

[0483] The controller 4 first determines whether the data of the copy start page P31 of the copy source block B0 is valid or invalid. Fig.42 In this case, the data of page P31 is valid. Therefore, the controller 4 reads data from page P31 and copies the read data to the transfer target start page P11 of the copy target block B10.

[0484] The controller 4 determines whether the data of page P32 of the copy source block B0 is valid or invalid. Fig.42 In the case of , the data of page P32 is invalid. Therefore, the controller 4 skips the copying of the data of page P32. The number of invalid data detected (ie, the number of data to be copied is skipped) becomes 1.

[0485] The controller 4 determines whether the data of page P33 of the copy source block B0 is valid or invalid. Fig.42 In the case of , the data of page P33 is valid. Therefore, the controller 4 reads data from page P33 and copies the read data to page P12 of the copy target block B10. The number of invalid data detected remains 1.

[0486] The controller 4 determines whether the data of page P34 of the copy source block B0 is valid or invalid. Fig.42 In the case of , the data of page P34 is invalid. Therefore, the controller 4 skips the copying of the data of page P34. The number of invalid data detected becomes 2.

[0487] The controller 4 determines whether the data of page P35 of the copy source block B0 is valid or invalid. Fig.42 In the case of , the data of page P35 is valid. Therefore, the controller 4 reads data from page P35 and copies the read data to page P13 of the copy target block B10. The number of invalid data detected remains 2.

[0488] The controller 4 determines whether the data of page P36 of the copy source block B0 is valid or invalid. Fig.42 In the case of , the data of page P36 is valid. Therefore, the controller 4 reads data from page P36 and copies the read data to page P14 of the copy target block B10. The number of invalid data detected remains 2.

[0489] The controller 4 determines whether the data of page P37 of the copy source block B0 is valid or invalid. Fig.42 , the data of page P37 is invalid. Therefore, the controller 4 skips copying the data of page P37. The number of invalid data detected becomes 3. Since the number of invalid data detected reaches the end condition (the number of invalid data to be detected before the copy is completed), the copy operation is terminated.

[0490] Fig.43 An example of a data copy operation is shown in which a plurality of copy source blocks are designated and the number of valid data to be copied is designated as a termination condition.

[0491] Here, for the sake of simplicity, it is assumed that the number of pages included in one block is 3 and the number of valid data to be copied until the copy is completed is 3. The bitmap data 81A and 81B are valid / invalid bitmaps corresponding to the blocks B11 and B20, respectively.

[0492] The blocks B11 and B20 are copy source blocks specified by the copy command from the host 2 , and the block B30 is a copy destination block specified by the copy command.

[0493] The controller 4 first determines whether the data of the copy start page P0 of the copy source block B11 is valid or invalid. Fig.43 In the case of , the data of page P0 is valid. Therefore, the controller 4 reads data from page P0 and copies the read data to the transfer target start page P0 of the copy target block B30. The number of valid data copied to the copy target block B30 becomes 1.

[0494] The controller 4 determines whether the data of the page P1 of the copy source block B11 is valid or invalid. Fig.43In the case of , the data of page P1 is valid. Therefore, the controller 4 reads data from page P1 and copies the read data to page P1 of the copy target block B30. The number of valid data copied to the copy target block B30 becomes 2.

[0495] The controller 4 determines whether the data of the page P2 of the copy source block B11 is valid or invalid. Fig.43 In this case, the data of page P2 is invalid. Therefore, the controller 4 skips copying the data of page P2. The number of valid data copied to the copy target block B30 remains 2.

[0496] The controller 4 determines whether the data of the page P0 of the next copy source block B20 is valid or invalid. Fig.43 In the case of , the data of page P0 of the copy source block B20 is valid. Therefore, the controller 4 reads data from page P0 of the copy source block B20 and copies the read data to page P2 of the copy target block B30. The number of valid data copied to the copy target block B30 becomes 3. Since the number of valid data copied to the copy target block B30 reaches the end condition (the number of valid data to be copied until the copy is completed), the copy operation is terminated.

[0497] The controller 4 sends data copy information indicating the valid data ID and the location (copy target location) in the copy target block storing the valid data as a command completion response of the copy command to the host 2 according to the copied valid data. Based on the data copy information, the host 2 updates the address conversion table (LUT45) to map each copied data to the correct physical address. The data of page P0 and page P1 of block B11 are invalidated. As a result, block B11 becomes an idle block without valid data. Similarly, the data of page P0 of block B20 is also invalidated.

[0498] Furthermore, the controller 4 determines page P1 of the copy source block B20 as the next copy source start page, and notifies the host 2 of the physical address of the next copy source start page (block address of the copy source block B20, page address of page P1).

[0499] Furthermore, the controller 4 identifies the page address (latest page address) of the latest page from which data can be read out of the page group of the copy target block to which valid data has been copied due to the data copy operation, and notifies the host 2 of the identified latest page address. Thus, the host 2 can know the last page that can be read out of the page group in the copy target block B30.

[0500] Fig.44 An example of a data copy operation is shown in which a plurality of copy source blocks are designated and the number of invalid data to be detected is designated as a termination condition.

[0501] Here, for simplicity of illustration, it is assumed that the number of pages included in one block is 3 and the number of invalid data to be detected before the copy is completed is 3. Bitmap data 81A, 81B, and 81C are valid / invalid bitmaps corresponding to blocks B11, B20, and B25, respectively.

[0502] Blocks B11, B20, and B25 are copy source blocks specified by a copy command from the host 2, and blocks B30 and B31 are copy target blocks specified by a copy command.

[0503] The controller 4 first determines whether the data of the copy start page P0 of the copy source block B11 is valid or invalid. Fig.44 Therefore, the controller 4 reads data from page P0 and copies the read data to the transfer target start page P0 of the copy target block B30.

[0504] The controller 4 determines whether the data of the page P1 of the copy source block B11 is valid or invalid. Fig.44 Therefore, the controller 4 reads data from page P1 and copies the read data to page P1 of the copy target block B30.

[0505] The controller 4 determines whether the data of the page P2 of the copy source block B11 is valid or invalid. Fig.44 In the case of , the data of page P2 is invalid. Therefore, the controller 4 skips the copying of the data of page P2. The number of invalid data detected (ie, the number of data to be copied is skipped) becomes 1.

[0506] The controller 4 determines whether the data of the page P0 of the next copy source block B20 is valid or invalid. Fig.44 In the case of , the data of page P0 of the copy source block B20 is valid. Therefore, the controller 4 reads data from page P0 of the copy source block B20 and copies the read data to page P2 of the copy target block B30. Since the number of invalid data detected has not yet reached the end condition, the copy operation is continued.

[0507] The controller 4 determines whether the data of the page P1 of the copy source block B20 is valid or invalid. Fig.44 In the case of , the data of page P1 is invalid. Therefore, the controller 4 skips the copying of the data of page P1 of the copy source block B20. The number of invalid data detected becomes 2.

[0508] The controller 4 determines whether the data of page P2 of the copy source block B20 is valid or invalid. Fig.44In this case, the data of page P2 of the copy source block B20 is valid. Therefore, the controller 4 reads data from page P2 of the copy source block B20 and copies the read data to page P0 of the copy target block B31.

[0509] The controller 4 determines whether the data of page P0 of the next copy source block B25 is valid or invalid. Fig.44 , the data of page P0 of the copy source block B25 is invalid. Therefore, the controller 4 skips the copying of the data of page P0 of the copy source block B25. The number of invalid data detected becomes 3. Since the number of invalid data detected reaches the end condition (the number of valid data to be detected until the end of the copying), the copying operation is terminated.

[0510] The controller 4 sends the data copy information indicating the data ID and the copy target location to the host 2 as a command completion response of the copy command according to each copy data. Based on the data copy information, the host 2 updates the address conversion table (LUT45) and maps each copied data to the correct physical address. The data of page P0 and page P1 of block B11 are invalidated. As a result, block B11 becomes an idle block without valid data. Similarly, the data of page P0 and page P2 of block B20 are also invalidated. As a result, blocks B11 and B20 become idle blocks without valid data.

[0511] Furthermore, the controller 4 determines page P1 of the copy source block B25 as the next copy source start page, and notifies the host 2 of the physical address of the next copy source start page (block address of the copy source block B25, page address of page P1).

[0512] Furthermore, the controller 4 identifies the latest page address in the copy target block B30 and the latest page address in the copy target block B31, and notifies the host 2 of the latest page addresses. Thus, the host 2 can know the last readable page in the page group in each copy target block.

[0513] Fig.45 Indicates the data copy operation when the data size is smaller than the page size and the number of valid data to be copied is specified as the end condition.

[0514] Here, as an example, it is assumed that the page size is 16K bytes and the data size is 4K bytes. This data size corresponds to the management size used to manage the mapping between each LBA and each physical address. In the copy start page P31 of the copy source block B0, data D1, data D2, data D3, and data D4, each having a data size of 4K bytes, are stored. In the next page P32 of the copy source block B0 of each data, data D5, data D6, data D7, and data D8, each having a data size of 4K bytes, are stored. The bitmap data 81 indicates the validity / invalidity of each of the data D1, data D2, data D3, data D4, data D5, data D6, data D7, data D8, ...

[0515] In this way, when the data size is smaller than the page size, each page of the copy source block B0 includes a plurality of data whose validity / invalidity is respectively indicated by the bitmap data 81 .

[0516] The controller 4 (1) reads data from pages in the copy source block B0 containing one or more valid data in page units, (2) extracts valid data from the read data, thereby preparing valid data of a number corresponding to the page size of 1 page, and (3) writes the prepared valid data of a number corresponding to the page size of 1 page from the copy target area (area starting from the transfer target start page) of the copy target block B10 in page units, thereby copying the valid data to the copy target area and skipping the copying of invalid data. Furthermore, the controller 4 ends the data copying operation when the number of valid data copied to the copy target area is greater than the number of valid data to be copied before the copying is completed, or when the number of invalid data whose copying is skipped is greater than the number of invalid data to be detected before the copying is completed.

[0517] That is, for each page containing valid data, the controller 4 reads out data from these pages in page units in sequence. If valid data of one page (here, four valid data) is prepared, the controller 4 writes the valid data of one page to the copy target block in page units. Thus, only valid data can be efficiently copied to the copy target block in a state where these valid data are aligned with the page unit. In the case where the data of the source block is not copied before the valid data of one page is complete, the controller 4 fills the valid data currently prepared with dummy data, and writes the data of one page obtained thereby to the copy target block.

[0518] More specifically, the following copying operation is performed. In order to simplify the illustration below, it is assumed that the number of valid data to be copied before the copying is completed is 2.

[0519] The controller 4 first determines whether the copy start page P31 of the copy source block B0 contains valid data. Fig.45In this case, page P31 includes valid data D1 and D3. Therefore, the controller 4 reads out one page of data (D1 to D4) from page P31. The read data may be temporarily stored in the copy buffer 32.

[0520] Since the number of valid data read out is only two, D1 and D3, and the four valid data corresponding to the size of one page are not complete, the controller 4 continues to execute the process of reading data from the copy source block B0 in page units.

[0521] The controller 4 determines whether the page P32 of the copy source block B0 contains valid data. Fig.45 In the case of , page P32 includes valid data D5 and D6. Therefore, the controller 4 reads out one page of data (D5 to D8) from page P32. The read data may be temporarily stored in the copy buffer 32.

[0522] The controller 4 extracts valid data D1 and D3 from the data of one page read out from page P31, and extracts valid data D5 and D6 from the data of one page read out from page P32, and generates valid data (D1, D3, D5, D6) of one page. Furthermore, the controller 4 copies the valid data (D1, D3, D5, D6) of one page to the transfer target start page P11 of the copy target block B10. Thus, the copying of invalid data D2, D3, D7, and D8 is skipped, and only the valid data is copied to the copy target block B10 in page units. In this way, the process of aligning the valid data with the page unit is executed first, and the determination of the end condition is executed after the valid data is aligned with the page unit.

[0523] The number of valid data copied to the copy destination block B10 becomes 4. The number of valid data copied to the copy destination block B10, 4, is greater than the number of valid data specified by the end condition (here, 2), and thus the copy operation is ended.

[0524] By using the above copy operation, even when the size of each data is smaller than the page size, valid data can be efficiently copied to the copy target block in a state where the valid data is aligned with the page unit.

[0525] The controller 4 notifies the host 2 of the data copy information indicating the data ID and the copy target location as a command completion response of the copy command according to each copy data. The copy target location can also be represented by a block address, a page address, and an offset within a page. The offset within a page corresponding to a certain 4K bytes of data is an address within a page indicating the offset position within the page storing the 4K bytes of data. Based on the data copy information, the host 2 updates the address conversion table (LUT45) and maps each copy data (here D1, D3, D5, D6) to the correct physical address. Data D1, D3 of page P31 of block B0 and data D5, D6 of page P32 are invalidated.

[0526] Furthermore, the controller 4 determines page P33 of the copy source block B0 as the next copy source start page, and notifies the host 2 of the physical address of the next copy source start page (block address of the copy source block B0, page address of page P33).

[0527] Furthermore, the controller 4 identifies the latest page address in the copy target block B10 that holds the readable data, and notifies the host 2 of the latest page address.

[0528] Fig.46 The data copy operation is shown when the data size is smaller than the page size and the number of invalid data to be detected is specified as the termination condition. In the following, it is assumed that the number of invalid data to be detected before the copy is completed is 2.

[0529] The controller 4 first determines whether the copy start page P31 of the copy source block B0 contains valid data. Fig.46 In this case, page P31 includes valid data D1 and D3. Therefore, the controller 4 reads out one page of data (D1 to D4) from page P31. The read data may be temporarily stored in the copy buffer 32.

[0530] Since the number of invalid data included in the read data of one page (D1 to D4) is only two, D2 and D4, the controller 4 continues to execute the process of reading data in units of pages from the copy source block B0.

[0531] The controller 4 determines whether the page P32 of the copy source block B0 contains valid data. Fig.46 In the case of , page P32 includes valid data D5 and D6. Therefore, the controller 4 reads out one page of data (D5 to D8) from page P32. The read data may be temporarily stored in the copy buffer 32.

[0532] The controller 4 extracts valid data D1 and D3 from the data of one page read out from page P31, and extracts valid data D5 and D6 from the data of one page read out from page P32, and generates valid data (D1, D3, D5, D6) of one page. Furthermore, the controller 4 copies the valid data (D1, D3, D5, D6) of one page to the transfer target start page P11 of the copy target block B10. Thus, the copying of invalid data D2, D4, D7, and D8 is skipped, and only valid data is copied to the copy target block B10 in page units.

[0533] The number of invalid data detected, that is, the number of invalid data for which copying is skipped, becomes 4. Since the number of invalid data detected, 4, is equal to or larger than the number of invalid data specified by the termination condition (here, 2), the copying operation is terminated.

[0534] [Data copy command]

[0535] Fig.47 Indicates the input parameters of the data copy command applied to SSD3. The data copy command contains the following input parameters.

[0536] (1) Copy source block address (copy source block address list): This parameter value indicates the block address of the copy source block. The block address of the copy source block can also be specified by the virtual block address and the block number within the virtual block. The copy source block address list includes the block addresses of multiple copy source blocks. In other words, the host 2 can specify more than one copy source block.

[0537] (2) Copy start position in copy source block: This parameter value indicates the start position in the copy source block where data is to be copied (copy source start page). When multiple copy source blocks are specified, only the copy start position in the first copy source block may be specified by this parameter value.

[0538] (3) Copy target block address: The copy target block address indicates the block address of the copy target block. The block address of the copy target block can also be specified by a virtual block address and a block number within a virtual block.

[0539] (4) Starting position in the copy target block: The starting position in the copy target block indicates the starting position in the copy target block where data should be transferred (transfer target start page).

[0540] (5) Valid / Invalid Bitmap: The valid / invalid bitmap is information (bitmap data) indicating the arrangement of valid data and invalid data in the copy source block.

[0541] (6) Number of valid data to be copied until the copy is completed: This parameter value specifies the number of data (e.g., number of pages) to be transferred, i.e., copied to the copy target block. This parameter value is used as the end condition of the copy operation. The data copy operation skips the copying of invalid data and only copies valid data.

[0542] (7) Number of invalid data to be detected before copying ends: This parameter value can also be used as a termination condition for the copying operation. The host 2 can specify only one of the termination conditions (6) or (7) in one copy command.

[0543] (8) Data size (data size)

[0544] In addition, the data copy command may include other input parameter values ​​such as processing priority.

[0545] Fig.48 Indicates the output parameters of the data copy command. The data copy command contains the following output parameters.

[0546] (1) Number of invalid data detected until the end of copying

[0547] (2) Total number of data copied to the copy target block: This parameter value indicates the total number of data actually copied to the copy target block. When the number of invalid data to be detected before the copy is completed is specified as the end condition, the total number of data actually copied to the copy target block is not fixed. Therefore, this parameter value is useful when the number of invalid data to be detected before the copy is completed is specified as the end condition.

[0548] (3) A combination of an identifier of data to be copied to a copy target block and a recording location of the copy target: This parameter value indicates which valid data is to be copied to where in the copy target block.

[0549] (4) The position of the data to be copied next time: This parameter value indicates the copy start position within the copy source block in the next copy.

[0550] (5) Latest readable page address: This parameter value indicates the latest page address of the copy target block that holds readable data.

[0551] [Data copying process order]

[0552] Fig.49 The flowchart shows the procedure of the data copy operation when the number of valid data to be copied is designated as the end condition.

[0553] The controller 4 first sets the copy start position (copy source start page) in the copy source block specified by the data copy command as the current copy target page, and determines whether the current copy target page is valid data based on the bitmap data (step S91).

[0554] If the current copy target page is invalid data (No in step S91 ), the controller 4 skips the copy operation of the current copy target page (step S92 ) and changes the current copy target page to the next page (step S93 ).

[0555] If the current copy target page is valid data (Yes in step S91), the controller 4 reads the valid data from the current copy target page (step S94), and writes the read valid data to the transfer target start page of the copy target block (step S95). The controller 4 updates the number of valid data copied (step S96), and determines whether the number of valid data copied reaches the number of valid data to be copied (step S97).

[0556] If the number of valid data copied does not reach the number of valid data to be copied (No in step S97 ), the controller 4 changes the current copy target page to the next page (step S98 ), and then executes the processing of steps S91 to S97 again.

[0557] If the number of valid data copied reaches the number of valid data to be copied (Yes in step S97), the controller 4 executes the end processing (step S99). In step S99, the controller 4 creates the return value data and sends a command completion response including the return value data to the host 2.

[0558] Fig.50 The flowchart shows the procedure of the data copy operation when the number of invalid data to be detected is specified as the end condition.

[0559] The controller 4 first sets the copy start position (copy source start page) in the copy source block specified by the data copy command as the current copy target page, and determines whether the current copy target page is valid data based on the bitmap data (step S101).

[0560] If the current copy target page is valid data (Yes in step S101), the controller 4 reads the valid data from the current copy target page (step S102), and writes the read valid data to the transfer target start page of the copy target block (step S103). The controller 4 changes the current copy target page to the next page (step S104), and enters the process of step S101.

[0561] If the current copy object page is invalid data (No in step S101), the controller 4 skips copying the current copy object page (step S105), updates the number of invalid data detected (step S106), and determines whether the number of invalid data detected reaches the number of invalid data that should be detected (step S107).

[0562] If the number of invalid data detected does not reach the number of invalid data that should be detected (No in step S107 ), the controller 4 changes the current copy target page to the next page (step S108 ) and proceeds to the process of step S101 .

[0563] If the number of invalid data detected reaches the number of invalid data to be detected (Yes in step S107), the controller 4 executes the end process (step S109). In step S109, the controller 4 creates the return value data and sends a command completion response including the return value data to the host 2.

[0564] Fig.51 The flowchart shows the procedure of the data copy operation when the data size is smaller than the page size and the number of valid data to be copied is specified as the end condition.

[0565] The controller 4 first sets the copy start position (copy source start page) in the copy source block specified by the data copy command as the current copy target page, and determines whether the current copy target page contains at least one valid data based on the bitmap data (step S111).

[0566] If the current copy target page is a page containing only invalid data (No in step S111 ), the controller 4 skips the copy operation of the current copy target page (step S112 ), changes the current copy target page to the next page (step S113 ), and enters the processing of step S111 .

[0567] If the current copy target page is a page containing at least one valid data (Yes in step S111), the controller 4 reads the data in the current copy target page in units of pages and stores the read data in the copy buffer 32 (step S114). The controller 4 extracts only valid data from the read data, thereby skipping invalid data and preparing a group of valid data aligned with the page size (step S115). The controller 4 determines whether a group of valid data aligned with the page size (valid data having a size of 1 page) can be prepared (step S116).

[0568] If the size of the prepared valid data is smaller than the size of one page (No in step S116 ), the controller 4 changes the current copy target page to the next page (step S117 ), and executes the processes of steps S111 to S115 here.

[0569] If a group of valid data aligned with the page size can be prepared (valid data having a size of 1 page) (Yes in step S116), the controller 4 writes the valid data having a size of 1 page to the transfer target start page of the copy target block (step S118). The controller 4 updates the number of valid data to be copied (step S119), and determines whether the number of valid data to be copied becomes greater than the number of valid data to be copied (step S120).

[0570] If the number of valid data to be copied is less than the number of valid data to be copied (No in step S120 ), the controller 4 changes the current copy target page to the next page (step S117 ), and then executes the process from step S111 again.

[0571] If the number of valid data copied is greater than the number of valid data to be copied (Yes in step S120), the controller 4 executes the end process (step S121). In step S121, the controller 4 creates return value data and sends a command completion response including the return value data to the host 2.

[0572] Fig.52 The flowchart shows the procedure of the data copy operation when the data size is smaller than the page size and the number of invalid data to be detected is specified as the termination condition.

[0573] exist Fig.52 In the processing, instead of Fig.51 Steps S119 and S120 are skipped, and steps S131 and S132 are executed.

[0574] That is, after writing a group of valid data aligned with the page size (valid data with a size of 1 page) to the transfer target start page of the copy target block (step S118), the controller 4 updates the number of invalid data detected (step 131), and determines whether the number of invalid data detected is greater than the number of invalid data that should be detected (step S132).

[0575] If the number of invalid data detected is less than the number of invalid data that should be detected (No in step S132), the controller 4 changes the current copy target page to the next page (step S117), and then executes the processing starting from step S111 again.

[0576] If the number of invalid data detected is equal to or larger than the number of invalid data to be detected (Yes in step S132 ), the controller 4 executes the end processing (step S121 ).

[0577] [Namespace Management]

[0578] Fig.53 Indicates the namespace management function of SSD3.

[0579] In SSD3, the number of blocks specified for the namespace of NSID#1 can be secured (reserved), and similarly, the number of blocks specified for the namespace of NSID#n can be secured (reserved). A user terminal 51 (user A) connected to host 2 can access (read, write, delete) SSD3 using NSID#1, and another user terminal 51 (user B) connected to host 2 can access (read, write, delete) SSD3 using NSID#n.

[0580] In the following, it is assumed that user A processes data with a high update frequency, and user B processes data with a low update frequency. In this case, there is a possibility that write amplification increases in the namespace of NSID#1. Write amplification (WA) is defined as follows.

[0581] WA = "Total amount of data written to the SSD" / "Total amount of data written to the SSD by write commands from the host"

[0582] The “total amount of data written to the SSD” corresponds to the sum of the total amount of data written by a write command from the host and the total amount of data internally written to the SSD by garbage collection (data copy operation) and the like.

[0583] The increase in write amplification (WA) will cause an increase in the number of deletions of each block in SSD 3. In other words, the larger the write amplification (WA), the easier it is for the number of deletions of a block to quickly reach its upper limit of the number of deletions. As a result, the durability and life of SSD 3 are deteriorated.

[0584] Therefore, the consumption of SSD3 caused by writing to the namespace of NSID#1 is greater than the consumption of SSD3 caused by writing to the namespace of NSID#n.

[0585] The namespace management function of SSD3 can manage the total number of deletions of blocks (or virtual blocks) according to each namespace, and notify the host 2 of the total number of deletions corresponding to the specific namespace specified by the host 2 as an indicator of the consumption of SSD3 caused by the specific namespace. The total number of deletions of NSID#1 is counted by the total number of deletions counter 300-1, and the total number of deletions of NSID#n is counted by the total number of deletions counter 300-n. The total number of deletions of a certain NSID is obtained by counting the number of deletion actions performed on the blocks assigned to the NSID.

[0586] Using this notification, the host 2 can evaluate the degree of consumption of the SSD 3 by each namespace. As a result, the host 2 can take measures such as adding more blocks to the namespace with a large total number of deletions based on the evaluation result.

[0587] For example, the host software may request SSD3 to ensure a sufficient number of blocks exceeding the capacity (user data capacity) corresponding to the LBA range of NSID#1 for the namespace of NSID#1. In response to the request, the controller 4 of SSD3 ensures the specified number of blocks for the namespace of NSID#1.

[0588] When the capacity corresponding to the LBA range of NSID#1 is 100G bytes, the host software can request SSD3 to add physical blocks equivalent to 100G bytes, and physical blocks equivalent to a total of 200G bytes are reserved for the namespace of NSID#1. The remaining 100GB of physical resources after subtracting the user data capacity from 200G bytes functions as an over-provision area of ​​the namespace of NSID#1.

[0589] In another embodiment, the host software can determine the storage usage fee (rental fee) to be charged to user A who is using the namespace based on the number of blocks reserved for the namespace of NSID#1 and the total number of deletions corresponding to the namespace. The higher the total number of deletions, the higher the rental fee is set.

[0590] Fig.54 Represents the namespace management architecture of SSD3.

[0591] The controller 4 manages the free blocks of the NAND memory 5 using the common free block pool 90, and allocates several blocks from the common free block pool 90 to the namespace of NSID#1. These allocated blocks are used to store data associated with the namespace of NSID#1. That is, the controller allocates several blocks to the namespace of NSID#1 as blocks for storing data associated with the namespace of NSID#1. In response to receiving a command from the host 2 for reading, writing, or deleting one of these blocks, the controller 4 performs a read action, a write action, or a delete action on one of these blocks. The controller 4 counts the number of delete actions performed on these blocks. In response to receiving a command from the host 2 requesting to obtain the number of delete actions associated with the namespace of NSID#1, the controller 4 notifies the host 2 of the count value of the number of delete actions (the total number of deletes of NSID#1). Regarding the namespace of NSID#n, the controller 4 also performs the same processing as the processing of the namespace of NSID#1.

[0592] The following describes the namespace management architecture.

[0593] In SSD3, an independent virtual flash pool is provided for each namespace. Virtual flash pool 81 is used to manage the amount of physical resources (the total number of ensured blocks) ensured (reserved) for the namespace of NSID#1. Similarly, virtual flash pool 82 is used to manage the amount of physical resources (the total number of ensured blocks) ensured (reserved) for the namespace of NSID#n. In this case, there is no need to consider which block should be ensured (reserved), and each virtual flash pool only needs to manage the number of blocks to be ensured (reserved). The number of blocks to be ensured is the number of physical blocks in the physical NAND access management API 21 and the number of virtual blocks in the virtual NAND access management API 22.

[0594] Each free block is managed by a common free block pool 90 shared by a plurality of name spaces. Blocks returned from the virtual flash pool of each name space are managed by the common free block pool 90.

[0595] Wear leveling is performed when a new block (e.g., a write target block or a write target virtual block) is allocated from the common free block pool 90 to each namespace. When the controller 4 receives a block allocation command (e.g., the block allocation and deletion command) containing a specific NSID from the host 2, the controller 4 selects a free block from the common free block pool 90. The selected free block is a physical block when the physical NAND access management API 21 is used, and a virtual block when the virtual NAND access management API 22 is used. The controller 4 allocates the selected block to the namespace corresponding to the specific NSID, and subtracts 1 from the total number of blocks used to ensure the namespace. When selecting a free block from the common free block pool 90, the controller 4 may also select a block with the minimum number of deletions (a physical block with the minimum number of deletions or a virtual block with the minimum number of deletions). Thus, the block with a small number of deletions returned from the namespace of NSID#n can be allocated to the namespace of NSID#1, where data is frequently overwritten, so that wear leveling between namespaces can be achieved.

[0596] The controller 4 manages the total number of blocks for NSID#1, the list of block addresses allocated to NSID#1, and the total number of deletions of NSID#1 as management information corresponding to the namespace of NSID#1. The total number of deletions of NSID#1 is obtained by counting the number of deletion actions performed on each block allocated to NSID#1.

[0597] The namespace management of NSID#1 can also be performed as follows: The following is an example of namespace management for the physical NAND access management API 21.

[0598] When the controller 4 receives a namespace allocation command including NSID#1 from the host 2, the controller 4 reserves the number of blocks specified by the namespace allocation command for NSID#1. The total number of blocks reserved for NSID#1 is managed by the virtual flash pool 81. The upper limit of the number of blocks that can be allocated to the namespace of NSID#1 is limited to be less than the total number of blocks reserved for NSID#1.

[0599] When the controller 4 receives a block allocation and deletion command including NSID#1 from the host 2, the controller 4 selects a block with the minimum number of deletions from the common free block pool 90, allocates the selected free block to the namespace of NSID#1, deletes the allocated block, notifies the host 2 of the physical address of the allocated and deleted block, and subtracts 1 from the total number of blocks managed by the virtual flash pool 81, that is, the number of remaining blocks that can be allocated to NSID#1. The number of remaining blocks that can be allocated to NSID#1 represents the current number of blocks that can be allocated to the namespace of NSID#1. The allocated and deleted block can be used as, for example, a write target block 91 for NSID#1.

[0600] If the current total number of blocks managed by the virtual flash pool 81 (the number of remaining blocks) is zero, even if the controller 4 receives a block allocation or deletion command containing NSID#1 from the host 2, the controller 4 will not allocate a new block to the namespace of NSID#1.

[0601] When the controller 4 receives a write command including NSID#1 from the host 2, the controller 4 writes the data specified by the write command to the write target block 91. The write command may include the physical address (both the block address and the page address) of the data to be written (direct address specification mode), or may include only the block address of the data to be written (automatic address generation mode), or may include only NSID#1.

[0602] When the write command includes only NSID#1, the physical address to which the data is to be written is automatically generated by the controller 4, similarly to the case of the automatic address generation mode. In this case, the data specified by the write command is written in the order of pages P0 to P255 in the current write target block 91. The controller 4 notifies the host 2 of the physical address (both the block address and the page address) of the write data.

[0603] When the current write target block 91 is full of data, the write target block 91 can be moved to the active block pool 92. The active block pool 92 manages a list of blocks (active blocks) currently used by NSID#1. When the current write target block 91 is full of data, the host 2 can send a block allocation or deletion command containing NSID#1 to the SSD 3 to request the allocation or deletion of a new write target block.

[0604] The host 2 can read out or delete any block in the active block pool 92. In addition, the host 2 can send a block return command to the SSD 3 to request the SSD 3 to return the block in the active block pool 92 to the common free block pool 90. For example, a deleted block, a block containing only data invalidated due to data update, or a block containing only data invalidated due to the data copy action, etc. is returned. In response to receiving the block return command, the controller 4 moves the block specified by the block return command to the common free block pool 90, and increases the total number of blocks managed by the virtual flash pool 81 (the number of remaining blocks) by 1.

[0605] The controller 4 also manages management information corresponding to the name space of NSID#n, the total number of reserved blocks, a list of allocated block addresses, the total number of deletions of NSID#n, and the like.

[0606] Namespace management of NSID#n is performed as follows.

[0607] When the controller 4 receives a namespace allocation command including NSID#n from the host 2 , the controller 4 reserves the number of blocks specified by the namespace allocation command for NSID#n. The total number of blocks reserved for NSID#n is managed by the virtual flash pool 82 .

[0608] When the controller 4 receives a block allocation and deletion command including NSID#n from the host 2, the controller 4 selects a block with the minimum number of deletions from the common free block pool 90, allocates the selected free block to the name space of NSID#n, deletes the allocated block, and subtracts 1 from the total number of blocks managed by the virtual flash pool 82, that is, the number of remaining blocks that can be allocated to NSID#n. The allocated and deleted block can be used as, for example, a write target block 93 for NSID#n.

[0609] If the current total number of blocks managed by the virtual flash pool 82 (the number of remaining blocks) is zero, even if the controller 4 receives a block allocation or deletion command containing NSID#n from the host 2, the controller 4 will not allocate a new block to the namespace of NSID#n.

[0610] When the controller 4 receives a write command including NSID#n from the host 2, the controller 4 writes the data specified by the write command into the write target block 93. The write command may include the physical address (both the block address and the page address) of the data to be written (direct address specification mode), or may include only the block address of the data to be written (automatic address generation mode), or may include only NSID#n.

[0611] When the write command includes only NSID#n, the physical address to which the data is to be written is automatically generated by the controller 4, similarly to the case of the automatic address generation mode. In this case, the data specified by the write command is sequentially written to pages P0 to P255 in the current write target block 93. The controller 4 notifies the host 2 of the physical address (both the block address and the page address) of the write data.

[0612] When the current write target block 93 is full of data, the write target block 93 can be moved to the active block pool 94. The active block pool 94 manages a list of blocks currently used by NSID#n. When the current write target block 93 is full of data, the host 2 can send a block allocation or deletion command containing NSID#n to the SSD 3 to request the allocation or deletion of a new write target block.

[0613] The host 2 can read out or delete any block in the active block pool 94. In addition, the host 2 can send a block return command to the SSD 3 to request the SSD 3 to return the block in the active block pool 94. In response to receiving the block return command, the controller 4 moves the block specified by the block return command to the common free block pool 90 and increases the total number of blocks managed by the virtual flash pool 82 (the number of remaining blocks) by 1.

[0614] The namespace management for the virtual NAND access management API 22 can also be performed in the same order as the namespace management for the physical NAND access management API 21. In the namespace management for the virtual NAND access management API 22, the number of virtual blocks to be secured can be managed instead of the number of blocks to be secured, and the list of virtual block addresses to be allocated can be managed instead of the list of block addresses to be allocated.

[0615] In addition, in the namespace management used by the virtual NAND access management API 22, the count value obtained by counting the number of deletion actions performed on the virtual blocks assigned to NSID#1 can be managed as the total number of deletions of NSID#1, and the count value obtained by counting the number of deletion actions performed on the virtual blocks assigned to NSID#n can be managed as the total number of deletions of NSID#n.

[0616] [Namespace allocation command]

[0617] Fig.55 Indicates a namespace allocation command. The namespace allocation command is a request to the SSD 3 to secure (or add) the number of blocks specified by the namespace allocation command.

[0618] The namespace assignment command contains the following input parameters.

[0619] (1) NSID: This input parameter value represents the identifier (ID) of the object namespace.

[0620] (2) Physical resource quantity: The physical resource quantity indicates the number of blocks to be secured. In the physical NAND access management API 21, the number of blocks to be secured is specified at the granularity of a block (physical block), and in the virtual NAND access management API 22, the number of blocks to be secured is specified at the granularity of a virtual block (a plurality of blocks constituting a virtual block).

[0621] In addition, the namespace allocation command may also include an input parameter indicating a processing priority.

[0622] The namespace assignment command contains the following output parameters.

[0623] (1) Physical resource quantity: The physical resource quantity indicates the number of blocks to be secured. In the physical NAND access management API 21, the number of blocks to be secured is indicated at the granularity of a block (physical block), and in the virtual NAND access management API 22, the number of blocks to be secured is indicated at the granularity of a virtual block (a plurality of blocks constituting a virtual block).

[0624] [Order of namespace allocation processing]

[0625] Fig.56 The flowchart represents the order of the namespace allocation processing performed by SSD3.

[0626] The controller 4 of the SSD 3 receives a namespace allocation command from the host 2 (step S141). Based on the number of remaining blocks in the common free block pool 90, it is determined whether the number of blocks specified by the input parameter (physical resource amount) in the namespace allocation command can be ensured (step S142). As described above, in the physical NAND access management API 21, the number of blocks to be ensured is specified in the granularity of blocks (physical blocks), and in the virtual NAND access management API 22, the number of blocks to be ensured is specified in the granularity of virtual blocks (multiple blocks constituting one virtual block).

[0627] If the number of remaining blocks (or remaining virtual blocks) is greater than the specified number (yes in step S142), the controller 4 secures the specified number of blocks (or virtual blocks) for the namespace of the NSID specified by the namespace allocation command (step S143), and then sends a command completion response including an output parameter indicating the number of secured blocks (or virtual blocks) to the host 2 (step S144).

[0628] If the number of remaining blocks (or remaining virtual blocks) is less than the specified number (No in step S142), the controller 4 notifies the host 2 of an error (step S145). The host 2 that receives the error report can change the number of blocks (or virtual blocks) to be secured.

[0629] [Namespace block allocation and deletion commands]

[0630] Fig.57 Indicates the block allocation and deletion commands for namespaces.

[0631] The namespace block allocation and deletion commands have the following input parameters.

[0632] (1) Processing priority: The processing priority indicates the priority of the command.

[0633] (2) NSID: NSID represents the ID of the namespace to which the block (or virtual block) should be allocated.

[0634] The namespace block allocation and deletion commands have the following output parameters.

[0635] (1) End status: Returns to host 2 the end status indicating success or error of the block allocation or deletion command.

[0636] (2) Block address: Returns the block address of the allocated block (or the virtual block address of the allocated virtual block) to the host 2.

[0637] (3) Number of remaining blocks: The number of remaining blocks (or the number of remaining virtual blocks) guaranteed for the NSID is returned to the host 2.

[0638] [The order of allocating and deleting namespace blocks]

[0639] Fig.58 The flowchart of FIG. 1 shows the procedure of the block allocation and deletion process executed by the SSD 3. Here, the block allocation and deletion process used by the physical NAND access management API 21 is illustrated.

[0640] The controller 4 of the SSD 3 receives a block allocation and deletion command including an NSID from the host 2 (step S151 ). The controller 4 determines whether there is a remaining block for the NSID (step S152 ).

[0641] If there are remaining blocks for the NSID (yes in step S152), the controller 4 allocates a block from the common free block pool 90 as the write object block for the specified NSID, and automatically deletes the allocated block (step S152). The controller 4 subtracts 1 from the number of remaining blocks for the specified NSID (step S154). The controller 4 updates the total number of deletions corresponding to the specified NSID (step S155). In step S155, the controller 4 increases the total number of deletions corresponding to the specified NSID by 1. In addition, the controller 4 generates a return value (output parameter) and sends a command completion response containing the return value to the host 2 (step S156).

[0642] On the other hand, if there are no remaining blocks for the NSID (No in step S152), the controller 4 will send a command completion response including an error status indicating that a new block cannot be allocated because the number of remaining blocks for the NSID is zero to the host 2 (step S157).

[0643] In the block allocation and deletion process for the virtual NAND access management API 22, the controller 4 determines whether there are any remaining virtual blocks for the NSID (step S152).

[0644] If there are remaining virtual blocks for the NSID (yes in step S152), the controller 4 allocates a virtual block from the common free block pool 90 as the write object block (write object virtual block) for the specified NSID, and automatically deletes the allocated virtual block (step S152). The controller 4 subtracts 1 from the number of remaining virtual blocks for the specified NSID (step S154). The controller 4 updates the total number of deletions corresponding to the specified NSID (step S155). In step S155, the controller 4 increases the total number of deletions corresponding to the specified NSID by 1. In addition, the controller 4 generates a return value (output parameter) and sends a command completion response containing the return value to the host 2 (step S156).

[0645] On the other hand, if there are no remaining virtual blocks for the NSID (No in step S152), the controller 4 will send a command completion response to the host 2 (step S157) including an error status indicating that a new block cannot be allocated because the number of remaining virtual blocks for the NSID is zero.

[0646] [Delete command for namespace]

[0647] Fig.59 Represents a delete command used to delete a specific block assigned to a namespace.

[0648] The delete command contains the following input parameters.

[0649] (1) Block address: This input parameter value indicates the block address of the block to be deleted. In the delete command used by the virtual NAND access management API 22, this input parameter value indicates the virtual block address of the virtual block to be deleted instead of the block address.

[0650] (2) Processing priority: The input parameter value indicates the priority of the command.

[0651] (3) NSID: This input parameter value indicates the NSID corresponding to the block (or virtual block) to be deleted.

[0652] The delete command contains the following output parameters.

[0653] (1) End status: Returns the success or error of the deletion command to the host.

[0654] (2) Block address: This output parameter value indicates the block address of the block to be deleted. In the delete command used by the virtual NAND access management API 22, this output parameter value indicates the virtual block address of the virtual block to be deleted.

[0655] (3) Total number of deletions: This output parameter value indicates the total number of deletions of each block assigned to the NSID. In the deletion command used by the virtual NAND access management API 22, this output parameter value indicates the total number of deletions of each virtual block assigned to the NSID.

[0656] [Deletion process order]

[0657] Fig.60 The flowchart of FIG. 1 shows the order of the deletion process executed by the SSD 3. Here, the deletion process used by the physical NAND access management API 21 is illustrated.

[0658] The controller 4 of the SSD 3 receives a delete command from the host 2 (step S171). The controller 4 executes a delete action for deleting the block specified by the delete command (step S172), increases the number of deletions of the deleted block by 1 (step S173), and increases the total number of deletions corresponding to the NSID to which the deleted block is assigned by 1 (step S174). In the case where the delete command includes an NSID, the NSID to which the deleted block is assigned is specified by the NSID in the delete command. On the other hand, in the case where the delete command does not include an NSID, the NSID to which the deleted block is assigned can be specified based on the block address of the deleted block and a list of block addresses assigned to each NSID.

[0659] Furthermore, a return value (output parameter) is generated, and a command completion response including the return value is sent to the host 2 (step S175).

[0660] In the deletion processing used by the virtual NAND access management API 22, the controller 4 executes a deletion action for deleting multiple blocks within the virtual block specified by the deletion command (step S172), increases the number of deletions of the deleted virtual block by 1 (step S173), and increases the total number of deletions corresponding to the NSID assigned to the deleted virtual block by 1 (step S174).

[0661] [Block return command]

[0662] Fig.61 The block return command applied to the SSD 3 is used to return the blocks in the active block pool corresponding to a specific namespace to the common free block pool 90 .

[0663] The block return command contains the following input parameters.

[0664] (1) Block address: This input parameter value indicates the block address of the block to be returned. In the block return command used by the virtual NAND access management API 22, this input parameter value indicates the virtual block address of the virtual block to be returned instead of the block address.

[0665] (2) Processing priority: The input parameter value indicates the priority of the command.

[0666] (3) NSID: This input parameter value indicates the NSID corresponding to the block (or virtual block) to be returned.

[0667] The block return command contains the following output parameters.

[0668] (1) End status: Returns the success or error of the block return command to the host.

[0669] (2) Number of remaining blocks: This output parameter value indicates the number of remaining blocks after the block return. In the block return command used by the virtual NAND access management API 22, this output parameter value indicates the number of remaining virtual blocks after the virtual block return.

[0670] [Order of block return processing]

[0671] Fig.62 The flowchart of FIG. 1 shows the procedure of the block return process executed by the SSD 3. Here, the block return process used by the physical NAND access management API 21 is illustrated and described.

[0672] The controller 4 of the SSD 3 receives a block return command from the host 2 (step S181). The controller 4 moves the block specified by the block return command from the active block pool corresponding to the NSID specified by the block return command to the common free block pool 90 (step S182). As a result, the allocation of the block to the NSID is released, and the block is managed by the common free block pool 90 as a free block without valid data.

[0673] The controller 4 increases the number of remaining blocks corresponding to the designated NSID by 1 (step S183 ). Furthermore, the controller 4 generates a return value (output parameter) and sends a command completion response including the return value to the host 2 (step S184 ).

[0674] In the block return processing used by the virtual NAND access management API 22, the controller 4 moves the virtual block specified by the block return to the common free block pool 90 (step S182), and increases the number of remaining virtual blocks corresponding to the specified NSID by 1 (step S183), and then sends a command completion response containing a return value to the host 2 (step S184).

[0675] [Deletion count acquisition command]

[0676] Fig.63 Indicates a deletion count acquisition command for a namespace applied to SSD3. The deletion count acquisition command requests SSD3 to be notified of the total number of deletions of a specific namespace.

[0677] The command to obtain the number of deletions contains the following input parameters.

[0678] (1) NSID: This input parameter value indicates the target NSID. When this input parameter value is a special value, all NSIDs may be determined as target NSIDs.

[0679] (2) Processing priority: The input parameter value indicates the priority of the command.

[0680] The command to obtain the number of deletions contains the following output parameters.

[0681] (1) End status: Returns the success or error of the deletion count acquisition command to the host.

[0682] (2) Total number of deletions: The output parameter value indicates the total number of deletions of the specified NSID.

[0683] [Deletion notification processing]

[0684] Fig.64The flowchart of FIG. 1 shows the procedure of the deletion count notification process executed by the SSD 3. Here, the deletion count notification process used by the physical NAND access management API 21 is described by way of example.

[0685] When the controller 4 of the SSD 3 receives the deletion count acquisition command from the host 2 , the controller 4 determines whether the NSID specified by the deletion count acquisition command is designated or all NSIDs are designated (step S191 ).

[0686] If a specific NSID is specified (yes in step S191), the controller 4 obtains the current total number of deletions (count value) of the specific NSID (step S192), and sends a command completion response containing the current total number of deletions of the specific NSID to the host 2 (step S194).

[0687] If all NSIDs are specified (No in step S191), the controller 4 obtains a list of the current total number of deletions corresponding to all NSIDs (step S193), and sends a command completion response containing a list of the current total number of deletions corresponding to all NSIDs to the host 2 (step S194).

[0688] In the deletion count notification process used by the virtual NAND access management API 22, the number of deletion operations performed on each virtual block allocated to the specified specific NSID is counted, and the count value is notified to the host 2 as the total deletion count of the specified specific NSID.

[0689] Here, the process of notifying the host 2 of the total number of deletions of the NSID specified by the deletion count acquisition command is described, but a deletion count acquisition command including a parameter specifying either a block address or a virtual block address may be used instead of the NSID.

[0690] The delete command used by the physical NAND access management API 21 includes a block address (a physical address of a specified block). The controller deletes the block specified by the block address in the delete command received from the host 2, manages the number of deletions of each block in group #Y, and, when receiving a delete count acquisition command including a certain block address from the host 2, notifies the host 2 of the number of deletions of the block specified by the block address in the delete count acquisition command.

[0691] The delete command used by the virtual NAND access management API 22 includes a virtual block address (a physical address that specifies a virtual block). The controller deletes multiple blocks in the virtual block specified by the virtual block address in the delete command received from the host 2, manages the number of deletions of each virtual block in the group #X, and when receiving a delete count acquisition command including a certain virtual block address from the host 2, notifies the host 2 of the number of deletions of the virtual block specified by the virtual block address in the delete count acquisition command.

[0692] [Other commands for namespace management]

[0693] The controller 4 also supports a namespace disintegration command. The namespace disintegration command requests the controller 4 to delete (disintegrate) the namespace. The namespace disintegration command may also include an input parameter representing the number of blocks currently allocated to the specific NSID (the number of blocks to be disintegrated). The number of blocks is the number of physical blocks currently allocated to the specific NSID in the physical NAND access management API 21, and the number of virtual blocks currently allocated to the specific NSID in the virtual NAND access management API 22. In response to receiving a namespace disintegration command including a specific NSID from the host 2, the controller 4 moves all blocks in the virtual flash pool corresponding to the specific NSID as free blocks to the common free blocks 90. In addition, the controller 4 sends a command completion response to the namespace disintegration command to the host 2. The command completion response may also include a return value representing the number of disintegrated blocks.

[0694] The host 2 can increase or decrease the namespace by using the namespace assignment command and the namespace destruction command.

[0695] [Host Configuration]

[0696] Fig.65 An example of the hardware configuration of an information processing device functioning as the host computer 2 is shown.

[0697] The information processing device is implemented as a server computer or a personal computer and 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.

[0698] The processor 101 is a CPU configured to control the operation of each component of the information processing device. The processor 101 executes various programs loaded from any one of the plurality of SSDs 3 to the main memory 102. The main memory 102 includes a random access memory such as a DRAM. The program executed by the processor 101 includes the application software layer 41, the OS 42, the file system 43, and the FTL 44. The program executed by the processor 101 may also include a resource management unit 45.

[0699] The resource management unit 45 may send a deletion count acquisition command to SSD3, obtain the total deletion count of each namespace from SSD3, and determine the consumption of physical resources of SSD3 caused by each namespace based on the obtained total deletion count of each namespace. Assuming that the consumption of physical resources of SSD3 caused by a specific namespace is greater than a threshold, the resource management unit 45 may execute a process for increasing the number of blocks that should be ensured for the specific namespace. In this case, the resource management unit 45 may send a namespace allocation command to SSD3 requesting that a specified number of blocks be added to the specific namespace. As a result, the size of the over-provisioned area of ​​the specific namespace is increased, thereby reducing the write amplification of the specific namespace, and as a result, the consumption of physical resources of SSD3 caused by the specific namespace can be reduced.

[0700] In addition, as described above, the data center provider may also determine the rental fee corresponding to the namespace based on the number of blocks (or the number of virtual blocks) ensured for the namespace and the total number of deletions corresponding to the namespace. In this case, the resource management unit 45 may perform a service for supporting the data center provider in determining the rental fee. For example, the basic rental fee associated with a certain namespace is first determined by the capacity (number of blocks) of the area corresponding to the namespace. Furthermore, the total fee after adding the additional fee obtained by the function of the total number of deletions to the basic rental fee can be used as the rental fee associated with the namespace for determination.

[0701] When the user who rents the namespace requests to increase the number of blocks to be reserved for the namespace, the resource management unit 45 may exempt the additional fee from being charged and set a new rental fee based on the total number of the additional blocks and the number of already reserved blocks. Furthermore, the resource management unit 45 may send a namespace allocation command to the SSD 3 requesting that the number of blocks specified by the user be added to the specific namespace.

[0702] In addition, the resource management unit 45 can work together with the FTL 44 to allow each application to control the NAND memory 5 of the SSD 3 using the physical NAND access management API / virtual NAND access management API. For example, in response to receiving a first read, write, or delete request from a user (a certain application or a certain user terminal) including the physical address of one of the blocks for the physical NAND access management API 21 in the designated NAND memory 5, the resource management unit 45 sends the read command, write command, or delete command to the SSD 3 to control the read action, write action, or delete action on the designated block. In addition, in response to receiving a second read, write, or delete request from a user (a certain application or a certain user terminal) including the physical address (virtual block address) of one of the virtual blocks in the designated NAND memory 5, the resource management unit 45 sends the read command, write command, or delete command to the SSD 3 to control the read action, write action, or delete action on the designated virtual block.

[0703] Furthermore, the resource management unit 45 can also perform the following control: based on the latest page address of the readable data notified from the SSD3, the storage area (the memory in the host 2 that holds the written data for a certain period of time, or the NAND memory 5 in the SSD3) that should be responsive to the read request from the user (a certain application or a certain user terminal) is automatically changed. In this case, the resource management unit 45 can read and access the memory in the host 2 in response to the read request for the specific data before the specific data written to the SSD3 becomes readable, and can read and access the NAND memory 5 in the SSD3 in response to the read request for the specific data after the specific data becomes readable.

[0704] In addition, the resource management unit 45 can work together with the FTL 44 to manage multiple namespaces. The resource management unit 45 sends a command for reading, writing, or deleting one of the multiple first blocks allocated to the first namespace among the multiple blocks in the NAND memory 5 in the SSD 3 to the SSD 3. In addition, the resource management unit 45 sends a command requesting acquisition of the number of deletions associated with the first namespace to the SSD 3, and obtains from the SSD 3 a count value obtained by counting the number of deletion operations performed on the multiple first blocks.

[0705] Furthermore, the resource management unit 45 sends a command for securing blocks for the first namespace to the SSD 3, thereby causing the SSD 3 to secure the first number of blocks for the first namespace and to limit the upper limit of the number of the plurality of first blocks that can be allocated to the first namespace to be less than the first number. Furthermore, the resource management unit 45 is configured to send a command for adding the number of blocks to be secured for the first namespace to the SSD 3, thereby causing the SSD 3 to add the second number of blocks as blocks to be secured for the first namespace and to increase the upper limit of the number of the first blocks that can be allocated to the first namespace to the sum of the first number and the second number.

[0706] Then, the resource management unit 45 controls garbage collection (data copy operation) by sending the data copy command to the SSD 3 .

[0707] That is, the processor 101 manages the mapping between each logical block address and each physical address of the NAND memory 5 by executing the FTL 44. The processor 101 further controls garbage collection (data copy operation) by executing the resource management unit 45.

[0708] In this case, the processor 101 sends a data copy command requesting to copy only valid data to the SSD 3. As described above, the data copy command includes a copy source block, a copy start page in the copy source block, a copy target block, a transfer start page in the copy target block, bitmap data indicating whether the data of each page in the copy source block is valid data or invalid data, and an end condition specifying either the number of valid data to be copied before the copy is completed or the number of invalid data to be detected before the copy is completed.

[0709] Furthermore, the processor 101 receives data copy information indicating the location in the copy destination block where the valid data is stored for each valid data copied to the copy destination block from the SSD 3. The processor 101 updates the address conversion table based on the data copy information.

[0710] Then, the processor 101 controls the next garbage collection (data copy operation) based on the position of the data to be copied next time notified from the SSD 3 .

[0711] In addition, the processor 101 executes a basic input / output system (BIOS) stored in the BIOS-ROM 103 which is a nonvolatile memory. The BIOS is a system program for hardware control.

[0712] The network controller 105 is a communication device such as a wired LAN controller or a wireless LAN controller. The peripheral interface controller 106 is configured to perform communication with a peripheral device such as a USB device.

[0713] The controller 107 is configured to perform communication with devices connected to the plurality of connectors 107A. In this embodiment, the plurality of SSDs 3 are connected to the plurality of connectors 107A. The controller 107 is a SAS expander, a PCIe switch, a PCIe expander, a flash array controller, or a RAID controller.

[0714] EC108 functions as a system controller configured to perform power management of the information processing device. EC108 powers on and off the information processing device according to the operation of the power switch by the user. EC108 is implemented as a processing circuit such as a single-chip microcontroller. EC108 may also have a built-in keyboard controller that controls input devices such as a keyboard (KB).

[0715] Fig.66 A configuration example of an information processing device including a plurality of SSDs 3 and a host 2 is shown.

[0716] The information processing device includes a thin box-shaped housing 201 that can be housed on a stand. A plurality of SSDs 3 may be arranged in the housing 201. In this case, each SSD 3 is inserted into a slot provided on a front surface 201A of the housing 201 in a detachable manner.

[0717] The system board (main board) 202 is disposed in the housing 201. Various electronic components including the CPU 101, the memory 102, the network controller 105, and the controller 107 are mounted on the system board (main board) 202. These electronic components function as the host computer 2.

[0718] As described above, according to the namespace management function of this embodiment, the number of deletion actions can be counted for each namespace, and the number of deletions of each namespace can be notified to the host 2 in response to a request from the host 2. Therefore, the host 2 can be provided with a measure of the degree of consumption of the NAND memory 5 caused by each namespace, and the host 2 can execute a countermeasure for suppressing the consumption of the NAND memory 5 caused by each namespace.

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

[0720] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other ways, and various omissions, substitutions, and changes can be made without departing from the scope of the invention. These embodiments or their variations are included in the scope or spirit of the invention and are included in the invention described in the claims and their equivalents.

Claims

1. A storage system, characterized in that Include: A non-volatile memory comprising a plurality of blocks, each of the plurality of blocks being a unit for a data deletion action; and A controller is electrically connected to the non-volatile memory and is configured as follows: Managing a plurality of namespaces, the plurality of namespaces including at least a first namespace; managing a plurality of free blocks among the plurality of blocks, each of the plurality of free blocks being shared by a plurality of namespaces; In response to receiving a first command from a host, allocating a first number of blocks from the plurality of free blocks to the first namespace, the first command including an identifier of the first namespace; Counting the number of data deletion actions performed on each of the first number of blocks allocated to the first namespace, the number of data deletion actions being: the number of data deletion actions performed on each of the first number of blocks after the first number of blocks are allocated to the first namespace, and excluding the number of data deletion actions performed on each of the first number of blocks before the first number of blocks are allocated to the first namespace; and Obtain the total number of data deletion actions performed on the first number of blocks allocated to the first namespace, the total number of data deletion actions excluding the number of data deletion actions performed on each of the first number of blocks before allocating the first number of blocks to the first namespace.

2. The storage system according to claim 1, characterized in that: The controller is also configured as follows: In response to receiving a second command from the host, first information is notified to the host based on the total number of data deletion actions, the second command including the identifier of the first namespace.

3. The storage system according to claim 2, characterized in that: The controller is configured to notify the host computer of the total number of data deletion operations as the first information.

4. The storage system according to claim 2, characterized in that: The first information indicates a degree of consumption of the first namespace.

5. The storage system according to claim 1, characterized in that: Each of the plurality of blocks is a physical block.

6. The storage system according to claim 1, characterized in that: Each of the plurality of blocks is a virtual block including a plurality of physical blocks.

7. The storage system according to claim 1, characterized in that: The first number of blocks allocated to the first namespace includes overprovision blocks.

8. The storage system according to claim 1, characterized in that: The controller is also configured as follows: In response to receiving a third command from the host, the overprovisioned capacity of the first namespace is increased by additionally allocating a specified second number of blocks to the first namespace, the third command including the identifier of the first namespace and the second number of blocks to be appended to the first namespace.

9. The storage system according to claim 8, characterized in that: The controller is also configured as follows: In response to receiving a fourth command from the host, the first block is decomposed from the first namespace, the fourth command including the identifier of the first namespace and the identifier of the first block.

10. The storage system according to claim 1, characterized in that: The controller is also configured as follows: A second block is allocated as one of the first number of blocks from the plurality of free blocks to the first namespace, and a number of data deletion operations performed on the second block is a minimum number of data deletion operations performed on the plurality of free blocks.

11. A method for controlling a non-volatile memory, characterized in that: The non-volatile memory includes a plurality of blocks, each of the plurality of blocks is a unit for a data deletion operation, and the method includes: Managing a plurality of namespaces, the plurality of namespaces including at least a first namespace; managing a plurality of free blocks among the plurality of blocks, each of the plurality of free blocks being shared by a plurality of namespaces; In response to receiving a first command from a host, allocating a first number of blocks from the plurality of free blocks to the first namespace, the first command including an identifier of the first namespace; Counting the number of data deletion actions performed on each of the first number of blocks allocated to the first namespace, the number of data deletion actions being: the number of data deletion actions performed after the first number of blocks are allocated to the first namespace, and excluding the number of data deletion actions performed on each of the first number of blocks before the first number of blocks are allocated to the first namespace; as well as Obtain the total number of data deletion actions performed on the first number of blocks allocated to the first namespace, the total number of data deletion actions excluding the number of data deletion actions performed on each of the first number of blocks before allocating the first number of blocks to the first namespace.

12. The method according to claim 11, characterized in that Also includes: In response to receiving a second command from the host, first information is notified to the host based on the total number of data deletion actions, the second command including the identifier of the first namespace.

13. The method according to claim 12, characterized in that: The total number of data deletion operations is notified to the host as the first information.

14. The method according to claim 12, characterized in that: The first information indicates a degree of consumption of the first namespace.

15. The method according to claim 11, characterized in that: Each of the plurality of blocks is a physical block.

16. The method according to claim 11, characterized in that: Each of the plurality of blocks is a virtual block including a plurality of physical blocks.

17. The method according to claim 11, characterized in that: The first number of blocks allocated to the first namespace includes overprovision blocks.

18. The method according to claim 13, characterized in that Also includes: In response to receiving a third command from the host, the overprovisioned capacity of the first namespace is increased by additionally allocating a specified second number of blocks to the first namespace, the third command including the identifier of the first namespace and the second number of blocks to be appended to the first namespace.

19. The method according to claim 18, characterized in that Also includes: In response to receiving a fourth command from the host, the first block is decomposed from the first namespace, the fourth command including the identifier of the first namespace and the identifier of the first block.

20. The method according to claim 11, characterized in that Also includes: A second block is allocated as one of the first number of blocks from the plurality of free blocks to the first namespace, and the number of data deletion operations performed on the second block is the smallest among the numbers of data deletion operations performed on the plurality of free blocks.

Images