Memory system and control method

Abstract

Embodiments generally relate to a memory system and a control method for controlling a non-volatile memory of the memory system. According to one embodiment, the memory system includes a non-volatile memory having a plurality of blocks. A minimum unit of a data erase action in the memory system is one block. A controller is electrically connected to the non-volatile memory and is configured to perform a copy action in response to a first command from a host, the first command requesting a secure erase of secure erase object data stored in a first logical area identified by a first logical area identifier, the copy action copying valid data other than any secure erase object data from one or more first blocks of the plurality of blocks in which the secure erase object data is stored to one or more copy destination blocks of the plurality of blocks. After the copy action, the controller performs a data erase action on the one or more first blocks.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based upon and claims the benefit of priority from Japanese patent application No. 2020-110307, ​​filed on June 26, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] In general, embodiments described herein relate to a memory system and a control method for controlling a nonvolatile memory of the memory system. Background Art

[0004] In recent years, memory systems having nonvolatile memories have become very popular. As one of such memory systems, solid-state drives (SSDs) having NAND-type flash memories are well known.

[0005] Overwriting, block erasing, and cryptographic erasing are known as secure erase methods, and they securely and reliably delete data stored on SSDs. Secure erase methods are categorized into physical secure erase methods, which physically and irreversibly render stored data unreadable, and logical secure erase methods, which render stored data logically unreadable. Overwriting and block erasing are each examples of physical secure erase methods. Cryptographic erase is an example of logical secure erase methods.

[0006] In a cryptographic erase, the encryption key used to encrypt the data stored in the SSD is erased through a physical secure erase method. As a result, the stored data can no longer be decrypted and can be said to be logically erased.

[0007] Recently, there is a need to perform secure erasure on specific data among all data stored in a memory system such as an SSD through a physical secure erasure method. Summary of the Invention

[0008] An object of the present invention is to provide a memory system and a control method capable of securely erasing specific data using a physical secure erasure method.

[0009] In general, according to one embodiment, a memory system includes a non-volatile memory having a plurality of blocks. A minimum unit for a data erasing action is a block. A controller in the memory system is electrically connected to the non-volatile memory. The controller is configured to: in response to a first command from a host, the first command requesting a secure erase of secure erase object data stored in a first logical area identified by a first logical area identifier, perform a copy action that copies valid data other than any secure erase object data from one or more first blocks of the plurality of blocks in which the secure erase object data is stored to one or more copy-destination blocks of the plurality of blocks. The controller is further configured to, after the copy action, perform a data erasing action on the one or more first blocks.

[0010] According to the embodiment, specific data can be securely erased by a physical secure erase method. BRIEF DESCRIPTION OF DRAWINGS

[0011] Figure 1 is a block diagram of an information processing system including the memory system according to the first embodiment.

[0012] Figure 2 is a diagram of a logical-to-physical address translation table (L2P table) used in the memory system according to the first embodiment.

[0013] Figure 3 is a diagram showing a plurality of namespaces managed in the memory system according to the first embodiment.

[0014] Figure 4 Aspects related to a write action and a physical secure erase action performed in the memory system according to the first embodiment are described.

[0015] Figure 5 is a flowchart showing a procedure of a physical secure erase action performed in the memory system according to the first embodiment.

[0016] Figure 6A and Figure 6B is a diagram showing an example of a data structure written in each block.

[0017] Figure 7 is a flowchart showing a processing procedure of an I / O command that is not completed when a first specific command is received.

[0018] Figure 8 is a flowchart showing a processing procedure of an I / O command received during execution of the first specific command.

[0019] Figure 9A is a diagram showing an example of contents of each active block before a physical secure erase action is started.

[0020] Figure 9B FIG. 3 is a diagram showing an example of the contents of each free block before a physical secure erase operation is started.

[0021] Figure 10 FIG. 4 is a diagram showing an example of the contents of each active block after a deallocation operation is performed.

[0022] Figure 11A FIG. 5 is a diagram showing an example of the contents of each active block after a garbage collection operation is performed.

[0023] Figure 11B FIG. 6 is a diagram showing an example of the contents of each free block after a garbage collection operation is performed.

[0024] Figure 12 FIG. 7 is a flowchart showing a procedure of a physical secure erase operation performed in the memory system according to the second embodiment.

[0025] Figure 13A FIG. 8 is a flowchart showing a procedure of a physical secure erase operation performed in the memory system according to the third embodiment.

[0026] Figure 13B FIG. 9 is a flowchart showing a procedure of a deallocation operation and a garbage collection operation performed in the physical secure erase operation performed in the memory system according to the third embodiment.

[0027] Figure 13C FIG. 10 is a flowchart showing another procedure of a deallocation operation and a garbage collection operation performed in the physical secure erase operation performed in the memory system according to the third embodiment.

[0028] Figure 14A FIG. 11 is a flowchart showing a procedure of a physical secure erase operation performed in the memory system according to the fourth embodiment.

[0029] Figure 14B FIG. 12 is a flowchart showing a procedure of a deallocation operation and a garbage collection operation performed in the physical secure erase operation performed in the memory system according to the fourth embodiment.

[0030] Figure 14C FIG. 13 is a flowchart showing another procedure of a deallocation operation and a garbage collection operation performed in the physical secure erase operation performed in the memory system according to the fourth embodiment.

[0031] Figure 15 FIG. 14 is a flowchart showing a procedure of a physical secure erase operation according to the fifth embodiment.

[0032] Figure 16 FIG. 15 is a flowchart showing a procedure of a physical secure erase operation according to the sixth embodiment. DETAILED DESCRIPTION

[0033] Embodiments provide a memory system and a control method capable of performing secure erasure on only specific data among all stored data by a physical secure erasure method.

[0034] Hereinafter, certain example embodiments will be described with reference to the accompanying drawings.

[0035] (First Embodiment)

[0036] A configuration of an information processing system including a memory system according to the first embodiment will be described. Figure 1 is a block diagram showing a configuration example of an information processing system 1 including a memory system according to the first embodiment. The memory system in this example is a semiconductor storage device configured to write data to and read data from a nonvolatile memory. The memory system is implemented as, for example, an SSD 3 including a NAND-type flash memory.

[0037] The information processing system 1 includes a host 2 (host device) and the SSD 3. The host 2 is an information processing device configured to control the SSD 3. Possible examples of the host 2 include a personal computer, a server computer, a mobile terminal, and a vehicle-mounted device.

[0038] The SSD 3 can be connected to the host 2 via a cable or a network. Alternatively, the SSD 3 can be built in or installed in the host 2.

[0039] An interface for connecting the host 2 and the SSD 3 can use Serial ATA (SATA), Serial Attached SCSI (SAS), Universal Flash Storage (UFS), PCI Express (PCIe) or the like. However, the present embodiment is not limited thereto.

[0040] The SSD 3 includes a controller 4 and a nonvolatile memory (for example, a NAND-type flash memory 5). The SSD 3 can also have a random access memory, for example, a dynamic random access memory (DRAM) 6.

[0041] The NAND-type flash memory 5 includes a memory cell array having a plurality of memory cells arranged in a matrix shape. The NAND-type flash memory 5 can be a flash memory of a two-dimensional structure type or a flash memory of a three-dimensional structure type.

[0042] The memory cell array of the NAND-type flash memory 5 includes a plurality of blocks BLK0 to BLKx-1. Each of the blocks BLK0 to BLKx-1 contains a plurality of pages (here, pages P0 to Py-1). Each page contains a plurality of memory cells connected to the same word line. Each of the blocks BLK0 to BLKx-1 is a unit of a data erasing operation (hereinafter, also referred to as block erasing) for erasing data of the NAND-type flash memory 5. In this context, the blocks are also referred to as "erase blocks", "physical blocks", or "physical erase blocks". The pages P0 to Py-1 are units of a data writing operation and a data reading operation.

[0043] The controller 4 can be implemented by a circuit such as a system on chip (SoC). The controller 4 is electrically connected to the NAND-type flash memory 5 via a NAND interface 13, which is compatible with a Toggle NAND flash interface or an Open NAND flash interface (ONFI), but is not limited thereto. The controller 4 operates as a memory controller configured to control the NAND-type flash memory 5.

[0044] The controller 4 can function as a flash translation layer (FTL) configured to perform data management and block management of the NAND-type flash memory 5.

[0045] The data management performed by the FTL includes: (1) management of mapping information representing a correspondence between each logical region identifier and each physical address of the NAND-type flash memory 5; and (2) processing for hiding limitations of the NAND-type flash memory 5 (e.g., a read / write operation in a page unit and an erasing operation in a block unit).

[0046] The logical region identifier can be a namespace identifier, a logical address, or a combination of a namespace identifier and a logical address.

[0047] In this context, the host 2 uses a logical address to specify an address in a logical address space of the SSD 3. As the logical address, a logical block address (LBA) or a key of a key value store can be used.

[0048] The controller 4 is configured to create and manage a plurality of namespaces. The plurality of namespaces are logical address ranges independent of each other. The plurality of namespaces are used to make one storage device act as a plurality of separate / different storage devices. The host 2 uses the plurality of namespaces to access the SSD 3. The host 2 uses a namespace identifier to specify a namespace.

[0049] The management of the mapping between each logical area identifier used by the host 2 to access the SSD 3 and each physical address (physical block address) PBA of the NAND type flash memory 5 is performed by using an address conversion table called a logical-to-physical address conversion table (L2P table) 37. The logical area identifier in the L2P table includes a logical address. The controller 4 uses the L2P table 37 to manage the mapping between each logical area identifier and each physical address. The physical address corresponding to a certain logical area identifier indicates the physical storage location in the NAND type flash memory 5 where the data corresponding to the logical area identifier was most recently written. When the power of the SSD 3 is turned on (booted), the L2P table 37 can be loaded from the NAND type flash memory 5 into the DRAM 6.

[0050] When using an LBA as a logical area identifier, the L2P table 37 manages the mapping between each LBA and each physical address PBA in a predetermined management size called a cluster. When the size of the sector designated by the LBA is smaller than the size of the cluster, bitmap data indicating whether the data of each sector in each cluster is valid data or invalid data can also be stored in the L2P table 37.

[0051] When using a key of a key-value store as a logical area identifier, the L2P table 37 can manage, for example, a correspondence relationship between a hash value of each key, a pointer to each key, a unique number corresponding to each key, the size of the value corresponding to each key, and a physical address list including one or more physical addresses where the value corresponding to each key is stored, but is not limited thereto.

[0052] Figure 2 is a diagram illustrating a configuration example of the L2P table 37. Here, a configuration example of the L2P table 37 when a logical address such as an LBA is used as a logical area identifier will be described. The L2P table 37 manages the mapping between each logical address in the logical address space of the SSD 3 and each physical address in the physical address space of the NAND type flash memory 5 in units of a predetermined management size called a cluster. The size of a single cluster is an integer multiple of the size of the sector (also called a logical block when the logical address is an LBA) designated by the logical address. Examples of the sector size are 512B or 4KiB, and examples of the cluster size are 4KiB. In a large-capacity SSD, the size of the cluster can be larger than 4KiB. Data corresponding to a plurality of clusters can be stored in a single page. An example of the size of a single page is 16KiB.

[0053] In the L2P table 37, the physical address corresponding to a certain logical address indicates the most recent physical storage location in the NAND type flash memory 5 where the data corresponding to the logical address was written.

[0054] The L2P table 37 includes a plurality of entries corresponding to a plurality of logical addresses, respectively. Each L2P table entry corresponding to a certain logical address stores a physical address associated with the logical address. For example, if the controller 4 writes data corresponding to a certain logical address into a certain physical storage location in the NAND-type flash memory 5, the controller 4 updates the L2P table 37 to associate a physical address PBA representing the storage location with the logical address.

[0055] Figure 2 A case is shown in which the physical addresses PBA0, PBA2, PBA1, PBA4, PBA5, and PBA6 are associated with the logical addresses 0x000, 0x001, 0x002, 0x005, 0x006, and 0x007, respectively. When data corresponding to a certain logical address has not yet been written into the NAND-type flash memory 5, a predetermined constant (e.g., NULL: null value) can be stored in the entry corresponding to the logical address.

[0056] Returning to the description of Figure 1 In the NAND-type flash memory 5, in each erase cycle (program / erase cycle) of a block containing a page, data can be written into the page only once. That is, new data cannot be directly overwritten into an area in the block where data has already been written. Therefore, when already-written data is updated before an erase cycle, the controller 4 writes the new (updated) data into an area in the block (or another block) that has not yet been written, and regards the previously-written data as invalid data. In other words, the controller 4 writes updated data corresponding to a certain logical area identifier into another physical storage location, instead of writing into the physical storage location where the previous data corresponding to the logical area identifier is stored. Then, the controller 4 updates the L2P table 37 to associate a new physical address for the newly-written physical storage location with the logical area identifier, and invalidates the previous data location.

[0057] The block management performed by the FTL can also include management of defective blocks (bad blocks), wear leveling, and garbage collection (compaction).

[0058] Wear leveling is an action for leveling the number of rewrites (number of program / erase cycles) of each block.

[0059] Garbage collection is an action for reducing the number of blocks in which valid data and invalid data coexist, to increase the number of free blocks. In this context, a free block refers to a block that does not contain valid data.

[0060] In this context, valid data refers to data stored in a logical region associated with a certain logical region identifier. For example, data stored in a physical storage location that can be referenced / addressed by the L2P table 37 (i.e., data associated with a logical region identifier as the latest data) is valid data. Valid data is data that can be read from the host 2 later.

[0061] In this context, invalid data refers to data currently stored in a physical storage location that does not have a corresponding logical address association in the L2P table 37. For example, data stored in a physical storage location that cannot be referenced by the L2P table 37 (i.e., data not associated with any logical region identifier as the latest data) is invalid data. Invalid data is data that is no longer possible to read from the host 2. When updated data is stored in a logical region associated with a certain logical region identifier, any valid data previously stored in the associated logical region becomes invalid data, and the updated data becomes new valid data stored in association with the logical region identifier. In addition, if a de-mapping action (to be described further later) is performed for a logical region associated with a certain logical region identifier, valid data previously stored in the logical region subsequently becomes invalid data.

[0062] In garbage collection, the controller 4 copies valid data of several blocks in which valid data and invalid data coexist, together with the valid data, to other blocks (e.g., free blocks). The controller 4 updates the L2P table 37 to map the copy destination physical address to each logical region identifier of the copied valid data. After copying the valid data to another block, the block containing only invalid data is released (designated) as a free block. Thereby, after the data erasing action, the block can be reused to write data.

[0063] In addition to the NAND interface (I / F) 13 described above, the controller 4 includes a host interface (I / F) 11, a CPU 12, a DRAM interface (I / F) 14, a direct memory access controller (DMAC) 15, a static RAM (SRAM) 16, and an ECC encoding / decoding section 17. The host I / F 11, the CPU 12, the NAND I / F 13, the DRAM I / F 14, the DMAC 15, the SRAM 16, and the ECC encoding / decoding section 17 are interconnected by a bus 10.

[0064] The host I / F 11 is a host interface circuit configured to perform communication with the host 2. The host I / F 11 can be, for example, a SATA interface controller, a SAS interface controller, a PCIe controller, or an Ethernet controller.

[0065] The host I / F 11 receives various commands from the host 2. The SATA interface uses an ATA command defined by the ATA standard, the SAS interface uses an SCSI command defined by the SCSI standard, and the PCIe interface and the Ethernet interface use an NVMe command defined by the NVM Express (NVMe) standard. These commands include a write command, a read command, and an unmap command.

[0066] The write command is a command (also referred to as a "write request") that requests the SSD 3 to write user data (user data to be written, also referred to as "write data") to a region of the NAND-type flash memory 5 mapped to a region represented by a logical region identifier. When a combination of a logical address (particularly, an LBA) and a namespace identifier is used as the logical region identifier, the write command can include, for example, a namespace identifier that identifies a certain namespace, a logical address (start LBA) in the namespace, a size of write data (e.g., a number of sectors to be written), and a data pointer (e.g., a buffer address or the like) that represents a location in the memory of the host 2 where the write data is stored. The start LBA represents an LBA of a first sector in one or more sectors in the logical region where the write data should be written.

[0067] The read command is a command (also referred to as a "read request") that requests the SSD 3 to read data from a region of the NAND-type flash memory 5 mapped to a region represented by a logical region identifier specified by the read command. When a combination of a logical address (particularly, an LBA) and a namespace identifier is used as the logical region identifier, the read command can include a namespace identifier that identifies a certain namespace, a logical address (start LBA) in the namespace, a size of data to be read (a number of sectors), and a data pointer (a buffer address) that represents a location in the memory of the host 2 where the data should be transferred. The start LBA represents an LBA of a first sector in one or more sectors in the logical region where the data to be read is stored.

[0068] The unmap command notifies the SSD 3 of a logical region to be unmap as a logical region identifier. The unmap command is a command that deletes information representing a physical region of the NAND-type flash memory 5 corresponding to the logical region from the L2P table 37, and invalidates data recorded in the physical region. When a combination of a logical address (particularly, an LBA) and a namespace identifier is used as the logical region identifier, the controller 4 stores a NULL value in entries of the L2P table 37 corresponding to all logical address ranges (LBA ranges) specified by the unmap command, or deletes a physical address from each of the entries. This unmap action invalidates data associated with each LBA in the LBA range.

[0069] ​The command receivable from the host 2 can be a command requesting secure erasure of specific secure-erasure-object data stored in a specific logical area. Such a command can be referred to as a specific secure-erasure command, an object-secure-erasure command, or more simply as an object-erasure command. The specific logical area is an area logically identified by a logical area identifier specified by the host 2.

[0070] The secure-erasure object data includes data currently stored in the specific logical area and data previously stored in the specific logical area. The data currently stored in the specific logical area refers to valid data currently stored in the specific logical area. The data previously stored in the specific logical area refers to invalid data that has been invalidated, for example, by writing update data to the specific logical area. In the SSD 3, since update data is written to another physical storage location instead of a physical storage location for storing old data, data can be updated while old data is retained as invalid data in the old physical storage location. The secure-erasure object data also includes such invalid data.

[0071] In the following description, the specific logical area to be securely erased can be referred to as a secure-erasure-object logical area, and data currently stored in the secure-erasure-object logical area and / or previously stored in the secure-erasure-object logical area can be referred to as secure-erasure-object data. The secure-erasure-object logical area is logically identified by a logical area identifier.

[0072] For example, the specific secure-erasure command is a command that specifies a logical area identifier for identifying the secure-erasure-object logical area and also requests secure erasure of the secure-erasure-object data.

[0073] Alternatively, the specific secure-erasure command can be a command that requests secure erasure of the secure-erasure-object data without specifying a logical area identifier for identifying the secure-erasure-object logical area. In this case, the host 2 first sends one or more commands to the SSD 3, the one or more commands specifying a logical area identifier for identifying the secure-erasure-object logical area. Then, the host 2 sends the specific secure-erasure command to the SSD 3, the specific secure-erasure command requesting secure erasure of the secure-erasure-object data.

[0074] When the logical area identifier identifying the secure-erasure-object logical area is a namespace identifier, the secure-erasure-object logical area is a namespace identified by the namespace identifier. In this case, the secure-erasure-object data is data currently stored in and / or stored in the namespace identified by the namespace identifier.

[0075] That is, in a case where the controller 4 is configured to manage a plurality of namespaces respectively identified by a plurality of namespace identifiers, these namespace identifiers can be used as the logical area identifier that identifies the secure-erase-object namespace.

[0076] When the logical area identifier that identifies the secure-erase-object logical area is a logical address such as an LBA, the secure-erase-object logical area is a sector identified by the logical address, and the secure-erase-object data is data currently stored in the sector identified by the logical address and / or data that has been stored in the sector identified by the logical address. When there are a plurality of namespaces, a combination of a namespace identifier and a logical address can be used as the logical area identifier that identifies the secure-erase-object logical area.

[0077] A specific secure-erase command can specify one or more logical addresses that are used to identify one or more secure-erase-object sectors. In this case, the specific secure-erase command can specify a logical address range (e.g., an LBA range specified by a logical address and a number of sectors from the logical address, where the logical address represents the beginning of a logical area). When it is desired to set a plurality of logical address ranges as secure-erase objects, the host 2 can first send a plurality of commands to the SSD 3 that respectively specify secure-erase-object logical address ranges, and then can send a specific secure-erase command to the SSD 3 that requests secure erasure of the secure-erase-object data previously identified. The specific secure-erase command can also include a plurality of parameters that specify a plurality of logical address ranges to be objects. In addition, in this case, if there are a plurality of namespaces, a combination of a namespace identifier and a logical address range can be a single logical area identifier that identifies the secure-erase-object logical area.

[0078] When the controller 4 supports key-value storage, a key of the key-value storage can be used as the logical area identifier that identifies the secure-erase-object logical area. In this case, the secure-erase-object logical area is a logical area in which a value identified by the key is stored, and the secure-erase-object data is data currently stored in the logical area identified by the key and / or data that has been stored in the logical area identified by the key. A specific secure-erase command can specify one or more keys that are used to identify one or more secure-erase-object values.

[0079] In the first embodiment, a combination of a namespace identifier and a logical address (LBA) is used as the logical area identifier specified by an I / O command such as a write command or a read command. The combination of a namespace identifier and a logical address (LBA) specified by the I / O command indicates an access target logical area. When the controller 4 supports key-value storage, a key of the key-value storage or a combination of a namespace identifier and a key indicates an access target logical area.

[0080] Figure 3 is a diagram showing a plurality of namespaces managed in the SSD 3.

[0081] Figure 3 A case where the controller 4 manages a namespace NS#1 (NS#1), a namespace NS#2 (NS#2), and a namespace NS#3 (NS#3) is shown. Each namespace is identified by a namespace identifier (NSID). Each namespace contains a group of a plurality of continuous logical addresses (LBAs). The logical address range corresponding to each namespace starts from LBA0. Each namespace can be set to any size. The size of each namespace corresponds to the number of LBAs contained in each namespace.

[0082] Figure 3 A case where the namespace NS#1 includes a plurality of continuous LBAs from LBA0 to LBA(i-1), the namespace NS#2 includes a plurality of continuous LBAs from LBA0 to LBA(j-1), and the namespace NS#3 includes a plurality of continuous LBAs from LBA0 to LBA(k-1) is shown.

[0083] When the namespace NS#1, the namespace NS#2, and the namespace NS#3 are managed by the controller 4, a base address can be defined for each namespace so that the namespace NS#1, the namespace NS#2, and the namespace NS#3 are mapped to a single internal logical address space of the SSD 3 by using a single L2P table 37. Alternatively, an L2P table 37 can be created for each namespace.

[0084] Referring back to the description of Figure 1 , the CPU 12 is a processor configured to control the host I / F 11, the NAND I / F 13, the DRAM I / F 14, the DMAC 15, the SRAM 16, and the ECC encoding / decoding section 17. The CPU 12 performs various processing by loading a control program (firmware) onto the SRAM 16 from the NAND-type flash memory 5 or a ROM (not shown) and executing the firmware in response to the power-on of the SSD 3. The firmware can be loaded onto the DRAM 6. For example, the CPU 12 can perform command processing for processing various commands from the host 2. The action of the CPU 12 is controlled by the firmware mentioned above. Part or all of the command processing can be performed by a dedicated hardware in the controller 4.

[0085] The firmware causes the CPU 12 to function as a namespace management section 21, a write control section 22, a read control section 23, and an erase control section 24.

[0086] For example, the namespace management unit 21 performs creation, management, and deletion of namespaces based on a namespace management command received from the host 2.

[0087] The write control unit 22 processes a write command received from the host 2 via the host I / F 11. For example, the write command specifies a namespace identifier (NSID), a start LBA, and a size of write data. The write control unit 22 writes the write data associated with the write command received from the host 2 via the host I / F 11 to the NAND-type flash memory 5 via the NAND I / F 13. Then, the write control unit 22 updates the L2P table 37 so that each LBA corresponding to the write data is associated with a physical address to which the write data is written.

[0088] The read control unit 23 processes a read command received from the host 2 via the host I / F 11. For example, the read command specifies a namespace identifier (NSID), a start LBA, and a size of data to be read. The read control unit 23 acquires a physical address in which the data to be read is stored by referring to the L2P table 37. Then, the read control unit 23 reads out the data to be read from the NAND-type flash memory 5 via the NAND I / F 13.

[0089] In response to a specific secure erase command received from the host 2 via the host I / F 11, the erase control unit 24 performs secure erasure of secure erase object data stored in a secure erase object logical area identified by a logical area identifier by a physical secure erasure method. The erase control unit 24 can include a demapping unit 24a, a garbage collection (GC) unit 24b, and a secure erase unit 24c.

[0090] The demapping unit 24a performs a demapping action of invalidating the secure erase object data. For example, the demapping unit 24a demaps logical area identifiers that identify all logical areas in the secure erase object logical area.

[0091] The GC unit 24b selects each block in which valid data of the secure erase object data and data other than the secure erase object data is stored as a GC object block (a copy source block). The secure erase object data can be valid data and / or invalid data in the secure erase object logical area. The valid data of the data other than the secure erase object data is valid data stored in a logical area other than the secure erase object logical area. The GC unit 24b performs a copy action of copying only the valid data of the data other than the secure erase object data from the copy source block to a copy destination block. By the demapping action and the copy action, the copy source block becomes a block in which no valid data is stored.

[0092] After the copy action is performed, the secure erasing section 24c performs a data erasing action on at least the block storing the secure erasing object data including the copy source block, thereby securely erasing the secure erasing object data by the physical secure erasing method.

[0093] The other components in the controller 4 will be described below.

[0094] The NAND I / F 13 is a NAND controller configured to control the NAND type flash memory 5 under the control of the CPU 12.

[0095] The DRAM I / F 14 is a DRAM controller configured to control the DRAM 6 under the control of the CPU 12.

[0096] A part of the storage area of the DRAM 6 can be used as a write buffer 31, a read buffer 32, and a command buffer 33. Further, a part of the storage area of the DRAM 6 can be used as a region storing an L2P table 37, a secure erasing object block list 34, a free block list 35, and an active block list 36.

[0097] The write buffer 31 temporarily stores data to be written to the NAND type flash memory 5.

[0098] The read buffer 32 temporarily stores data read from the NAND type flash memory 5.

[0099] The command buffer 33 temporarily stores a command received from the host 2 until the command is executed.

[0100] The secure erasing object block list 34 stores a block identifier of each block in which secure erasing object data is stored.

[0101] The free block list 35 stores a block identifier of each free block. The free block is a block in which no valid data is stored.

[0102] The active block list 36 stores a block identifier of each active block. The active block is a block storing valid data.

[0103] Next, an action of securely and reliably erasing data by a physical secure erasing method (hereinafter referred to as a physical secure erasing action) will be described.

[0104] Figure 4 An overview of a write action and a physical secure erasing action performed in the SSD 3 is shown. Before describing the physical secure erasing action, the write action will be described first.

[0105] The write control section 22 writes the write data to the write buffer 31. When a write-destination block 56 is not allocated, the write control section 22 selects an idle block from the idle blocks managed by the idle block list 35, and performs block erasure on the selected idle block to allocate the block-erased idle block as the write-destination block 56.

[0106] The write control section 22 writes the write data of the write buffer 31 to the writable page of the write-destination block 56. The write control section 22 updates the L2P table 37. When the write data is written to the write-destination block 56, the write-destination block 56 becomes a block in which data is partially written (hereinafter, also referred to as a block in the middle of writing). Since the block in the middle of writing also stores valid data, the block is managed as an active block.

[0107] When there is no writable page in the write-destination block 56 due to the write-destination block 56 being full of data written, the write control section 22 allocates a new idle block as the write-destination block, and writes the write data of the write buffer 31 to the writable page of the newly allocated write-destination block.

[0108] Next, the demapping action and the garbage collection action performed in the physical secure erasure action will be described.

[0109] When a specific secure erasure command indicating secure erasure of data in the logical area designated by the logical area identifier is received from the host 2, the demapping section 24a demaps the logical area identifiers identifying all the logical areas designated by the specific secure erasure command. In other words, the demapping section 24a performs a demapping action of invalidating the secure erasure target data. Thereby, all the secure erasure target data becomes invalid data. The active block having no valid data is deleted from the active block list 36, and the block is instead managed by the idle block list 35.

[0110] Then, the GC section 24b performs a garbage collection action. In the garbage collection action, the GC section 24b copies only the valid data in the data other than the secure erasure target data from one or more first blocks in which the secure erasure target data is stored to one or more copy-destination blocks. The data other than the secure erasure target data is data that is not designated as the secure erasure target data.

[0111] Thereby, the active block group does not include a block in which the secure erasure target data and the valid data in the data other than the secure erasure target data coexist. Since the one or more first blocks (copy-source blocks) do not include the valid data in the data other than the secure erasure target data, each of the one or more first blocks can be treated as an idle block. Therefore, the one or more first blocks are removed from the active block list 36, and the one or more first blocks are instead managed by the idle block list 35.

[0112] Next, a detailed example of the garbage collection action performed by the GC section 24b will be described. The secure erase object data is, for example, any one of: (i) data (user data) of a secure erase object namespace identified by a namespace identifier when a specific secure erase command specifies only the namespace identifier; (ii) data in a logical region identified by a combination of a namespace identifier and an LBA range when a specific secure erase command specifies the combination; and (iii) a value identified by a key of a key-value store when a specific secure erase command specifies the key.

[0113] The GC section 24b selects an active block storing the secure erase object data as a copy source block 52.

[0114] The GC section 24b selects a single free block from the free blocks managed by the free block list 35. The GC section 24b performs block erasure on the selected free block. Then, the GC section 24b allocates the free block after the block erasure as a copy destination block 54.

[0115] The GC section 24b copies valid data, i.e., non-secure erase object valid data, other than the secure erase object data, from the copy source block 52 to the copy destination block 54. The GC section 24b updates the L2P table 37 to establish a correspondence between a physical address indicating a physical storage location of the copy destination in which valid data is copied and a logical region identifier of the valid data that is copied. The secure erase object data in the copy source block 52 remains in the unmapped state. The copy destination block 54 in which valid data is copied becomes an active block and is managed by the active block list 36.

[0116] When the copying of all valid data in the copy source block 52 is completed, the copy source block 52 becomes a free block and is managed by the free block list 35.

[0117] The GC section 24b selects another active block storing the secure erase object data as a new copy source block 52. The GC section 24b copies non-secure erase object valid data from the new copy source block 52 to the copy destination block 54. The GC section 24b updates the L2P table 37 to establish a correspondence between a physical address indicating a physical storage location of the copy destination in which valid data is copied and a logical region identifier of the valid data that is copied. The secure erase object data in the copy source block 52 remains in the unmapped state.

[0118] When the data of the copy-destination block 54 has become full (i.e., when there is no writable page in the copy-destination block 54), the GC section 24b selects a single free block from the free blocks managed by the free block list 35. The GC section 24b performs block erasure on the selected free block. Then, the GC section 24b allocates the free block after the block erasure as a new copy-destination block 54.

[0119] Since the copy-source block whose copy of valid data has been completed is managed as a free block by the free block list 35, such a copy-source block can be reused as a copy-destination block 54. The GC section 24b can select a copy-source block that has become a free block by the copy action as a copy-destination block. In this case, the GC section 24b performs block erasure on the selected block. Thereby, the secure-erasure-object data in the copy-source block that has become a free block by the copy action is erased. The GC section 24b allocates the block after the block erasure as a new copy-destination block 54. Then, the GC section 24b copies the non-secure-erasure-object valid data from the copy-source block 52 to the copy-destination block 54. By reusing the copy-source block that has become a free block as the copy-destination block 54 in this way, the secure-erasure-object data of the copy-source block is deleted by the block erasure and is overwritten by the non-secure-erasure-object valid data.

[0120] In this way, the GC section 24b performs block erasure on at least the copy-source block that has become a free block in which no valid data is stored, by the copy action.

[0121] When the garbage collection action is completed on all the active blocks storing the secure-erasure-object data, there is no secure-erasure-object data in any block other than the free blocks.

[0122] Next, an example of the above-described block erasure action performed in the physical secure erasure action will be described.

[0123] After the garbage collection action is performed, the secure-erasure section 24c performs block erasure on at least one or more first free blocks storing the secure-erasure-object data among the free blocks managed by the free block list 35.

[0124] Here, the one or more first free blocks include: (i) one or more blocks that are not used as copy-destination blocks among one or more copy-source blocks that have become free blocks in which no valid data is stored by the copy action; and (ii) one or more free blocks that are not used as copy-destination blocks among the free blocks that existed before the start of the garbage collection action and stored invalid data in the secure-erasure-object logical area. In (ii), the invalid data in the secure-erasure-object logical area includes data that has been invalidated before the start of the physical secure erasure action among the data in the secure-erasure-object logical area.

[0125] The secure erasing section 24c performs processing for finding the free block corresponding to (i) and the free block corresponding to (ii) from the free blocks managed by the free block list 35, and performs block erasing on at least each of the found free blocks. Alternatively, the secure erasing section 24c can perform block erasing on at least each of all the free blocks managed by the free block list 35.

[0126] As a result, by at least the block erasing, the secure erasing object data stored in each of the blocks left as free blocks after the garbage collection action is securely erased. Further, the secure erasing object data stored in the several blocks reused as the copy destination blocks is securely erased by the overwrite (i.e., block erasing + overwrite).

[0127] After performing the garbage collection action, the secure erasing section 24c can perform block erasing on each of the free blocks storing the secure erasing object data, and can further write a specific data pattern such as all zeros, all ones, or a combination thereof on each of the free blocks. Thus, all the secure erasing object data is securely erased by the block erasing and the rewriting based on the specific data pattern.

[0128] Hereinafter, it is assumed that the first specific command requesting secure erasing of data of a specific namespace is a specific secure erasing command. In this example, the first specific command uses a namespace identifier identifying the specific namespace as a logical area identifier representing a secure erasing object logical area.

[0129] Figure 5 is a flowchart showing a procedure of a physical secure erasing action performed in the memory system according to the first embodiment.

[0130] When the controller 4 receives a command from the host 2 (step S102), the CPU 12 judges whether the received command is the first specific command (step S104).

[0131] When it is determined that the received command is not the first specific command (NO in step S104), the CPU 12 performs processing according to the received command (step S106).

[0132] When it is determined that the received command is the first specific command (YES in step S104), the demapping section 24a performs a demapping action invalidating all the data of the secure erasing object namespace (step S112).

[0133] In step S112, the demapping section 24a deletes the physical addresses from each entry of the L2P table 37 corresponding to all LBAs of the secure-erasure-object namespace, for example. The demapping section 24a also stores a NULL value in these entries. By this demapping action, all clusters of the L2P table 37 corresponding to the secure-erasure-object namespace become an invalid state. That is, the data associated with all clusters corresponding to the secure-erasure-object namespace is internally recognized as discardable data. As a result, all data in the secure-erasure-object namespace becomes invalid data.

[0134] When all data stored in a certain active block is secure-erasure-object data, at the end of the demapping action, the active block becomes a free block storing only invalid data.

[0135] When a certain active block stores both secure-erasure-object data and valid data of a non-secure-erasure-object namespace, at the end of the demapping action, the active block stores invalid data among the secure-erasure-object data and valid data of the non-secure-erasure-object namespace.

[0136] The GC section 24b performs a garbage collection action (GC action) so that a block in which secure-erasure-object data (invalid data) and valid data of a non-secure-erasure-object namespace coexist disappears from the active block group (step S114).

[0137] The GC section 24b selects at least all active blocks storing invalid data of the secure-erasure-object namespace as GC-object blocks (i.e., copy-source blocks). Alternatively, when simply performing a garbage collection action, the GC section 24b can select at least all active blocks storing invalid data as copy-source blocks, regardless of whether the invalid data is invalid data of the secure-erasure-object namespace.

[0138] The GC section 24b can save the block identifier of each active block selected as a copy-source block in the secure-erasure-object block list 34.

[0139] The GC section 24b can check which namespace data a block stores based on information shown in, for example, Figure 6A and 6B

[0140] Figure 6A and 6B An example of a data structure written to a block is shown. In the example of Figure 6A a pair of a namespace identifier and an LBA and data identified by the pair is written on each page. Therefore, the GC section 24b can determine whether a block containing the page stores data of the secure-erasure-object namespace by reading the pair of a namespace identifier and an LBA on each page.​

[0141] In another example of writing to the data structure of a block, as shown in Figure 6B , in addition to the information in Figure 6A , a list of namespace identifiers of the namespaces containing the data in the block is written to any page (e.g., the last page). Thus, the GC section 24b can determine whether the block stores data of the secure-erasure-object namespace by reading only the list of namespace identifiers stored in the last page of each block, without reading all the pages of each block.

[0142] Referring back to the description of step S114 of Figure 5 , the GC section 24b selects an arbitrary one of the free blocks from the free blocks. The GC section 24b performs block erasure on the selected free block. The GC section 24b allocates the free block after the block erasure as the copy-destination block 54.

[0143] The GC section 24b copies, from the copy-source block 52 to the copy-destination block 54, valid data among the data other than the secure-erasure-object data, i.e., valid data of the non-secure-erasure-object namespaces. The GC section 24b updates the L2P table 37 to map each LBA of the valid data of the non-secure-erasure-object namespaces to each copy-destination physical address.

[0144] When the valid data of the non-secure-erasure-object namespaces is copied, the valid data of the non-secure-erasure-object namespaces of the copy-source block 52 becomes invalid data. Since the mapping of all the LBAs of the secure-erasure-object namespaces is not released before the copying, all the data of the copy-source block 52 is invalid data after the copying. Thus, when all the valid data of the non-secure-erasure-object namespaces stored in the copy-source block 52 is copied to the copy-destination block, the copy-source block 52 becomes a free block. Thus, when all the valid data of the non-secure-erasure-object namespaces of all the copy-source blocks is copied to several copy-destination blocks, there is no secure-erasure-object data other than the free blocks. In other words, there is only invalid data of the secure-erasure-object namespaces in the free blocks.

[0145] The GC section 24b determines whether an end condition of the garbage collection is satisfied (step S122). When all the valid data of the non-secure-erasure-object namespaces is completely copied from the blocks in which the data of the secure-erasure-object namespaces and the valid data of the non-secure-erasure-object namespaces coexist, the secure-erasure-object data (invalid data of the secure-erasure-object namespaces) disappears from the active blocks. That is, there is only invalid data of the secure-erasure-object namespaces in the free blocks. Thus, the end condition can be that there is no longer a block in the active block group that stores invalid data of the secure-erasure-object namespaces.

[0146] The GC section 24b continues the GC operation until the blocks storing the invalid data of the secure-erasure-target namespace disappear from the active block group (step S114, and "No" in step S122).

[0147] When the end condition of the garbage collection operation is satisfied (Yes in step S122), the GC section 24b ends the GC operation. At this time, it is not possible for the invalid data of the secure-erasure-target namespace to exist outside the free blocks.

[0148] The secure-erasure section 24c performs at least a block erasure operation on each free block in which the invalid data of the secure-erasure-target namespace is stored (step S124). The copy-source blocks that are reused as copy-destination blocks have already undergone block erasure by the garbage collection operation of step S114. Thus, by combining the block erasure operation on each copy-source block performed in step S114 with the block erasure operation of step S124, all the data of the secure-erasure-target namespace is securely erased by block erasure.

[0149] In step S124, the secure-erasure section 24c can perform block erasure on each free block in which the invalid data of the secure-erasure-target namespace is stored, and can further write a specific data pattern into each of these free blocks. As a result, the invalid data of the secure-erasure-target namespace stored in each free block will be overwritten with the specific data pattern. The invalid data of the secure-erasure-target namespace stored in the copy-source blocks that are reused as copy-destination blocks have already been overwritten with valid data of other namespaces by the garbage collection operation in step S114. Thus, by combining the overwriting in step S114 with the overwriting in step S124, all the data of the secure-erasure-target namespace is securely erased by overwriting.

[0150] The secure-erasure section 24c can perform block erasure on all the free blocks. Thus, it is easy to perform the processing of step S124 that performs at least block erasure on each free block in which the invalid data of the secure-erasure-target namespace is stored.

[0151] Alternatively, in order to reduce the number of blocks on which block erasure is performed, the secure-erasure section 24c can perform processing for determining one or more free blocks in which the invalid data of the secure-erasure-target namespace is stored, and perform block erasure only on the determined one or more free blocks.

[0152] In either the former or the latter case, at least the one or more free blocks in which the invalid data of the secure-erasure-target namespace is stored are the target of the physical secure erasure operation.

[0153] In the latter case, and when the active block storing the invalid data of the secure erase target namespace in step S114 is a GC object block, the secure erasing section 24c can classify the free blocks existing at the start of step S124 into: a group I of free blocks generated by the GC action of step S114 and a group II of other free blocks. The secure erasing section 24c can easily determine each free block belonging to the group I as a free block storing the invalid data of the secure erase target namespace without checking the content of each free block. The secure erasing section 24c can judge whether each free block belonging to the group II is a free block in which the invalid data of the secure erase target namespace is stored or not by checking the content of each free block.

[0154] When the processing of step S124 is completed, the erasing control section 24 notifies the host 2 of the completion of the first specific command by sending a response indicating the completion of the first specific command to the host 2 (step S126).

[0155] Next, the processing of the I / O command when the first specific command requesting the secure erasure of the data of a specific namespace is received will be described. Possible examples of the I / O command include a write command, a read command and an unmap command.

[0156] First, the processing of the I / O command that has been received but not completed when the first specific command (specific secure erasure command) is received will be described.

[0157] By the processing of the first specific command, the data of the secure erase target namespace is securely erased. Therefore, in principle, the controller 4 should abort any uncompleted write command to the secure erase target namespace or any uncompleted unmap command to the secure erase target namespace.

[0158] Alternatively, the controller 4 can wait for the processing of the uncompleted write command or unmap command to be completed and can then start executing the first specific command after the processing of these commands is completed. Specifically, in some examples, if the processing of these commands is about to be completed, the controller 4 can start executing the first specific command only after the processing of these commands has been completed without aborting these commands.

[0159] Figure 7 is a flowchart showing the processing procedure of the I / O command received before the first specific command is received and not completed. Before the first specific command is received, a plurality of I / O commands can be received. In this case, the processing procedure can be repeated for each received I / O command.

[0160] The controller 4 receives a first specific command requesting secure erasure of data of a certain namespace from the host 2 (step S702). The controller 4 determines whether there is an I / O command for the certain namespace (a secure erasure object namespace) that is being executed, or whether there is an I / O command for the secure erasure object namespace that has been received but has not yet started to be executed (hereinafter, these I / O commands are also referred to as an uncompleted command) (step S704).

[0161] When it is determined that there is an uncompleted command (YES in step S704), the controller 4 determines whether the uncompleted command is a write command or a demapping command (step S706).

[0162] When it is determined that the uncompleted command is a write command or a demapping command (YES in step S706), the controller 4 determines whether processing of the uncompleted write command or demapping command is about to be completed (step S708).

[0163] When it is determined that the processing of the uncompleted write command or demapping command is not about to be completed (NO in step S708), the controller 4 aborts the uncompleted write command or demapping command (step S712). When execution of commands received from the host 2 out of order is not allowed in step S712, for example, when a write command is aborted, the controller 4 aborts all subsequent I / O commands received from the host 2 after the write command is received.

[0164] After the uncompleted command is aborted, the controller 4 starts to execute the first specific command (step S714).

[0165] When it is determined that the processing of the uncompleted write command or demapping command is about to be completed (YES in step S708), the controller 4 can not abort the uncompleted write command or demapping command, and can wait for the processing of the uncompleted write command or demapping command to be completed (step S710). Then, in response to the processing of the uncompleted write command or demapping command being completed (YES in step S710), the controller 4 starts to execute the first specific command (step S714).

[0166] When it is determined that the uncompleted command for the secure erasure object namespace is neither a write command nor a demapping command, that is, when there is an uncompleted read command for the secure erasure object namespace (NO in step S706), the controller 4 does not abort the uncompleted read command, but waits for the processing of the uncompleted read command to be completed (step S710). Then, in response to the processing of the uncompleted read command being completed, the controller 4 starts to execute the first specific command (step S714).

[0167] Next, a case in which the controller 4 receives a second specific command requesting secure erasure of data of a certain namespace from the host 2 will be described with reference to FIG. 8. Figure 8The processing of the I / O command received during the execution of the first specific command is described. Figure 8 is a flowchart showing the processing procedure of the I / O command received during the execution of the first specific command. A plurality of I / O commands can be received during the execution of the first specific command. In this case, the processing procedure can be repeated for each received I / O command.

[0168] The controller 4 receives a first specific command requesting secure erasure of data of a specific namespace (step S802), and starts the execution of the first specific command (step S804). When an I / O command is received during the execution of the first specific command (step S806), the controller 4 determines whether the received I / O command is an I / O command for the specific namespace (a secure erasure target namespace) (step S808).

[0169] When it is determined that the I / O command received during the execution of the first specific command is an I / O command for the secure erasure target namespace (YES in step S808), the controller 4 suspends the received I / O command (step S810). Alternatively, in step S810, the controller 4 can suspend the execution of the received I / O command until the processing of the first specific command is completed (i.e., until the completion of the first specific command is notified to the host 2), and then can execute the received I / O command after the processing of the first specific command is completed.

[0170] When it is determined that the I / O command received during the execution of the first specific command is an I / O command for another namespace other than the secure erasure target namespace (NO in step S808), the controller 4 can selectively use the following first method or second method. Therefore, the controller 4 determines whether the first method or the second method is selected in advance (step S812). When it is determined that the first method is selected in advance, the controller 4 executes the processing of step S814. When it is determined that the second method is selected in advance, the controller 4 executes the processing of step S816.

[0171] The first method (step S814): When the I / O command for the other namespace is a write command, the controller 4 suspends the execution of the write command until at least the GC operation is completed, and then executes the write command after the completion of the GC operation.

[0172] When the I / O command for the other namespace is a read command, the controller 4 executes the read command as usual. However, when the execution of the commands received from the host 2 is not allowed in an arbitrary order (out of order), the controller 4 executes the read command for the other namespace in the same order as the order in which these read commands are received. Then, when a write command for the individual namespace is received after the read command for the other namespace, the controller 4 suspends the processing of the received write command and all the I / O commands for the other namespace received after the received write command until the GC action is completed. After the completion of the GC action, the controller 4 executes the received write command and all the I / O commands for the other namespace received after the received write command in the same order as the order in which these commands are received.

[0173] In the description of the first method, the controller 4 can process the unmap command in the same manner as the write command or in a different manner. When the controller 4 does not process the unmap command in the same manner as the write command, the controller 4 executes the unmap command as usual in the same manner as the read command.

[0174] The second method (step S816): When the I / O command for the other namespace is a write command, an unmap command, or a read command, the controller 4 executes the I / O command as usual. The effect of this second method is that the processing of the I / O command for the other namespace is not significantly delayed, but the time required to process the first specific command is increased by the amount of time required to process the I / O command. In addition, there is a possibility that the invalid data generated by writing the write data (update data) associated with the write command for the other namespace can also become the object of the GC action. In this case, the time required to process the first specific command is further increased.

[0175] Next, an example of a safe erase action for the data of the individual namespace will be described with reference to Figure 9A , 9B , 10, 11A, and Figure 11B .

[0176] Figure 9A is a diagram showing an example of the contents of each active block before the start of the safe erase action. Figure 9A The case where three blocks including the block BLK0, the block BLK1, and the block BLK2 are active blocks in which valid data is stored is shown.

[0177] The block BLK0 is an active block in the middle of writing, which is allocated as a write-destination block. In the block BLK0, an unwritten storage area is left as shown by a blank. Each of the blocks BLK1 and BLK2 is a write-completed active block in which data has been written to the end of the block.

[0178] When there are three namespaces including namespace A, namespace B, and namespace C in the SSD 3, data of namespace A, data of namespace B, and data of namespace C can coexist in each of the blocks BLKO, BLK1, and BLK2. Further, valid data and invalid data of each namespace can coexist in each of the blocks BLKO, BLK1, and BLK2. The invalid data is data that is invalidated by writing new write data (update data) associated with the LBA of the invalid data or by a de-map command from the host 2, for example.

[0179] Figure 9B is a diagram illustrating an example of the content of each free block before starting the secure erase action. Figure 9B A case in which four blocks including the block BLK3, the block BLK4, the block BLK5, and the block BLK6 are free blocks in which valid data is not stored is illustrated.

[0180] In Figure 9B , in the free block BLK3, invalid data of namespace A and invalid data of namespace C are stored, but invalid data of namespace B is not stored. In each of the free blocks BLK4 to BLK6, invalid data of namespace A, invalid data of namespace B, and invalid data of namespace C are stored.

[0181] Suppose a case in which, under the three active blocks illustrated in Figure 9A and the four free blocks illustrated in Figure 9B , the SSD 3 receives a first specific command requesting secure erasure of data of namespace B from the host 2.

[0182] First, the de-map section 24a performs a de-map action that invalidates data corresponding to all LBAs belonging to namespace B respectively.

[0183] Figure 10 is a diagram illustrating an example of the content of each active block after the de-map action is performed. In Figure 10 , the bold letters indicate data of namespace B that newly becomes invalid data due to the de-map.

[0184] Before the de-map action is performed, as illustrated in Figure 9A , the block BLKO stores one invalid data of namespace B and two valid data of namespace B. As illustrated in Figure 10 , due to the de-map action, all of the two valid data of namespace B of the block BLKO become invalid data.

[0185] Before the de-map action is performed, as illustrated in Figure 9AAs shown in (A) of FIG. 10, the block BLK1 stores two invalid data of the namespace B and four valid data of the namespace B. As shown in (B) of FIG. 10, the block BLK2 stores three invalid data of the namespace B and four valid data of the namespace B. As shown in (C) of FIG. 10, the block BLK3 stores four invalid data of the namespace B and four valid data of the namespace B. Figure 10 As shown in (A) of FIG. 11, all of the four valid data of the namespace B of the block BLK1 become invalid data due to the demapping action.

[0186] As shown in (A) of FIG. 10, the block BLK1 stores two invalid data of the namespace B and four valid data of the namespace B. As shown in (B) of FIG. 10, the block BLK2 stores three invalid data of the namespace B and four valid data of the namespace B. As shown in (C) of FIG. 10, the block BLK3 stores four invalid data of the namespace B and four valid data of the namespace B. Figure 9A Figure 10 As shown in (A) of FIG. 11, all of the four valid data of the namespace B of the block BLK1 become invalid data due to the demapping action.

[0187] After the demapping action is performed, the GC unit 24b selects all the active blocks storing invalid data of the namespace B as the GC object blocks (i.e., the copy source blocks), and performs the GC action.

[0188] In (A) of FIG. 12, each of the blocks BLK0, BLK1, and BLK2 that are the active blocks stores invalid data of the namespace B. Therefore, all the three active blocks including the blocks BLK0, BLK1, and BLK2 are selected as the copy source blocks. Figure 10

[0189] Figure 11A is a diagram showing an example of the contents of each active block after the GC action is performed. In (A) of FIG. 13, the symbols (A), (B), and (C) in each physical storage location indicate that the namespaces corresponding to the data previously stored in these physical storage locations are the namespace A, the namespace B, and the namespace C, respectively. Figure 11A

[0190] The blocks BLK6 and BLK5, which are the idle blocks before the GC action, are used as the copy destination blocks by the GC action, and become active blocks due to the copying of valid data. Figure 11A The block BLK6 becomes an active block by copying valid data from each of the blocks BLK1 and BLK2 to the block BLK6. As a result of this copying, all the valid data stored in each of the namespace A and the namespace C in the block BLK1 and all the valid data stored in each of the namespace A and the namespace C in the block BLK2 are stored in the BLK6.

[0191] The block BLK5 becomes an active block by copying valid data from the block BLK0 to the block BLK5. By this copying, all the valid data stored in each of the namespace A and the namespace C in the block BLK0 is stored in the block BLK5.

[0192]

[0193] ​​​Hereinafter, the GC action of changing the state of each of the blocks BLK6 and BLK5 from the free block shown in Figure 9B to the active block shown in Figure 11A will be described. The GC section 24b performs block erasure on the block BLK6. Then, the GC section 24b copies valid data of the other namespaces than the namespace B from the block BLK1 to the block BLK6. At this time, the GC section 24b copies the valid data of the other namespaces than the namespace B so as to be continuously arranged at a plurality of physical storage locations in the block BLK6.

[0194] Further, the GC section 24b copies valid data of the other namespaces than the namespace B from the block BLK2 to the block BLK6. At this time, the GC section 24b copies the valid data of the other namespaces than the namespace B so as to be continuously arranged at a plurality of subsequent physical storage locations in the block BLK6.

[0195] Thus, the block BLK6 is filled with the valid data of the other namespaces than the namespace B stored in the block BLK1 and the valid data of the other namespaces than the namespace B stored in the block BLK2. As a result, the invalid data of the namespace B stored in the block BLK6 which was a free block before the GC action is covered by the valid data of the other namespaces than the namespace B.

[0196] In Figure 11A , the bold characters indicate the physical storage locations from which the data of the namespace B is deleted. Referring to Figure 11A , it can be understood by focusing on the bold characters that, for example, the invalid data of the namespace B stored in the block BLK6 which was a free block before the GC action is covered by the valid data of the other namespaces than the namespace B.

[0197] Similarly, the GC section 24b performs block erasure on the block BLK5. Then, the GC section 24b copies valid data of the other namespaces than the namespace B from the block BLK0 to the block BLK5. At this time, the GC section 24b copies the valid data of the other namespaces than the namespace B so as to be continuously arranged at a plurality of physical storage locations in the block BLK5. In this example, no data is written to the end of the data in the block BLK5, but the remaining portion of the block BLK5 is filled with dummy data such as all zeros.

[0198] Referring back to Figure 11A , it can be understood by focusing on the bold characters that the invalid data of the namespace B stored in the block BLK5 is either covered by the valid data of the other namespaces than the namespace B or is block-erased.

[0199] By the above-described GC operation, the blocks BLK0 to BLK2 storing the data (invalid data) of the namespace B become free blocks. Further, the two blocks including the block BLK5 and the block BLK6 newly become active blocks, and store only valid data of other namespaces than the namespace B, and do not store data of the namespace B. Therefore, in the active block group, there is no block in which valid data of the secure-erasure-target namespace and the non-secure-erasure-target namespace coexist.

[0200] Figure 11B FIG. 8 is a diagram illustrating an example of the content of each free block after the execution of the GC operation. After the execution of the GC operation, the free blocks managed by the free block list 35 include the three blocks (BLK0, BLK1, and BLK2) which became free blocks by the GC operation and the two blocks (BLK3 and BLK4) which were free blocks before the start of the GC operation.

[0201] Each of the free block BLK0, the free block BLK1, and the free block BLK2 is a block which became a free block by the GC operation and was not used as a copy-destination block for the GC operation. The free block BLK0, the free block BLK1, and the free block BLK2 store invalid data of the secure-erasure-target namespace B, but do not store valid data of the non-secure-erasure-target namespaces A and C. Therefore, block erasure can be performed on each of the free block BLK0, the free block BLK1, and the free block BLK2.

[0202] By performing block erasure on each of the free block BLK0, the free block BLK1, and the free block BLK2, data of the secure-erasure-target namespace B can be securely erased from each of the free block BLK0, the free block BLK1, and the free block BLK2.

[0203] In the GC operation, any of the free block BLK0, the free block BLK1, and the free block BLK2 can be reused as a copy-destination block for the GC operation. First, block erasure is performed on the block which is reused as the copy-destination block. Then, valid data of the non-secure-erasure-target namespaces copied from the copy-source block is used to overwrite the data of the secure-erasure-target namespace B stored in the block which is reused as the copy-destination block. In this way, by the overwriting performed during the GC operation, the data of the secure-erasure-target namespace B stored in the block which is reused as the copy-destination block is securely erased.

[0204] The free block BLK3 is a block which was a free block before the start of the GC operation and was not used as a copy-destination block for the GC operation.

[0205] The free block BLK3 does not store data of the secure-erasure-target namespace B. Therefore, it is not necessary to perform block erasure on the free block BLK3.

[0206] The free block BLK4 is a block that is a free block before the GC action starts, and is not used as a copy-destination block for the GC action. The free block BLK4 stores invalid data of the secure-erase-object namespace B. Therefore, block erasure is performed on the free block BLK4. As a result, the data of the secure-erase-object namespace B is securely erased from the free block BLK4.

[0207] As described above, according to the first embodiment, in response to receiving a first specific command from the host 2 that requests secure erasure of data of a specific namespace, a demapping action that invalidates data of a secure-erase-object namespace is performed, and a GC action that copies valid data in data of other namespaces than the secure-erase-object namespace from one or more blocks (copy-source blocks) that store data of the secure-erase-object namespace to one or more copy-destination blocks is performed.

[0208] Therefore, since the one or more blocks that store data of the secure-erase-object namespace become free blocks, there is no data of the secure-erase-object namespace outside the free blocks.

[0209] When the copy-source block becomes a free block, the free block can be reused as a copy-destination block. In this case, data of the secure-erase-object namespace stored in the free block can be erased by block erasure, and then the free block can be further overwritten with valid data in data of other namespaces than the secure-erase-object namespace.

[0210] As described above, in the first embodiment, a part of data (valid data and invalid data) of a specified specific namespace can be securely erased by block erasure and overwriting during the GC action. Further, data of the specific namespace stored in one or more free blocks after the GC action can be securely erased at least by block erasure. As a result, all data (valid and invalid data) of the specified specific namespace is securely erased.

[0211] Next, advantages of the secure-erase action according to the first embodiment will be described in comparison with certain comparative examples.

[0212] First, differences between a configuration of an SSD according to certain comparative examples and a configuration of the SSD 3 according to the first embodiment will be described.

[0213] <Comparative Example #1>

[0214] In the SSD according to Comparative Example #1, a plurality of endurance groups are managed so that a plurality of namespaces belong to different endurance groups from each other. An endurance group is a unit of managing physical resources of a NAND-type flash memory. All physical resources of the NAND-type flash memory are divided into a plurality of endurance groups so that each block in the NAND-type flash memory is used by only one endurance group. When performing secure erasure of data of a certain namespace, each block in the endurance group corresponding to the certain namespace becomes a secure erasure target.

[0215] <Comparative Example #2>

[0216] In the SSD according to Comparative Example #2, all physical resources of the NAND-type flash memory belong to only one endurance group, but a correspondence relationship between a plurality of namespaces and a plurality of blocks is managed on a one-to-one basis so that data of different namespaces are written to different blocks. When performing secure erasure of data of a certain namespace, each block mapped one-to-one to the certain namespace becomes a secure erasure target.

[0217] <First Embodiment>

[0218] In the SSD 3 according to the first embodiment, a plurality of namespaces are managed to allow all physical resources of the NAND-type flash memory to belong to only one endurance group while allowing data of a plurality of namespaces to coexist in the same block. This is because the secure erasure action of the first embodiment can perform a physical secure erasure action on data of a certain namespace designated by the host 2 even in an environment where data of different namespaces coexist in the same block.

[0219] (1) Speed of user data erasure

[0220] In the SSD 3 according to the first embodiment, it is necessary to perform a GC action before block erasure. Therefore, the speed of the secure erasure action of user data is relatively slow. However, secure erasure of data of a certain namespace is, for example, a case where data of a namespace storing backup data of an OS is maintained and data of a namespace including user data is erased when a PC is handed over to another person. Since the frequency of use is small, the slow speed of secure erasure is acceptable.

[0221] In Comparative Examples #1 and #2, the speed of the action for performing secure erasure of user data depends on the implementation, but the action can be performed at a relatively high speed.

[0222] (2) Number of blocks in the write-in progress

[0223] Here, a case where the following configuration is assumed: user data from a host is written to a single layer cell (SLC: single level cell) storage area of a NAND type flash memory, and the user data in the SLC storage area is written to a triple layer cell (TLC: triple level cell) storage area or a quad-level cell (QLC: quad-level cell) storage area, for example, when the SSD is idle.

[0224] In the SSD 3 according to the first embodiment, the number of required blocks in the write-in-progress is two. One of the two blocks in the write-in-progress is an SLC block that serves as a write-destination block of the SLC storage area. The other block in the write-in-progress is a TLC / QLC block that serves as a write-destination block of the TLC / QLC storage area.

[0225] In Comparative Example #1 and Comparative Example #2, the number of required SLC blocks is the number of namespaces. The number of required TLC / QLC blocks is the number of namespaces.

[0226] (3) Over-provisioning

[0227] In the SSD 3 according to the first embodiment and Comparative Example #2, the over-provisioning space can be shared by a plurality of namespaces.

[0228] In Comparative Example #1, the over-provisioning space must be prepared separately for each namespace.

[0229] (4) SLC storage area

[0230] In the SSD 3 according to the first embodiment, since the SLC storage area is shared among the namespaces, a certain namespace can temporarily use the entire capacity of the SLC storage area.

[0231] In Comparative Example #1 and Comparative Example #2, an independent SLC storage area must be prepared for each namespace. When the required capacity of a single SLC storage area is fixed regardless of the namespace size, the number of blocks allocated to the TLC / QLC storage area can be reduced. Therefore, since the storage capacity of the non-volatile memory cannot be efficiently used, the drive capacity (total capacity) represented by the sum of the storage capacity of the TLC / QLC storage area and the storage capacity of all the SLC storage areas is reduced in proportion to the number of namespaces.

[0232] (5) Alignment between block size and namespace size

[0233] Generally, the size of a single block is several tens of megabytes (MB), and the size of each namespace is an integer multiple of a sector. This can cause misalignment between the block size and the namespace size.

[0234] In the SSD 3 according to the first embodiment, since a plurality of namespaces can share a plurality of blocks, the SSD 3 is not easily affected by the inconsistency even when an inconsistency occurs between the block size and the namespace size, and its capacity efficiency is not easily reduced.

[0235] In Comparative Example #1 and Comparative Example #2, when an inconsistency occurs between the block size and the namespace size, the SSD is affected by the inconsistency, and the capacity efficiency is reduced.

[0236] (6) Reduction of drive capacity by creating a plurality of namespaces

[0237] For reasons (2) to (5), when a plurality of namespaces are created in a single SSD, the drive capacity (e.g., the available, effective, or usable storage capacity) can be reduced.

[0238] In the SSD 3 according to the first embodiment, since there is only one endurance group, a plurality of namespaces can be efficiently created. Therefore, the drive capacity is not reduced due to the creation of a plurality of namespaces.

[0239] In Comparative Example #1, since an independent endurance group is required for each namespace, the reduction of the drive capacity due to the creation of a plurality of namespaces is large.

[0240] In Comparative Example #2, the degree of the reduction of the drive capacity due to the creation of a plurality of namespaces is between the first embodiment and Comparative Example #1.

[0241] (Second Embodiment)

[0242] Next, the second embodiment will be described. The configuration of the SSD according to the second embodiment is substantially the same as that of the SSD 3 according to the embodiment shown in Figure 1 the first embodiment. The second embodiment is similar to the first embodiment in that a physical secure erase action is performed on data of a specific namespace, but its processing related to the unmap action is different from that of the first embodiment. In the first embodiment, the controller 4 performs the unmap action before the GC action, whereas in the second embodiment, the controller 4 performs the unmap action during the execution of the GC action.

[0243] Figure 12 is a flowchart showing a process of a physical secure erase action performed in the memory system according to the second embodiment. The description of the process that is the same as the process of the physical secure erase action performed in the memory system according to the first embodiment described with reference to Figure 5 will be omitted.

[0244] When the received command is the first specific command (YES in step S104), the GC section 24b performs the GC operation, and the unmap section 24a performs the unmap operation during the execution of the GC operation (step S132).

[0245] In step S132, the GC section 24b selects, as the GC object block (i.e., the copy source block), at least an active block storing data of the secure-erase-object namespace, i.e., the secure-erase-object data, regardless of whether the data of the secure-erase-object namespace is valid data or invalid data. Alternatively, when simply implementing the GC operation, the GC section 24b can select, as the copy source block, all active blocks storing invalid data, regardless of whether the invalid data is data of the secure-erase-object namespace.

[0246] When the valid data stored in the copy source block is the secure-erase-object data, the unmap section 24a performs the unmap operation to invalidate the valid data stored in the copy source block. That is, the unmap section 24a performs the unmap operation to invalidate the valid data that is the secure-erase-object data among the valid data stored in the copy source block. Thereby, the valid data that is part of the secure-erase-object data stored in the copy source block is invalidated. When the valid data of the non-secure-erase-object namespace stored in the copy source block is copied to the copy destination block, and the valid data of the secure-erase-object namespace stored in the copy source block is also unmaped, the copy source block will become a free block. As a result, outside the free block, there is no secure-erase-object data. In other words, the data (invalid data) of the secure-erase-object namespace exists only in some free blocks.

[0247] After the execution of the GC operation and the unmap operation (step S132), as with the first embodiment, the end condition of the GC operation is determined (step S122), the block erase operation is performed (step S124), and the completion of the command is notified to the host 2 (step S126).

[0248] Since the processing of the I / O command when the first specific command requesting the secure erasure of data in a specific namespace is executed is the same as in the first embodiment, the description thereof will be omitted.

[0249] In the second embodiment, the same effects as in the first embodiment can also be obtained.

[0250] (Third Embodiment)

[0251] Next, the third embodiment will be described. The configuration of the SSD according to the third embodiment is the same as that of the first embodiment Figure 1The configuration of the SSD 3 according to the first embodiment shown in FIG. 1 is the same in the third embodiment. In the first and second embodiments, the namespace identifier is used as the logical area identifier representing the secure-erase-object logical area, but in the third embodiment, the logical address identifying the secure-erase-object sector and the number of sectors from the logical address are used as the logical area identifier representing the secure-erase-object logical area. For example, the LBA is used as the logical address. When the memory system has a plurality of namespaces, the logical area identifier representing the secure-erase-object logical area further includes the namespace identifier representing the secure-erase-object namespace.

[0252] In the third embodiment, the secure-erase-object data is data corresponding to one or more specific LBAs, i.e., data currently stored or past stored in one or more secure-erase-object sectors identified by the one or more specific LBAs.

[0253] The second specific command used in the third embodiment is a specific secure-erase command requesting to perform secure-erase on data identified by one or more specific LBAs, specifically data stored in one or more secure-erase-object sectors identified by the one or more specific LBAs. The second specific command can include a parameter specifying the one or more specific LBAs. The one or more specific LBAs can be represented by an LBA range.

[0254] When the host 2 sets a plurality of LBA ranges as secure-erase-objects, the host 2 can first send a plurality of commands respectively specifying the LBA ranges to the SSD 3, and then can send a second specific command requesting to perform secure-erase on the one or more previously specified LBA ranges to the SSD 3. The second specific command can further include a plurality of parameters specifying the plurality of LBA ranges. By specifying the plurality of LBA ranges in this way to request secure-erase, the GC action can be performed only once. Therefore, compared to the case where secure-erase is required for each LBA range respectively, the number of data to be copied and the number of times of performing block erase can be reduced, and the wear of the storage cells can be reduced.

[0255] Further, when the host 2 sets one or more specific LBAs or one or more specific LBA ranges of a specific namespace as secure-erase-objects, the host 2 can specify the namespace identifier identifying the specific namespace and the one or more specific LBAs or the one or more specific LBA ranges.

[0256] Figure 13A is a flowchart showing a process of a physical secure-erase action performed in the memory system according to the third embodiment.

[0257] When the controller 4 receives a command from the host 2 (step S202), the CPU 12 determines whether the received command is a second specific command (step S204). The second specific command requests to perform secure erasure of data of one or more specific LBAs by a physical secure erasure method.

[0258] When it is determined that the received command is not the second specific command (NO in step S204), the CPU 12 performs processing according to the received command (step S206).

[0259] When it is determined that the received command is the second specific command (YES in step S204), the demapping section 24a performs a demapping action (step S212). Next, the GC section 24b performs a GC action (step S214).

[0260] The procedures of the demapping action (step S212) and the GC action (step S214) differ depending on the relationship between the sector size and the cluster size. Figure 13B is a flowchart showing the procedures of the demapping action and the GC action when the sector size is equal to the cluster size. In this case, a single secure-erasure-object sector corresponds to only one cluster. Figure 13C is a flowchart showing the procedures of the demapping action and the GC action when the sector size is smaller than the cluster size. In this case, at least one secure-erasure-object sector can be located in a part of one cluster storing valid data.

[0261] As shown in Figure 13B When the sector size is equal to the cluster size, the demapping section 24a performs a demapping action that invalidates data respectively associated with all the secure-erasure-object LBAs designated by the host 2 (step S212A). The demapping section 24a deletes the physical addresses corresponding to all the LBAs included in the second specific command from each entry of the L2P table 37. Alternatively, the demapping section 24a stores NULL values in these entries. As a result of this demapping action, all the clusters of the L2P table 37 corresponding to the secure-erasure-object LBAs become invalid. As a result, the data corresponding to all the secure-erasure-object LBAs becomes invalid data.

[0262] The GC section 24b selects at least all the active blocks storing the invalid data of the secure-erasure-object LBAs as GC-object blocks (i.e., copy-source blocks). Alternatively, when the GC action is simply implemented, the GC section 24b selects at least all the active blocks storing invalid data as copy-source blocks regardless of whether the invalid data is invalid data associated with the secure-erasure-object LBAs.

[0263] The GC section 24b can save the block identifiers of each of the active blocks selected as copy-source blocks in the secure-erasure-object block list 34.

[0264] The GC unit 24b freely selects any one of the free blocks. The GC unit 24b performs block erasure on the selected free block. The GC unit 24b allocates the free block after the block erasure as a copy destination block.

[0265] The GC unit 24b copies valid data among data other than the secure erase target data, that is, valid data of the non-secure erase target LBAs, from the copy source block to the copy destination block (step S214A).

[0266] The GC section 24b updates the L2P table 37 to map each LBA of the copied valid data to each copy destination physical address.

[0267] refer to Figure 13C Describes the process of demapping and GC actions when the sector size is smaller than the cluster size. Figure 13B The process of describing the demapping action is the same as the process of describing the GC action.

[0268] When the sector size is smaller than the cluster size, bitmap data indicating whether data of each sector in the cluster is valid or invalid is stored in, for example, the L2P table 37, as described above.

[0269] The demapping unit 24 a selects a cluster including at least one secure erase target sector as a target for a demapping operation.

[0270] When all sectors in the cluster are targets for secure erasure, that is, when all data in the cluster are targets for secure erasure ("Yes" in step S212B-1), the demapping unit 24a executes a demapping operation to invalidate the data in the cluster (step S212B-4).

[0271] When all sectors in the cluster are not security erase targets (No in step S212B-1), the demapping unit 24a updates the bitmap data to invalidate all security erase target sectors in the cluster (step S212B-2).

[0272] The demapping section 24a checks whether all sectors in the cluster are invalidated by the invalidation (step S212B-3).

[0273] When it is determined that all sectors in the cluster have become invalid sectors ("Yes" in step S212B-3), the demapping section 24a performs a demapping operation to invalidate the data in the cluster (step S212B-4).

[0274] When determining that all sectors in the cluster are not invalid sectors (No in step S212B- 3 ), the demapping section 24 a ends the processing of the cluster.

[0275] The demapping unit 24a determines whether the demapping operation for all the clusters of the demapping operation target is completed (step S212B-5).

[0276] When it is determined that the demapping operation for all the clusters is not completed (NO in step S212B-5), the demapping unit 24a executes the determination of step 212B-1 for the next cluster.

[0277] When it is determined that the demapping operation for all the clusters is completed (YES in step S212B-5), the GC unit 24b copies all the clusters including the valid data (i.e., the data other than the safe-to-erase object data) in the active block from the copy source block to the copy destination block (step S214B-1).

[0278] In step S214B-1, when there is an invalid sector in a cluster, the GC unit 24b changes the data in the sector to an appropriate value, and then copies the data to the copy destination block. The appropriate value is, for example, all zeros or all 1s, random data, or a combination thereof.

[0279] The GC unit 24b updates the entry of the L2P table 37 to associate the LBA of the copied data with the physical address of the previously copied cluster.

[0280] Referring back to the description of Figure 13A As with the first embodiment, after the GC operation is executed (step S214), the GC unit 24b determines whether the end condition of the GC operation is satisfied (step S222). The end condition can be that there is no longer a block storing invalid data of a safe-to-erase object LBA in the active block group.

[0281] The GC unit 24b continues to execute the GC operation until the blocks storing invalid data of a safe-to-erase object LBA disappear from the active block group (step S214, and NO in step S222).

[0282] When it is determined that the end condition of the garbage collection operation is satisfied (YES in step S222), the GC unit 24b ends the GC operation. At this time, it is impossible that there is invalid data of a safe-to-erase object LBA other than in the free block.

[0283] When at least all the active blocks storing invalid data are selected as the GC object block regardless of whether the invalid data is invalid data of a safe-to-erase object LBA, the end condition of the GC operation can be that the blocks storing invalid data disappear from the active block group regardless of whether the invalid data is invalid data of a safe-to-erase object LBA. However, since this reduces the efficiency of the GC operation, this end condition can be employed when the proportion of invalid data with respect to valid data is large in each of all the active blocks.

[0284] After determining the end condition of the GC action (step S222), the secure erasing section 24c executes a block erasing action on at least each free block in which the invalid data of the secure erasing object LBA is stored (step S224). Thereby, all the invalid data in the secure erasing object LBA is securely erased by the block erasing.

[0285] In step S224, the secure erasing section 24c can execute the block erasing on each free block in which the invalid data of the secure erasing object LBA is stored, and can further write a specific data pattern into each free block as in the first embodiment. Thus, all the invalid data of the secure erasing object LBA is securely erased by the overwriting.

[0286] The secure erasing section 24c can execute the block erasing on all the free blocks regardless of whether or not these free blocks store the invalid data of the secure erasing object LBA. Thus, the processing of executing the block erasing on at least each free block in which the invalid data of the secure erasing object LBA is stored (step S224) can be easily executed.

[0287] Alternatively, in order to reduce the number of blocks to be executed the block erasing, the secure erasing section 24c can execute the processing of determining one or more free blocks in which the invalid data of the secure erasing object LBA is stored to execute the block erasing on only the determined one or more free blocks.

[0288] In either of the former and the latter, at least the one or more free blocks in which the invalid data of the secure erasing object LBA is stored is the secure erasing object.

[0289] When the processing of step S224 is completed, the erasing control section 24 notifies the host 2 of the completion of the second specific command by sending a response indicating the completion of the second specific command to the host 2 (step S226).

[0290] The processing of the I / O command when receiving the second specific command requesting the secure erasing of the data in the specific LBA is the same as that of the first embodiment, and thus the description thereof will be omitted.

[0291] As described above, according to the third embodiment, the data of one or more specific LBAs can be securely erased by the physical secure erasing method. Further, when the copy source block includes a cluster storing valid data and in which the secure erasing object sector exists in a part thereof, the controller 4 changes the data of the secure erasing object sector to a data pattern such as all ones or all zeros when copying all the data of the cluster to the copy destination block. Thus, even when there is a cluster in which the secure erasing object sector and the non-secure erasing object valid sector coexist, the data of the non-secure erasing object valid sector can be correctly copied while ensuring the security of the physical secure erasing action.

[0292] (Fourth Embodiment)

[0293] Next, the fourth embodiment will be described. The configuration of the SSD according to the fourth embodiment is the same as that of the SSD 3 according to the first embodiment shown in FIG. 1. The fourth embodiment is the same as the third embodiment in that the secure erase of the data of the specific LBA is performed, but the processing related to the unmap action is different from that of the third embodiment. In the third embodiment, the controller 4 performs the unmap action before the GC action, whereas in the fourth embodiment, the controller 4 performs the unmap action during the execution of the GC action. Figure 1

[0294] Figure 14A is a flowchart showing a process of the physical secure erase action performed in the memory system according to the fourth embodiment. The description of the process common to the process of the physical secure erase action performed in the memory system according to the third embodiment described with reference to Figure 13A will be omitted.

[0295] When the received command is the second specific command (YES in step S204), the GC section 24b performs the GC action, and the unmap section 24a performs the unmap action during the execution of the GC action (step S232).

[0296] Similar to the third embodiment, the processes of the GC action and the unmap action differ depending on the relationship between the sector size and the cluster size (step S232).

[0297] Figure 14B is a flowchart showing a process of the GC action and the unmap action when the sector size is equal to the cluster size. In this case, one secure erase object sector corresponds to one cluster.

[0298] In step S232A, the GC section 24b selects, as the GC object block (i.e., the copy source block), at least the active block storing the data of the secure erase object LBA and the valid data of the non-secure erase object LBA, regardless of whether the data of the secure erase object LBA is valid data or invalid data. Alternatively, when the GC action is simply implemented, the GC section 24b selects, as the copy source block, all the active blocks storing invalid data, regardless of whether the invalid data is the data of the secure erase object LBA.

[0299] ​In step S232A, the GC section 24b copies valid data of the non-secure erase object LBAs from the copy source block to the copy destination block. When valid data of the secure erase object LBAs is stored in the copy source block, the demapping section 24a performs a demapping action of invalidating valid data stored in the copy source block. Thus, valid data of the secure erase object LBAs stored in the copy source block is invalidated. When valid data of the non-secure erase object LBAs stored in the copy source block is copied to the copy destination block, and the demapping action of invalidating valid data of the secure erase object LBAs stored in the copy source block is also performed, the copy source block becomes a free block. Thus, outside the free block, there is no data of the secure erase object LBAs. In other words, data (invalid data) of the secure erase object LBAs exists only in certain free blocks.

[0300] Figure 14C is a flowchart showing a procedure of the GC action and the demapping action when the sector size is smaller than the cluster size. In this case, as described above, bitmap data indicating whether data of each sector in a cluster is valid or invalid is stored in, for example, the L2P table 37.

[0301] The demapping section 24a and the GC section 24b select a cluster including at least one sector storing valid data as an object of the demapping action and the GC action.

[0302] When the cluster as a processing object contains at least one secure erase object sector (YES in step S232B-1), the demapping section 24a updates the bitmap data to invalidate all the secure erase object sectors in the cluster (step S232B-2).

[0303] The demapping section 24a checks whether all the sectors in the cluster are invalidated by the invalidation (step S232B-3).

[0304] When it is determined that all the sectors in the cluster are invalidated (YES in step S232B-3), the demapping section 24a performs a demapping action of invalidating data in the cluster (step S232B-4).

[0305] After step S232B-4, or when it is determined that all sectors in the cluster are not all invalidated (i.e., when the cluster stores valid data of a non-secure erase object) (NO in step S232B-3), or when the processing object cluster does not include a sector of a secure erase object (NO in step S232B-1), the GC unit 24b copies valid data (i.e., data of a non-secure erase object) in the cluster from the copy source block to the copy destination block (step S232B-5). At this time, as in the third embodiment, the GC unit 24b can replace data of the invalid sector in the cluster with an appropriate value. In step S232B-5, when all sectors in the cluster are valid, the GC unit 24b copies data of all sectors to the copy destination block, and updates the L2P table 37 to update the copy source cluster address to the copied destination cluster address.

[0306] The GC unit 24b determines whether the demapping action and the GC action have both been completed for all clusters including a sector storing valid data (step S232B-6).

[0307] When it is determined that the demapping action and the GC action have not been completed for all clusters (NO in step S232B-6), the GC unit 24b performs the determination of step S232B-1 for the next cluster.

[0308] When it is determined that the demapping action and the GC action have both been completed for all clusters (YES in step S232B-6), the processing of the GC unit 24b proceeds to step S222.

[0309] Finally, all valid data is copied to the copy destination block, and the copy source block becomes a free block. Therefore, outside the free block, there is no data of a secure erase object LBA. In other words, data (invalid data) of a secure erase object LBA exists only in some free blocks.

[0310] Referring back to the description of Figure 14A After performing the GC action (step S232), as in the third embodiment, the end condition of the GC action is determined (step S222), the block erasing action is performed (step S224), and the completion of the command is notified to the host 2 (step S226).

[0311] Since the processing of the I / O command when the second specific command is executed is the same as in the third embodiment, a further description thereof will be omitted.

[0312] In the fourth embodiment, substantially the same effects as in the third embodiment can be obtained.

[0313] (Fifth Embodiment)

[0314] Next, the fifth embodiment will be described. The configuration of the SSD according to the fifth embodiment is the same as that of the SSD 3 according to the first embodiment shown in FIG. 25. Figure 1 The physical secure erasure action of the fifth embodiment performs physical secure erasure of old data in response to a specific write command that requests writing of data into a logical area identified by a certain logical area identifier, and performs secure erasure of old data associated with the logical area identifier. A logical address such as an LBA or a key of a key-value store can be used as the logical area identifier. That is, the physical secure erasure action of the fifth embodiment can also be applied to a key-value store. In the case of a key-value store, the physical secure erasure action of the fifth embodiment performs physical secure erasure of an old value in response to a specific write command that requests writing of a value (data) corresponding to a certain key, and performs secure erasure of an old value (old data) associated with the key.

[0315] Hereinafter, a case where an LBA is used as a logical area identifier will be described.

[0316] For example, the specific write command can include an LBA (start LBA), a size of write data (number of sectors), an object namespace identifier, and a data pointer indicating a position (buffer address) in a memory of the host 2 where the write data is stored, like a normal write command.

[0317] The controller 4 of the SSD according to the fifth embodiment writes the write data associated with the specific write command into the NAND-type flash memory 5, and updates the L2P table 37 to associate a physical address where the write data is written with the LBA of the write data. Then, the controller 4 automatically performs a physical secure erasure action on old data (invalid data) associated with the LBA.

[0318] Due to the GC action, old data associated with the LBA can remain in a plurality of blocks. Further, even in a case where the specific write command specifying a certain LBA is received after a plurality of normal write commands specifying the LBA are received, old data associated with the LBA can remain in a plurality of blocks.

[0319] Therefore, the controller 4 performs a GC action that selects all active blocks storing old data associated with the LBA as GC object blocks (copy source blocks), and copies valid data stored in the GC object blocks to one or more copy destination blocks. Therefore, there is no old data in any block other than the free blocks.

[0320] After the execution of the GC action, the controller 4 performs block erasure at least on each of the free blocks storing the old data among the free blocks managed by the free block list 35. This makes it possible to safely erase the old data. In this case, the controller 4 can perform block erasure on all the free blocks managed by the free block list 35 after the execution of the GC action. Alternatively, in order to reduce the number of blocks to be subjected to block erasure, the controller 4 can perform processing for determining one or more free blocks storing the old data, and can perform block erasure only on these determined one or more free blocks.

[0321] Figure 15 is a flowchart showing a procedure of a physical secure erasure action performed in the memory system according to the fifth embodiment.

[0322] When the controller 4 receives a command from the host 2 (step S302), the CPU 12 judges whether the received command is a specific write command (step S304).

[0323] When it is determined that the received command is not the specific write command (NO in step S304), the CPU 12 performs processing in accordance with the received command (step S306).

[0324] When it is determined that the received command is the specific write command (YES in step S304), the write control section 22 writes write data (update data) associated with the specific write command into the NAND type flash memory 5, and updates the L2P table 37.

[0325] The GC section 24b performs a GC action (step S314). In step S314, the GC section 24b can select all the active blocks storing the old data associated with the LBA specified by the specific write command as GC target blocks, i.e., copy source blocks.

[0326] The GC section 24b freely selects one free block from the free blocks. The GC section 24b performs block erasure on the selected free block. The GC section 24b allocates the free block subjected to block erasure as a copy destination block.

[0327] The GC section 24b copies the valid data from the copy source blocks to the copy destination block.

[0328] After the execution of the GC action (step S314), the GC section 24b judges whether an end condition of the GC action is satisfied (step S322). The end condition can be that there is no longer a block storing the old data associated with the LBA specified by the specific write command in the active block group.

[0329] The GC section 24b continues the execution of the GC action until the block storing the old data disappears from the active block group (NO in step S322, step S314).

[0330] When it is determined that the end condition of the garbage collection operation is satisfied ("Yes" in step S322), the GC unit 24b ends the GC operation. At this time, there is no possibility that old data exists outside the free blocks.

[0331] After that, the secure erasing unit 24c performs block erasing on at least the free blocks where the old data exists (step S324). Thus, the old data is securely erased by the block erasing.

[0332] When the processing of step S324 is completed, the erase control section 24 notifies the host 2 of the completion of the specific write command by sending a response indicating the completion of the specific write command to the host 2 (step S326 ).

[0333] Because executing a specific write command takes a long time, the erase control unit 24 can notify the host 2 of the completion of the specific write command upon receiving the specific write command. In other words, the erase control unit 24 can execute the process of step S326 immediately before proceeding to step S312. If the processing of the specific write command is not completed normally, the controller 4 can notify the host 2 of the failure to process the specific command by using the exception notification mechanism defined in the command interface standard, or can record the occurrence of the exception in a log defined in the command interface standard.

[0334] (Variation)

[0335] A specific write command can be used, requesting data to be written to a logical area identified by a certain logical area identifier and indicating that the data written to the logical area will later be subject to secure erasure. In this case, for example, in response to receiving the specific write command from the host 2, the controller 4 executes a write operation to write the data to the logical area and stores, for example, log information in the DRAM 6 indicating that the logical area is a subject to secure erasure. Whenever the specific write command is received from the host 2, the controller 4 executes the write operation and the log information storage operation. When a specific secure erase command requesting secure erasure is received from the host 2, the controller 4 identifies the subject areas by referring to the log information. The controller 4 then executes a physical secure erase operation to securely erase the data stored in these subject areas. By performing the physical secure erase operation on multiple subject areas in this manner, the number of required GC operations can be reduced. As a result, the impact of an increase in the number of rewrites to the NAND flash memory 5 on the lifespan of the SSD 3 can be reduced, and the processing time for specific write commands can be reduced.

[0336] As described above, according to the fifth embodiment, old data associated with the LBA to which newly written data is written can be securely erased by the physical secure erase method.

[0337] (Sixth Embodiment)

[0338] Next, the sixth embodiment will be described. The configuration of the SSD according to the sixth embodiment is substantially the same as that of the SSD 3 according to the first embodiment shown in FIG. 1. The physical secure erasing action of the sixth embodiment can be considered as a modification of the third embodiment. In the third embodiment, valid data and invalid data associated with (or previously associated with) a certain LBA are securely erased. In the sixth embodiment, only invalid data among data stored in association with a logical area identified by a logical area identifier is securely erased, and valid data stored in association with the logical area identified by the logical area identifier is not erased. Figure 1

[0339] Hereinafter, a case where an LBA is used as a logical area identifier representing a secure erasing target logical area will be described as an example.

[0340] In the sixth embodiment, the second specific command of the third embodiment is changed to a third specific command which takes only invalid data of one or more specific LBAs as secure erasing target data, without taking valid data of the one or more specific LBAs as secure erasing target data.

[0341] The sixth embodiment is useful when it is desired to securely erase only old data (invalid data) written to one or more specified specific LBAs in the past, without erasing current data (valid data) which can be read by a read action.

[0342] Figure 16 is a flowchart showing a process of a physical secure erasing action performed in the memory system according to the sixth embodiment. The process for the physical secure erasing action performed in the memory system according to the sixth embodiment is similar to those described with reference to FIG. 10 in some respects. Description of such similar respects will not be repeated. Figure 13A

[0343] When the controller 4 receives a command from the host 2 (step S402), the CPU 12 judges whether the received command is the third specific command (step S404).

[0344] When it is determined that the received command is not the third specific command (NO in step S404), the CPU 12 performs processing according to the received command (step S406).

[0345] When it is determined that the received command is the third specific command (YES in step S404), the GC section 24b performs a GC action (step S412).

[0346] ​​The GC section 24b selects at least all active blocks in which invalid data associated with one or more specific LBAs designated by the third specific command is stored as GC target blocks (i.e., copy source blocks).

[0347] The GC section 24b copies valid data from the copy source blocks to copy destination blocks.

[0348] After the execution of the GC action, the GC section 24b determines whether the end condition of the GC action has been satisfied (step S422). The end condition can be that each block in which invalid data associated with one or more designated specific LBAs is stored no longer exists in the active block group.

[0349] The GC section 24b continues the execution of the GC action until each block in which invalid data associated with one or more designated specific LBAs is stored is removed from the active block group (step S412, and "No" in step S422).

[0350] When it is determined that the end condition of the garbage collection action is satisfied (Yes in step S422), the GC section 24b ends the GC action. At this time, it is not possible that invalid data associated with one or more designated specific LBAs exists in any block other than the free blocks.

[0351] After the determination of the end condition of the GC action (step S422), the secure erasing section 24c performs block erasing on at least one or more free blocks in which invalid data associated with one or more designated specific LBAs is stored (step S424). Thus, invalid data of the secure erasing target sectors is securely erased by the block erasing.

[0352] After the execution of the GC action, the secure erasing section 24c can perform block erasing on all free blocks managed by the free block list 35. Alternatively, in order to reduce the number of blocks on which block erasing is performed, the secure erasing section 24c can perform processing of designating one or more free blocks in which invalid data associated with one or more designated specific LBAs is stored, and perform block erasing only on these one or more designated free blocks.

[0353] When the processing of step S424 is completed, the erasing control section 24 notifies the host 2 of the completion of the third specific command by transmitting a response indicating the completion of the third specific command to the host 2 (step S426).

[0354] As described above, according to the sixth embodiment, invalid data associated with one or more specified specific LBAs can be securely erased by a physical secure erase method. That is, in the sixth embodiment, invalid data associated with one or more specified specific LBAs can be a secure erase object, but in the secure erase action of the sixth embodiment, invalid data among data in the specified specific namespace can be a secure erase object.

[0355] In this case, in response to receiving the fourth specific command requesting secure erasure of only invalid data in the specific namespace from the host 2, the controller 4 performs a physical secure erase action of securely erasing only invalid data among data in the specified specific namespace.

[0356] In the above-described embodiments, the description of the processing of a damaged block or a block that has exceeded a specified number of erasures is omitted. Data contained in such a damaged or aged block can be invalidated and processed as a defective block. Since the data contained in such a block is invalid data, such a block can be collectively regarded as a single free block, and can also be a block erase object at the time of secure erasure. Alternatively, when such a block is initially made (specified as) a defective block, a block erasure can be performed.

[0357] While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of protection of the present disclosure. Indeed, the novel embodiments described herein can be embodied in a multitude of other forms; additionally, various omissions, substitutions and changes in the form of the embodiments described herein can be made without departing from the spirit of the disclosure. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the disclosure.

Claims

1. A memory system comprising: A non-volatile memory comprising a plurality of blocks, wherein each block is a minimum unit of data erasure action; as well as a controller electrically connected to the nonvolatile memory, The controller is configured to: executing a copy action in response to a first command from a host, the first command requesting secure erasure of secure erasure target data stored in a first logical area identified by a first logical area identifier, the copy action copying valid data other than any secure erasure target data from one or more first blocks in the plurality of blocks storing the secure erasure target data to one or more copy destination blocks in the plurality of blocks; as well as After the copying action, performing the data erasing action on the one or more first blocks, The controller is configured to: selecting a second block from the first blocks, wherein the second block is a free block storing only invalid data and serves as one of the copy destination blocks; performing the data erasing action on the second block; as well as A copy action is performed, wherein the copy action copies the valid data except any valid data in the secure erasure target data from a third block in the first blocks to the second block.

2. The memory system according to claim 1, wherein: The secure erasure target data includes valid data.

3. The memory system according to claim 1, wherein: The secure erasure target data includes only invalid data.

4. The memory system according to claim 1, wherein: The controller is further configured to, in response to the first command, execute a demapping action to invalidate the security erase target data.

5. The memory system according to claim 4, wherein: The controller is configured to perform the demapping action before the copying action.

6. The memory system of claim 4, wherein: The controller is configured to perform the demapping action during the execution of the copying action, and The controller is configured to invalidate the valid data among the secure erasure target data stored in the one or more first blocks.

7. The memory system according to claim 1, wherein: The controller is also configured to, in response to the first command, perform the data erasure action on an idle block among the multiple blocks that did not store valid data before starting the copy action, which stores invalid data included in the secure erase object data when the first command is received and is not used as one of the copy destination blocks.

8. The memory system according to claim 1, wherein: The controller is configured to manage a plurality of namespaces respectively identified by a plurality of namespace identifiers, and The first logical area identifier is a namespace identifier that identifies a secure erase object namespace.

9. The memory system according to claim 1, wherein: The first logical area identifier includes one or more logical addresses identifying one or more security erase target sectors.

10. The memory system according to claim 1, wherein: The first logical region identifier includes one or more keys that identify one or more secure erase object values.

11. The memory system of claim 1 , wherein: The first logical area identifier includes one or more logical addresses identifying one or more sectors to be subject to security erasure, and The controller is further configured to: Using a logical-physical address translation table, a mapping between each logical address and each physical address of the nonvolatile memory is managed in units of clusters. changing data of the security erasure target sector stored in a first cluster into a first data pattern, wherein the first cluster stores valid data and the security erasure target sector is located in the first cluster, and A copy action of copying the first cluster to the one or more copy destination blocks is performed.

12. The memory system according to claim 1, wherein: The secure erase target data includes invalid data previously associated with the first logical region identifier.

13. The memory system according to claim 1, wherein: The first command specifies the first logical region identifier.

14. The memory system according to claim 1, wherein: The first logical area identifier is specified by a command from the host other than the first command.

15. A memory system comprising: A non-volatile memory comprising a plurality of blocks, wherein each block is a minimum unit of data erasure action; as well as a controller electrically connected to the nonvolatile memory, The controller is configured to: performing a copy action in response to a first write command from a host, the first write command requesting writing data to a first logical area identified by a first logical area identifier and securely erasing old data stored in the first logical area, the copy action copying valid data other than the old data from one or more first blocks storing the old data among the plurality of blocks to one or more copy destination blocks among the plurality of blocks; and After the copying action, performing the data erasing action on the one or more first blocks, The controller is configured to: selecting a second block from the first blocks, wherein the second block is a free block storing only invalid data and serves as one of the copy destination blocks; performing the data erasing action on the second block; and A copy action is performed, wherein the copy action copies the valid data from a third block in the first blocks to the second block.

16. The memory system according to claim 15, wherein: After the copying action is completed, the data erasing action is directly performed on the one or more first blocks.

17. The memory system according to claim 15, wherein: In response to a second command from the host requesting secure erasure of secure erasure target data, the data erasure action is performed on the one or more first blocks after the copy action is completed.

18. A method for controlling a nonvolatile memory comprising a plurality of blocks, wherein each block is a minimum unit of data erasure, the method comprising: executing a copy action in response to a first command from a host, the first command requesting secure erasure of secure erasure target data stored in a first logical area identified by a first logical area identifier, the copy action copying valid data other than any secure erasure target data from one or more first blocks in the plurality of blocks storing the secure erasure target data to one or more copy destination blocks in the plurality of blocks; After the copying action, performing the data erasing action on the one or more first blocks, selecting a second block from the first blocks, wherein the second block is a free block storing only invalid data and serves as one of the copy destination blocks; performing the data erasing action on the second block; as well as A copy action is performed, wherein the copy action copies the valid data except any valid data in the secure erasure target data from a third block in the first blocks to the second block.

19. The control method according to claim 18, wherein: The secure erase target data includes invalid data previously associated with the first logical region identifier.

Images