Storage system and control method

Abstract

One embodiment of the present invention provides a storage system and a control method capable of performing invalidation processing that can cope with a case where an invalidation request is issued by mistake from a host. A controller writes first data associated with a write request and a first logical address specified by the write request to a first block, and updates a logical-physical address conversion table in a manner such that a first physical address representing a first storage location within the first block to which the first data is written is associated with the first logical address. In response to receiving an invalidation request from the host to invalidate the first data corresponding to the first logical address, the controller acquires the first physical address associated with the first logical address from the logical-physical address conversion table, and updates a first valid data identifier corresponding to the storage location represented by the first physical address to a value representing invalidation.

Description

[0001] [Related Applications]

[0002] This application enjoys priority based on Japanese Patent Application No. 2021-102261 (filed on June 21, 2021). This application incorporates the entire contents of the basic application by reference. Technical Field

[0003] Embodiments of the present invention relate to a storage system having non-volatile memory and techniques for controlling the non-volatile memory. Background Technology

[0004] In recent years, storage systems with non-volatile memory have become widely used. As one such storage system, solid-state drives (SSDs) with NAND flash memory are known.

[0005] In storage systems like SSDs, a feature is used to invalidate data corresponding to the logical address specified by an invalidation request issued by the host. This feature is useful for reducing write amplification in the storage system.

[0006] Recently, there has been a desire to implement new invalidation handling that can be implemented in the event that a host erroneously issues an invalidation request. Summary of the Invention

[0007] One embodiment of the present invention aims to solve the technical problem of providing a storage system and control method capable of performing invalidation processing in the event that the host erroneously issues an invalidation request.

[0008] According to one embodiment, a storage system capable of connecting to a host includes: a non-volatile memory comprising multiple blocks; and a controller configured to manage multiple valid data identifiers per block using a management table. These multiple valid data identifiers are valid data identifiers corresponding to multiple storage locations included in each of the multiple blocks, and each valid data identifier indicates whether data stored in its corresponding storage location is valid or invalid. In response to receiving a write request specifying a first logical address from the host, the controller writes both first data associated with the write request and the first logical address into a first block. This updates the logical physical address translation table by associating a first physical address representing a first storage location within the first block where the first data has been written with the first logical address, and updates the first valid data identifier in the management table corresponding to the first storage location within the first block with a value indicating validity. In response to receiving an invalidation request from the host to invalidate the first data corresponding to the first logical address, the controller obtains the first physical address associated with the first logical address from the logical physical address translation table. While maintaining the obtained first physical address in the logical physical address translation table, the controller updates the first valid data identifier in the management table corresponding to the first storage location in the first block represented by the obtained first physical address to a value indicating invalidity. When performing garbage collection on the non-volatile memory, the controller selects the copy source block for garbage collection from the plurality of blocks. Based on the plurality of second valid data identifiers in the management table corresponding to the plurality of storage locations within the copy source block, the controller copies both valid data and the logical address corresponding to the valid data from the copy source block to the copy target block. The controller updates the logical physical address translation table in such a way that the physical address representing the copy target storage location within the copy target block where the valid data has been copied is associated with the logical address of the valid data. The controller updates the third valid data identifier in the management table corresponding to the copy source storage location within the copy source block where the valid data is stored to an invalid value, and updates the fourth valid data identifier in the management table corresponding to the copy target storage location within the copy target block to a valid value. Attached Figure Description

[0009] Figure 1 This is a block diagram illustrating a structural example of an information processing system including a storage system and a host, as described in the implementation.

[0010] Figure 2This is a block diagram illustrating an example of the relationship between multiple channels and multiple NAND flash memory dies used in a storage system implemented in an embodiment.

[0011] Figure 3 This is a block diagram illustrating an example of the structure of a superblock used in the storage system of an implementation.

[0012] Figure 4 This is a diagram illustrating an example of the structure of a logical physical address translation table used in a storage system implemented in this way.

[0013] Figure 5 This is a diagram illustrating an example of the relationship between multiple storage locations within each block and multiple physical addresses in a storage system according to an implementation method.

[0014] Figure 6 This diagram illustrates an example of an action performed in a storage system of an implementation method, where a pair of logical addresses and data is written to a block.

[0015] Figure 7 This diagram illustrates another example of the action performed in the storage system of the implementation method, which involves writing a pair of logical addresses and data into a block.

[0016] Figure 8 It is a graph that represents the state of blocks where data has been written to all storage locations.

[0017] Figure 9 It means Figure 8 Data configuration and related data storage locations within a block Figure 9 A graph mapping the valid sectors corresponding to the blocks.

[0018] Figure 10 This is a diagram illustrating the data writing and garbage collection operations performed in the storage system of the implementation method.

[0019] Figure 11 This diagram illustrates an example of a data write operation performed in the storage system of an implementation when a write request is received from the host.

[0020] Figure 12 It means according to Figure 11 The diagram shows the action of updating the logical physical address translation table as a result of the data writing action.

[0021] Figure 13 It means according to Figure 11 The diagram shows the action of updating the valid sector mapping performed in response to a data write operation.

[0022] Figure 14 This diagram illustrates an example of a write-update data operation performed in the storage system of an implementation.

[0023] Figure 15 It means according to Figure 14 The diagram shows the action of updating the logical physical address translation table as an action of writing updated data.

[0024] Figure 16 It means according to Figure 14 The diagram illustrates the actions performed during the update data write operation: updating the valid sector mapping corresponding to the block where previous data was written, and updating the valid sector mapping corresponding to the block where updated data was written.

[0025] Figure 17 It is a graph that represents the state of each unwritten storage location within a block where updated data has been written, and where data has been written.

[0026] Figure 18 It means Figure 17 The data configuration within the block shown and Figure 17 The diagram shows an example of the data structure for mapping the valid sectors corresponding to the block shown.

[0027] Figure 19 This diagram illustrates the invalidation process performed in the storage system of the implementation when an invalidation request (Trim instruction) specifying a certain logical address is received from the host.

[0028] Figure 20 This is a diagram illustrating the data readout operation performed in the storage system of the implementation method.

[0029] Figure 21 This diagram illustrates the revalidation process performed in the storage system of the implementation when a revalidation request (Untrim instruction) is received from the host to revalidate the data corresponding to the logical address specified by the invalidation request.

[0030] Figure 22 It is a graph that represents the data configuration within a block, the valid sector mapping corresponding to that block, the content of the valid sector mapping after the invalidation request has been processed, and the content of the valid sector mapping after the re-validation request has been processed.

[0031] Figure 23 It is a graph representing the garbage collection action that copies valid data and logical addresses from the source block to the target block based on the valid sector mapping corresponding to the source block.

[0032] Figure 24 It means in Figure 23 The diagram shows the action of updating the logical physical address translation table during garbage collection.

[0033] Figure 25 It means in Figure 23 The diagram shows the actions performed during garbage collection that update and copy the valid sector mappings corresponding to the source block and the target block.

[0034] Figure 26 It is a diagram that shows the action of reusing the copied source block in order to write data after all valid data and all logical addresses in the source block have been copied.

[0035] Figure 27 This is a diagram illustrating the actions taken when the logical address from which the data is read along with the storage location corresponding to the physical address obtained from the logical-physical address translation table is inconsistent with the logical address specified by the read request.

[0036] Figure 28 It is a diagram showing the timing of data write operations, garbage collection operations, invalidation processing, revalidation processing, and data read operations performed in the storage system of the implementation method.

[0037] Figure 29 This is a flowchart showing the sequence of data write operations performed in the storage system of the implementation method.

[0038] Figure 30 This is a flowchart showing the sequence of garbage collection operations performed in the storage system of the implementation method.

[0039] Figure 31 This is a flowchart illustrating the steps of invalidation processing performed in the storage system of the implementation method.

[0040] Figure 32 This is a flowchart showing the sequence of data readout operations performed in the storage system of the implementation method.

[0041] Figure 33 This is a flowchart illustrating the steps of the re-validation process performed in the storage system of the implementation method. Detailed Implementation

[0042] The embodiments will now be described with reference to the accompanying drawings.

[0043] First, the structure of the information processing system, including the storage system of the implementation method, will be described. Figure 1 This is a block diagram illustrating an example structure of an information processing system 1, including the storage system and host of the embodiment. Hereinafter, it is assumed that the storage system of the embodiment is implemented as a solid-state drive (SSD) 3. The information processing system 1 includes a host (host device) 2 and an SSD 3.

[0044] Host 2 is the information processing device that controls the operation of SSD 3. Examples of information processing devices include personal computers, server computers, and various other computing devices. Host 2 sends write requests (requests) to SSD 3. Additionally, Host 2 sends read requests (requests) to SSD 3.

[0045] The host 2 includes a processor 101 and a memory 102, etc. The processor 101 is a CPU (Central Processing Unit) configured to control the operation of various components within the host 2. The processor 101 executes software (host software) loaded into the memory 102 from the SSD 3 or other storage devices within the host 2. The host software includes an operating system, a file system, device drivers, applications, etc.

[0046] Memory 102 is the main memory located in host 2. Memory 102 is a volatile semiconductor memory in which data stored in memory 102 is lost when power is cut off. Memory 102 is implemented, for example, by a random access memory such as DRAM (Dynamic Random Access Memory).

[0047] An SSD3 is a semiconductor storage device configured to receive write and read requests from a host 2 and perform data write and read operations on non-volatile memory based on the received write and read requests. Non-volatile memory is a semiconductor storage device that retains data stored in it even after the power supply is interrupted. NAND flash memory is used as an example of non-volatile memory.

[0048] The SSD3 can be connected to the host device 2. The SSD3 may be built into the information processing device, for example. The SSD3 can also be connected to the information processing device via cable or network.

[0049] As a standard for the logical interface used to connect host 2 to SSD 3, Serial Attached SCSI (SAS), Serial ATA (SATA), and NVM Express can be used, for example. TM (NVMe TM standard).

[0050] The SSD3 features a controller 4 and non-volatile memory (such as NAND flash memory) 5. The SSD3 may also feature random access memory, such as DRAM 6.

[0051] Controller 4 is a memory controller configured to control NAND flash memory 5, which is an example of non-volatile memory. Controller 4 can also be implemented using circuitry such as a System-on-a-Chip (SoC). Controller 4 is electrically connected to NAND flash memory 5 via a memory bus called a channel.

[0052] The NAND flash memory 5 includes a cell array. The cell array comprises multiple cells arranged in a matrix. The cell array within the NAND flash memory 5 includes multiple blocks BLK0 to BLKx-1. Blocks BLK0 to BLKx-1 are the units for data erasure operations. Blocks BLK0 to BLKx-1 are also referred to as physical blocks or flash memory blocks.

[0053] Blocks BLK0 to BLKx-1 each comprise multiple pages (here, pages P0 to Py-1). Each page includes multiple storage units connected to the same word line. Pages P0 to Py-1 are the units for data write and data read operations, respectively.

[0054] The NAND flash memory 5 may also include multiple NAND flash memory dies (multiple NAND flash memory chips). Each NAND flash memory die can be a two-dimensional flash memory or a three-dimensional flash memory.

[0055] DRAM6 is a volatile semiconductor memory whose data is lost when power is cut off. DRAM6 is used, for example, to temporarily store data that should be written to NAND flash memory 5. In addition, the storage area of ​​DRAM6 is used to store various management data used by controller 4.

[0056] Next, the detailed structure of controller 4 will be explained.

[0057] The controller 4 includes a host interface (I / F) 11, a CPU 12, a NAND interface (I / F) 13, a DRAM interface (I / F) 14, a direct memory access controller (DMAC) 15, static RAM (SRAM) 16, and an ECC (Error Correction Code) encoding / decoding unit 17.

[0058] These host interfaces 11, CPU 12, NAND interface 13, DRAM interface 14, DMAC 15, SRAM 16, and ECC encoding / decoding unit 17 are interconnected via bus 10.

[0059] Host interface 11 is a host interface circuit configured to perform communication with host 2. Host interface 11 receives various instructions (requests) from host 2. These instructions include write instructions, read instructions, trim instructions, untrim instructions, etc.

[0060] A write instruction is an instruction (write request) used to write the data to be written (write data) into the NAND flash memory 5. A write instruction may include, for example, a logical address (start logical block address: start LBA) representing the initial sector to be written, the size of the write data, and a data pointer (buffer address) representing the location within the memory 102 of the host 2 where the write data is stored.

[0061] The size of the data to be written can also be specified, for example, by the number of sectors (logical blocks). One sector corresponds to the minimum size of data that can be written by host 2. Therefore, the size of the data to be written is represented by a multiple of the number of sectors.

[0062] In this embodiment, the write data written to the NAND flash memory 5 according to the write command from the host 2 is also referenced as user data.

[0063] The read instruction is an instruction (read request) to read data from the NAND flash memory 5. The read instruction includes a logical address (start LBA) representing the first sector of the data to be read (read target data), the data size of the read target data, and a data pointer (buffer address) representing the location in the memory 102 of the host 2 to which the read target data is transferred.

[0064] The Trim instruction is an instruction that requests the invalidation of data corresponding to a given logical address. The Trim instruction specifies the logical address of the data to be invalidated. More specifically, the Trim instruction indicates the logical address (start LBA) representing the initial sector to be invalidated and the number of sectors (logical addresses) to be invalidated. The Trim instruction is sometimes also called the Unmap instruction or the Deallocate instruction.

[0065] By using the Trim command, host 2 can notify SSD 3 of the logical addresses of data (user data) that has become unnecessary. This notification reduces the amount of data that should be copied during garbage collection, thus reducing write amplification on SSD 3.

[0066] The Untrim instruction is a new instruction (revalidation request) supported by the SSD3 in this implementation. The Untrim instruction is used to cancel the invalidation of data corresponding to a certain logical address and make the data corresponding to that logical address valid again. The Untrim instruction indicates the logical address (start LBA) representing the initial sector to be revalidated and the number of sectors (logical addresses) to be revalidated.

[0067] CPU12 is a processor configured to control host interface 11, NAND interface 13, DRAM interface 14, DMAC 15, SRAM 16, and ECC encoding / decoding unit 17.

[0068] CPU 12 loads a control program (firmware) from NAND flash memory 5 or ROM (not shown) into DRAM 6 based on the power supply to SSD 3. CPU 12 functions as a flash translation layer (FTL) configured to perform data management and block management of NAND flash memory 5 by executing the firmware. Data management performed by FTL includes: (1) management of mapping information that represents the correspondence between logical addresses and physical addresses of NAND flash memory 5; and (2) processing for hiding constraints of NAND flash memory 5 (e.g., page-level read / write operations and block-level erase operations).

[0069] The logical address is the address used by host 2 for accessing SSD3. For example, an LBA is used as a logical address. The management of the mapping between each logical address used by host 2 for accessing SSD3 and each physical address PBA (physical block address) of NAND flash memory 5 is performed using a logical-to-physical address translation table (L2P table) 31.

[0070] CPU12 uses L2P table 31 to manage the mapping between logical addresses and physical addresses. The physical address corresponding to a certain logical address indicates the storage location (physical storage location) within the NAND flash memory 5 where data corresponding to that logical address has been written. L2P table 31 can also be loaded from NAND flash memory 5 to DRAM 6, for example, in response to the power supply to SSD 3.

[0071] L2P table 31 manages the mapping between logical addresses and physical addresses (PBAs) in sectors, using a prescribed management size. A sector corresponds to the minimum data size that can be written by host 2. The size of a sector (logical block) is, for example, 4 KiB. Data corresponding to multiple sectors can also be stored in a single page. The size of a page is, for example, 16 KiB.

[0072] Data management performed by FTL also includes the management of valid and invalid data. CPU12 uses a management table to manage multiple valid data identifiers corresponding to multiple storage locations within each block of the NAND flash memory 5.

[0073] Multiple valid data identifiers indicate whether the data stored in the corresponding storage location is valid or invalid. These multiple valid data identifiers corresponding to each block are referenced as a valid sector map 32. A valid sector map 32 corresponding to a block includes the same number of valid data identifiers as the number of storage locations (sectors) included in the block. The block corresponding to a valid sector map 32 is, for example, a physical block. Alternatively, the block corresponding to a valid sector map 32 can also be a reference... Figure 3 The block group (i.e., superblock) will be discussed later.

[0074] Each valid data identifier is represented by a 1-bit flag. Therefore, the valid sector mapping 32 is also referenced as bit-mapped data. In addition, each valid data identifier is also referenced as a bit-mapped flag.

[0075] Valid data is the latest data associated with a specific logical address. When data corresponding to a logical address is written to NAND flash memory 5, the data written to NAND flash memory 5 is valid data.

[0076] Furthermore, when updated data corresponding to a certain logical address is written to the NAND flash memory 5, the written data is valid data. Old data remaining in the NAND flash memory 5 is treated as invalid data. Additionally, data corresponding to the logical address specified by the invalidation request from host 2 is also treated as invalid data.

[0077] Block management performed by FTL includes the management of bad blocks, wear leveling, and garbage collection.

[0078] The loss balancing action is used to even out the number of rewrites (the number of programming / elimination loops) for each block.

[0079] Garbage collection is an operation used to reduce the number of blocks containing a mixture of valid and invalid data and increase the number of free blocks. During garbage collection, the CPU12 selects a source block from the mixed data blocks and copies the valid data stored in the source block to the target block. When the copying of all valid data in the source block is complete, the source block is released as a free block that does not contain valid data and can be reused for data writing.

[0080] As described above, data corresponding to the logical address specified by the invalidation request from host 2 is treated as invalid data. Therefore, the invalidation request can reduce the amount of data that needs to be copied during garbage collection, thereby reducing the write amplification of the SSD3.

[0081] Block management performed by FTL also includes the management of free blocks and active blocks. An active block is a block that stores valid data. CPU12 uses the free block list 33 to manage each free block. Additionally, CPU12 uses the active block list 34 to manage each active block.

[0082] NAND interface 13 is a memory control circuit configured to control NAND flash memory 5 under the control of CPU 12. Communication between NAND interface 13 and NAND flash memory 5 is performed, for example, via Toggle NAND flash interface or Open NAND flash interface (ONFI).

[0083] DRAM interface 14 is a DRAM control circuit configured to control DRAM 6 under the control of CPU 12. A portion of the storage area of ​​DRAM 6 is used as a write buffer (WB) 30 for temporarily storing write data associated with one or more write requests received from host 2. In addition, another portion of the storage area of ​​DRAM 6 is used as a storage area for storing L2P table 31, active sector map 32, free block list 33, and active block list 34.

[0084] Under the control of CPU 12, DMAC 15 performs data transfers between host 2's memory 102 and DRAM 6 (or SRAM 16). When write data needs to be transferred from host 2's memory 102 to write buffer (WB) 30, CPU 12 specifies to DMAC 15 the source address of the transfer, the size of the write data to be transferred, and the destination address of the transfer, which represents the location within host 2's memory 102.

[0085] When writing data to the NAND flash memory 5, the ECC encoding / decoding unit 17 encodes the data and adds error correction codes (ECC) as redundancy codes to the data. When reading data from the NAND flash memory 5, the ECC encoding / decoding unit 17 uses the ECC appended to the read data to correct errors in the data.

[0086] Next, the invalidation processing function of this embodiment will be described. The CPU 12 can function as a write control unit 121, a read control unit 122, a garbage collection (GC) control unit 123, an invalidation processing unit 124, an LBA comparison processing unit 125, and a re-validation processing unit 126.

[0087] The write control unit 121, read control unit 122, garbage collection (GC) control unit 123, invalidation processing unit 124, LBA comparison processing unit 125, and revalidation processing unit 126 can be implemented by dedicated hardware within the controller 4.

[0088] In response to receiving a write request from host 2, write control unit 121 writes the data (write data) associated with the received write request to the write target block. The write target block is a block allocated as a block used for writing data from host 2. Write control unit 121 can not only write the write data to the write target block, but also write both the write data and the LBA specified by the write request to the write target block.

[0089] Additionally, the write control unit 121 updates the L2P table 31 by associating the physical address PBA, which represents the storage location within the write target block to which write data has been written, with the LBA specified by the write request. Furthermore, the write control unit 121 updates the valid data identifier in the valid sector mapping 32 corresponding to the storage location within the write target block to a valid value.

[0090] In response to receiving a read request from host 2, read control unit 122 retrieves the physical address PBA (= block identifier and offset) associated with the LBA specified in the read request from L2P table 31 by referring to L2P table 31. Then, based on the retrieved physical address, read control unit 122 reads both the data and the corresponding LBA from the storage location within the block determined by that physical address. The LBA read along with the data is used to verify that the read data corresponds to the LBA specified in the read request.

[0091] When performing garbage collection on the NAND flash memory 5, the GC control unit 123 selects one or more copy source blocks (GC source blocks) from multiple blocks of the NAND flash memory 5 for garbage collection. In selecting the copy source block, for example, a GC strategy that prioritizes selecting valid blocks with the least amount of valid data can be used, or other GC strategies can be used. The copy source block is the GC object block for which garbage collection has been performed.

[0092] The GC control unit 123 determines the valid data within the selected copy source block based on multiple valid data identifiers in the valid sector mapping 32 corresponding to multiple storage locations within the selected copy source block. Then, the GC control unit 123 copies both the valid data and the LBA corresponding to the valid data from the copy source block to the copy target block (GC target block) used for garbage collection operations.

[0093] The GC control unit 123 updates the L2P table 31 in such a way that the physical address representing the copy target storage location within the copy target block where the copy target data has been copied is associated with the LBA corresponding to the copied valid data.

[0094] The source block stores a pair of valid data and LBAs. Therefore, the GC control unit 123 can easily determine the LBA corresponding to the valid data. As a result, the GC control unit 123 can easily associate the physical address representing the copy target storage location within the copy target block where the valid data has been copied with the LBA corresponding to the valid data.

[0095] Furthermore, the GC control unit 123 updates the valid data identifier in the valid sector mapping 32 corresponding to the copy source storage location within the copy source block containing valid data to a value indicating invalidity. Additionally, the GC control unit 123 updates the valid data identifier in the valid sector mapping 32 corresponding to the copy target storage location within the copy target block to a value indicating validity.

[0096] After copying all valid data within the source block and all LBAs corresponding to that valid data are completed, the source block can be reused for data writing. That is, when a block has undergone garbage collection, it becomes a free block. Therefore, the garbage-collected block is reused as a write target block.

[0097] In response to a Trim instruction received from host 2 requesting the invalidation of data corresponding to a certain logical address, invalidation processing unit 124 retrieves the physical address representing the storage location containing the data corresponding to that logical address by referring to L2P table 31. Then, while maintaining the retrieved physical address in L2P table 31, invalidation processing unit 124 updates the valid data identifier in valid sector mapping 32 corresponding to the storage location represented by the retrieved physical address to a value indicating invalidity.

[0098] As a result, data stored at the storage location represented by the obtained physical address is treated as invalid data. Therefore, when a block including this storage location is selected as a replication source block for garbage collection, data stored at this storage location can be excluded from the replication object, thereby reducing write amplification.

[0099] In L2P table 31, the physical address PBA corresponding to the LBA specified by the Trim instruction remains after being deleted. Therefore, even if host 2 erroneously issues a Trim instruction specifying a certain LBA, it can still retrieve the physical address PBA corresponding to the LBA specified by that Trim instruction from L2P table 31.

[0100] Therefore, even if host 2 issues a Trim command specifying a certain LBA, it can still perform garbage collection on the block that stores data corresponding to that LBA, and read the data corresponding to that LBA from the block before the block is reused as a new write target block.

[0101] Therefore, the invalidation process of this embodiment, which updates only the valid sector mapping 32 without updating the L2P table 31, can achieve an effect equivalent to the original purpose of the Trim instruction to reduce write amplification, and can enable the reading of data corresponding to the logical address specified by the Trim instruction to be performed for a certain period of time.

[0102] Here, the invalidation process for the comparative examples will be explained.

[0103] Upon receiving a Trim instruction specifying a certain LBA, in the invalidation process of the comparison example, the physical address is deleted from the entry in the L2P table 31 corresponding to that LBA, and in its place, the magic number representing invalidity is stored in that entry.

[0104] The data corresponding to the LBA remains in the NAND flash memory 5. However, the physical address representing the storage location where the data is stored is deleted. Therefore, in the invalidation process of the comparative example, even if the host 2 erroneously issues a Trim command, it is impossible to read the data corresponding to the LBA specified by the Trim command from the SSD 3.

[0105] The LBA comparison processing unit 125 compares the LBA read from the NAND flash memory 5 along with the data with the LBA specified by the read request based on the read request from the host 2.

[0106] For example, when a block containing data corresponding to an LBA specified by a processed Trim instruction is garbage collected, and that block is reused as a new write target block, it is possible to write new data corresponding to other LBAs at the storage location where that data is stored. Therefore, if a read request specifying an LBA specified by a processed Trim instruction is issued from host 2 after garbage collection of that block, it is possible to read data corresponding to other LBAs from that block.

[0107] In this embodiment, based on the result of the LBA comparison performed by the LBA comparison processing unit 125, it is possible to determine whether the data read from the NAND flash memory 5 corresponds to the LBA specified in the read request. Therefore, it is possible to prevent data corresponding to other LBAs that are different from the LBA specified in the read request from being sent to the host 2.

[0108] In response to receiving an Untrim instruction from host 2 to revalidate data corresponding to a certain LBA, the revalidation processing unit 126 retrieves the physical address associated with the LBA from the L2P table 31 by referring to the L2P table 31. Then, the revalidation processing unit 126 updates the valid data identifier in the valid sector mapping 32 corresponding to the storage location represented by the retrieved physical address to a valid value. Thus, the invalidation of the data corresponding to the LBA can be canceled, and the data corresponding to the LBA can be revalidated.

[0109] In this embodiment, the LBA comparison performed by the LBA comparison processing unit 125 is also performed when the Untrim command is received. Therefore, even if an Untrim command specifying the LBA specified by the processed Trim command is issued from the host 2 after garbage collection has been performed on a block storing data corresponding to the LBA specified by the processed Trim command, it is possible to prevent data corresponding to an LBA different from the LBA specified by the Untrim command from being incorrectly validated.

[0110] Next, the structure of the NAND flash memory 5, which includes multiple NAND flash memory dies, will be described. Figure 2 This is a block diagram illustrating an example of the relationship between multiple channels and multiple NAND flash memory dies used in a storage system implemented in an embodiment.

[0111] Multiple NAND flash memory dies can operate independently. Therefore, NAND flash memory dies are processed as units capable of parallel operation. Figure 2 The example illustrates a case where 16 channels Ch.1 to Ch.16 are connected to the NAND interface (I / F) 13, and two NAND flash memory dies are connected to each of the 16 channels Ch.1 to Ch.16.

[0112] In this case, the 16 NAND flash memory dies #1 to #16 connected to channels Ch.1 to Ch.16 can be configured as memory bank #0, and the remaining 16 NAND flash memory dies #17 to #32 connected to channels Ch.1 to Ch.16 can be configured as memory bank #1. The memory bank is processed as a unit for parallel operation of multiple memory dies through memory bank interleaving. Figure 2 In the example structure, by interleaving 16 channels and memory banks that use 2 memory banks, up to 32 NAND flash memory dies can operate in parallel.

[0113] The erasure operation can be performed either as a single block (physical block) or as a block group, which includes a set of multiple physical blocks that can be processed in parallel. The block group is also referred to as the superblock.

[0114] A superblock, which is a set of multiple physical blocks, is not limited to this; it can also include a total of 32 physical blocks, each selected from NAND flash memory dies #1 to #32. Furthermore, each of the NAND flash memory dies #1 to #32 can also have a multi-plane structure. For example, if each of the NAND flash memory dies #1 to #32 has a multi-plane structure including two planes, a superblock can also include a total of 64 physical blocks, selected sequentially from the 64 planes corresponding to the NAND flash memory dies #1 to #32.

[0115] exist Figure 3The example illustrates a superblock (SB) comprising 32 physical blocks (here, physical block BLK2 in NAND flash memory die #1, physical block BLK3 in NAND flash memory die #2, physical block BLK7 in NAND flash memory die #3, physical block BLK4 in NAND flash memory die #4, physical block BLK6 in NAND flash memory die #5, ..., physical block BLK3 in NAND flash memory die #32).

[0116] Alternatively, a structure can be used where a superblock consists of only one physical block, in which case a superblock is equivalent to a physical block.

[0117] Next, the L2P table 31 of this embodiment will be explained. Figure 4 This is a diagram showing an example of the structure of L2P table 31 used in the SSD3 implementation.

[0118] L2P table 31 includes multiple entries corresponding to multiple logical addresses. In the entry corresponding to a specific logical address, the physical address PBA associated with that logical address is stored. For example, when controller 4 writes data corresponding to a specific logical address to a storage location within NAND flash memory 5, controller 4 updates L2P table 31, associating the physical address PBA representing that storage location with the logical address.

[0119] exist Figure 4 The example illustrates how logical addresses 0x00000000, 0x00000001, 0x00000002, 0x00000005, 0x00000006, and 0x00000007 are associated with physical addresses PBA0, PBA2, PBA1, PBA4, PBA5, and PBA6, respectively.

[0120] Even if the data corresponding to a certain logical address is not written to the NAND flash memory 5, a specific value representing invalidity (unallocated), i.e., a magic number (INV), can also be stored in the entry corresponding to that logical address.

[0121] The physical address (PBA) representing each storage location within the NAND flash memory 5 is represented by a combination of a block identifier and an offset within the block. The block identifier is an identifier that uniquely identifies each block. The offset corresponding to a storage location within a block represents the offset value from the beginning of the block to that storage location.

[0122] In NAND flash memory, a write to a page can only be performed once within one erase cycle (program / erase cycle) of the block containing that page. That is, it is not possible to directly overwrite new data within a block that has already been written to.

[0123] Therefore, when updating data that has already been written, controller 4 writes the new data to the unwritten area within the block (or other blocks), and then treats the previous data as invalid. In other words, controller 4 writes the updated data corresponding to a certain logical address to another storage location instead of the storage location that stores the previous data corresponding to that logical address. Then, controller 4 updates L2P table 31, associating the physical address representing this other storage location with the logical address.

[0124] Next, the multiple physical addresses within the NAND flash memory 5 will be explained. Figure 5 This is a diagram illustrating an example of the relationship between multiple storage locations within each block and multiple physical addresses in an SSD3 implementation.

[0125] As described above, the physical address of each storage location within a block is represented by a combination of the block identifier and the offset corresponding to that storage location. Figure 5 The diagram illustrates multiple storage locations comprised of any block (here, block BLKn) within a NAND flash memory 5. The block identifier for block BLKn is BLKn. Block BLKn comprises multiple pages (e.g., pages 0 to 63).

[0126] With each page from 0 to 63 having a size of 16 KiB and each sector having a size of 4 KiB, block BLKn is logically divided into 256 (=4×64) storage locations, each with a size of 4 KiB.

[0127] Offset +0 represents the initial storage location within page P0, offset +1 represents the second storage location within page P0, offset +2 represents the third storage location within page P0, and offset +3 represents the fourth storage location within page P0.

[0128] Offset +4 represents the initial storage location within page P1, offset +5 represents the second storage location within page P1, offset +6 represents the third storage location within page P1, and offset +7 represents the fourth storage location within page P1.

[0129] Furthermore, offset +252 represents the initial storage location within page P63, offset +253 represents the second storage location within page P63, offset +254 represents the third storage location within page P63, and offset +255 represents the fourth storage location within page P63.

[0130] For example, the physical address of the initial storage location within page P0 is represented by a combination of the block identifier BLKn and offset +0.

[0131] Next, the action of writing the data to the block along with the logical address (LBA) of the data to be written will be explained. Figure 6 and Figure 7 This diagram illustrates an example of the action performed in an SSD3 implementation where a logical address and data pair is written to a block.

[0132] Within each block, each page may also include a user data area for storing user data and a redundant area for storing management data. The size is 16 KiB+α.

[0133] Controller 4 writes both 4KiB of user data and the logical address (LBA) corresponding to that 4KiB of user data to the write target block (in this case, block BLKn). In this case, it can be done as follows: Figure 6 As shown, four data sets, each containing LBA and 4KiB user data, are written to the same page. Offsets can also represent set boundaries.

[0134] Or, it can be like Figure 7 As shown, four 4KiB user data entries are written to the user data area within the page, and four LBA entries corresponding to these four 4KiB user data entries are written to the redundant area within the page.

[0135] Next, a structural example of the effective sector mapping 32 will be described. Here, it is assumed that the effective sector mapping 32 consists of multiple effective sector mappings corresponding to multiple blocks respectively. Figure 8 As shown, this assumes that data is stored in all storage locations within block BLKn. In page P0 of block BLKn, which corresponds to a valid sector mapping, the four storage locations sequentially store valid data, invalid data, valid data, and valid data. Similarly, in page P63 of block BLKn, the four storage locations sequentially store valid data, valid data, invalid data, and valid data.

[0136] Figure 9 It means Figure 8 Data configuration and related data in multiple storage locations within block BLKn Figure 8 The effective sector mapping of block BLKn is a 32-n graph.

[0137] The effective sector mapping 32-n includes 256 effective data identifiers, i.e., 256 bit mapping flags (1011…1101), corresponding to 256 storage locations within block BLKn.

[0138] Here, a "1" valid data identifier indicates that the data stored at the corresponding storage location is valid data. A "0" valid data identifier indicates that the data stored at the corresponding storage location is invalid data.

[0139] Next, the data writing and garbage collection actions will be explained. Figure 10 This is a diagram showing the data write operations and garbage collection operations performed in the SSD3 implementation.

[0140] The NAND flash memory 5 comprises multiple blocks, which are broadly divided into free blocks that do not contain valid data and active blocks that contain valid data. Each free block is managed through a free block list 33. Each active block is managed through an active block list 34.

[0141] First, a free block is selected from the free block list 33. The selected free block is allocated as the write target block after the erase operation is performed. If the write target block has already been allocated, there is no need to allocate the free block as the write target block.

[0142] The write data stored in the write buffer (WB) 30, together with the LBA corresponding to the write data, is written to the write target block.

[0143] When the target block is completely filled with data, it is managed by the active block list 34. Then, a free block is selected again from the free block list 33. After the selected free block is erased, it is allocated as the new target block.

[0144] When performing garbage collection on the NAND flash memory 5, a free block is selected from the free block list 33. The selected free block is then allocated as a copy target block after an erase operation is performed. If a copy target block has already been allocated, there is no need to allocate the free block as a copy target block.

[0145] Additionally, a replication source block is selected from the active blocks in the active block list 34. Then, based on the valid sector mapping corresponding to the selected replication source block, valid data and the LBA corresponding to that valid data are copied from the replication source block to the replication target block. In this case, valid data and the LBA corresponding to that valid data are read from the replication source block, and the read valid data and LBA are written to the replication target block.

[0146] When the copying of all valid data and all LBAs corresponding to the valid data within the source block is complete, the source block is managed as a free block through the free block list 33. Furthermore, the source block that becomes a free block can be reused for data writing.

[0147] In addition, when the target block to be copied is completely filled with data, the target block to be copied is managed as an active block through the active block list 34.

[0148] Next, the data writing action performed in response to the write request from host 2 will be described. Figure 11 This diagram illustrates an example of a data write operation performed in the SSD3 of the implementation when a write request is received from host 2.

[0149] exist Figure 11 In this case, assume that a write request specifying LBA11 and size (=4) is received from host 2. The write control unit 121, for example, allocates block BLK1 as the write target block.

[0150] The write control unit 121 writes 16 KiB of data associated with the write request and four LBAs (11 to 14) to page P0 within block BLK1. In this case, the first 4 KiB of the 16 KiB data associated with the write request and LBA11 are written to the initial storage location of page P0 within block BLK1. At the second storage location of page P0 within block BLK1, the second 4 KiB of the 16 KiB data and LBA12 are written. At the third storage location of page P0 within block BLK1, the third 4 KiB of the 16 KiB data and LBA13 are written. At the fourth storage location of page P0 within block BLK1, the fourth 4 KiB of the 16 KiB data and LBA14 are written.

[0151] Figure 12 It means corresponding to Figure 11 The diagram shows the action of updating L2P table 31 as a result of the data writing action.

[0152] The control unit 121 is written to update the L2P table 31 by establishing associations between the four LBA11 to LBA14 and the four physical addresses PBA that store the four 4KiB data corresponding to the four LBA11 to LBA14 respectively.

[0153] In this case, the entry in L2P table 31 corresponding to LBA11 stores the physical address PBA(BLK1, offset +0) corresponding to LBA11. The physical address PBA(BLK1, offset +0) represents the initial storage location of page P0 within block BLK1, that is, the storage location where 4KiB of data corresponding to LBA11 was written.

[0154] The entry in L2P table 31 corresponding to LBA12 stores the physical address PBA(BLK1, offset + 1) corresponding to LBA12. The physical address PBA(BLK1, offset + 1) indicates the second storage location of page P0 within block BLK1, which is the storage location of the 4KiB data corresponding to LBA12.

[0155] The entry in L2P table 31 corresponding to LBA13 stores the physical address PBA(BLK1, offset + 2) corresponding to LBA13. The physical address PBA(BLK1, offset + 2) represents the third storage location of page P0 within block BLK1, that is, the storage location where 4KiB of data corresponding to LBA13 has been written.

[0156] The entry in L2P table 31 corresponding to LBA14 stores the physical address PBA(BLK1, offset + 3) corresponding to LBA14. The physical address PBA(BLK1, offset + 3) represents the fourth storage location of page P0 within block BLK1, that is, the storage location where 4KiB of data corresponding to LBA14 has been written.

[0157] Figure 13 It means corresponding to Figure 11 The diagram shows the action of updating the valid sector mapping performed in response to a data write operation.

[0158] The write control unit 121 first selects the valid sector mapping 32-1 corresponding to block BLK1. Starting from the beginning of the valid sector mapping 32-1, four valid data identifiers correspond to four storage locations within page P0 of block BLK1. The write control unit 121 updates these four valid data identifiers from the invalid value "0" to the valid value "1". Thus, the four 4KiB data bytes stored in the four storage locations within page P0 of block BLK1 become valid data.

[0159] Next, the action of writing and updating data in response to a write request from host 2 will be explained. Figure 14 This diagram illustrates an example of an update data write operation performed in the SSD3 of the implementation when a write request is received from host 2.

[0160] exist Figure 14 In the case where 16 KiB of data with an initial LBA of LBA51 is stored in the storage location corresponding to the offset of block BLK0 from +0 to +3, a write request with a specified LBA51 and size = 4 is received from host 2.

[0161] The currently allocated write target block is block BLK1. Four 4-kiB data blocks, corresponding to four LBA11 to LBA14, have already been written to page P0 of block BLK1. Therefore, the write control unit 121 writes 16-kiB of data associated with the write request and four LBA51 to LBA54 to page P1 of block BLK1.

[0162] In this scenario, at the initial storage location of page P1 within block BLK1, the first 4 KiB of data and LBA51 from the 16 KiB update data associated with the write request are written. At the second storage location of page P1 within block BLK1, the second 4 KiB of data and LBA52 from the 16 KiB update data are written. At the third storage location of page P1 within block BLK1, the third 4 KiB of data and LBA53 from the 16 KiB update data are written. At the fourth storage location of page P1 within block BLK1, the fourth 4 KiB of data and LBA54 from the 16 KiB update data are written.

[0163] Figure 15 It means corresponding to Figure 14 The diagram shows the action of updating L2P table 31 as an update data write action.

[0164] The control unit 121 is written to update the L2P table 31 by establishing associations between the four physical addresses PBA, which store four 4KiB data corresponding to the four LBA51 to LBA54, respectively.

[0165] That is, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA51 is updated from physical address PBA(BLK0, offset +0) to physical address PBA(BLK1, offset +4). Physical address PBA(BLK0, offset +0) represents the initial storage location of page P0 in block BLK0, that is, the storage location where the previous 4KiB of data corresponding to LBA51 is stored. Physical address PBA(BLK1, offset +4) represents the initial storage location of page P1 in block BLK1, that is, the storage location where the 4KiB of updated data corresponding to LBA51 has been written.

[0166] In the entry of L2P table 31 corresponding to LBA52, the physical address PBA stored is updated from physical address PBA(BLK0, offset + 1) to physical address PBA(BLK1, offset + 5). Physical address PBA(BLK0, offset + 1) represents the second storage location of page P0 within block BLK0, i.e., the storage location where the previous 4KiB of data corresponding to LBA52 is stored. Physical address PBA(BLK1, offset + 5) represents the second storage location of page P1 within block BLK1, i.e., the storage location where the 4KiB of updated data corresponding to LBA52 has been written.

[0167] Similarly, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA53 is updated from physical address PBA(BLK0, offset +2) to physical address PBA(BLK1, offset +6). Furthermore, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA54 is updated from physical address PBA(BLK0, offset +4) to physical address PBA(BLK1, offset +7).

[0168] Figure 16 It means corresponding to Figure 14 The diagram shows the action of updating the valid sector mapping performed by the update data write action.

[0169] The write control unit 121 first selects the valid sector mapping 32-0 corresponding to block BLK0. Starting from the beginning of the valid sector mapping 32-0, four valid data identifiers correspond to four storage locations within page P0 of block BLK0. The write control unit 121 updates these four valid data identifiers from the valid value "1" to the invalid value "0".

[0170] Next, the write control unit 121 selects the valid sector mapping 32-1 corresponding to block BLK1. The fifth to eighth valid data identifiers in the valid sector mapping 32-1 correspond to four storage locations in page P1 of block BLK1, respectively. The write control unit 121 updates these four valid data identifiers from the invalid value "0" to the valid value "1".

[0171] Figure 17 It is a diagram representing the state of each unwritten storage location within block BLK1 where data has been written.

[0172] exist Figure 17 The example illustrates the case where block BLK1 contains a total of 4 pages, meaning the total number of storage locations (sectors) in block BLK1 is 16. Within page P2 of block BLK1, four storage locations store four 4-kiB data units corresponding to LBA102 to LBA105. Similarly, within page P3 of block BLK1, four storage locations store four 4-kiB data units corresponding to LBA81 to LBA84.

[0173] Here, it is assumed that among the 16 4KiB data included in block BLK1, for example, the 4KiB data corresponding to LBA11, LBA13, LBA14, LBA81, LBA82, and LBA84 are valid data.

[0174] Next, the data structure for valid sector mapping 32 will be explained. Figure 18 It means Figure 17 The data configuration and related data within block BLK1 shown are as follows: Figure 17 The diagram shows an example of the data structure for mapping the effective sectors corresponding to block BLK1 to 32-1.

[0175] When the total number of storage locations (sectors) included in block BLK1 is 16, the valid sector mapping 32-1 corresponding to block BLK1 includes 16 valid data identifiers, i.e., 16-bit bit mapping flags, corresponding to the 16 storage locations in block BLK1 respectively.

[0176] When only the 4KiB data corresponding to LBA11, LBA13, LBA14, LBA81, LBA82, and LBA84 are valid data, the 16 valid data identifiers, i.e., the 16-bit bit mapping flags, represent "1011000000001101".

[0177] Next, the invalidation process will be explained. Figure 19 This diagram illustrates the invalidation process performed in the SSD3 of the implementation when an invalidation request (Trim instruction) specifying a certain logical address is received from host 2.

[0178] exist Figure 19 In this context, it is assumed that the host 2 receives a Trim instruction specifying LBA13 and size = 2.

[0179] The invalidation processing unit 124 first retrieves the physical address PBA(BLK1, offset +2) corresponding to LBA13 and the physical address PBA(BLK1, offset +3) corresponding to LBA14 from the L2P table 31. In this case, the invalidation processing unit 124 does not change the physical address PBA(BLK1, offset +2) to a magic number. The physical address PBA(BLK1, offset +2) is maintained in the entry in the L2P table 31 corresponding to LBA13. Similarly, the invalidation processing unit 124 does not change the physical address PBA(BLK1, offset +3) to a magic number. The physical address PBA(BLK1, offset +3) is maintained in the entry in the L2P table 31 corresponding to LBA14.

[0180] The physical address PBA(BLK1, offset + 2) represents the third storage location starting from the beginning within block BLK1. Therefore, the invalidation processing unit 124 updates the third valid data identifier starting from the beginning of the valid sector mapping 32-1 corresponding to block BLK1 from the valid value "1" to the invalid value "0".

[0181] The physical address PBA(BLK1, offset + 3) represents the fourth storage location starting from the beginning within block BLK1. Therefore, the invalidation processing unit 124 updates the fourth valid data identifier starting from the beginning of the valid sector mapping 32-1 corresponding to block BLK1 from the valid value "1" to the invalid value "0".

[0182] As a result, the data corresponding to LBA13 and LBA14 become invalid. However, physical addresses PBA(BLK1, offset +2) and PBA(BLK1, offset +3) are maintained in L2P table 31. Therefore, while the data corresponding to LBA13 and LBA14 exist in block BLK1, the data corresponding to LBA13 and LBA14 can be read normally from the NAND flash memory 5 according to the read request from host 2.

[0183] Figure 20This is a diagram illustrating the data readout operations performed in the SSD3 implementation. Figure 20 In this context, it is assumed that a request is made to read the data corresponding to LBA13, which has been invalidated by the Trim instruction.

[0184] Upon receiving a read request (read instruction) specifying LBA13 and size = 1 from host 2, read control unit 122 obtains the physical address PBA (BLK1, offset + 2) associated with LBA13 from L2P table 31 by referring to L2P table 31.

[0185] The physical address PBA(BLK1, offset + 2) represents the third storage location within page P0 of block BLK1. Therefore, the read control unit 122 reads the 4 KiB of data stored in the third storage location within page P0 of block BLK1, and the LBA (here, LBA13) corresponding to the 4 KiB of data.

[0186] In this case, for example, the read control unit 122 may first read four 4KiB data entries and four corresponding LBAs from page P0 of block BLK1. Then, the read control unit 122 may extract the 4KiB data entries stored in the third storage location within page P0 of block BLK1, and the corresponding LBA (here, LBA13) from the four 4KiB data entries and the four LBAs.

[0187] The LBA comparison processing unit 125 compares the LBA (LBA13 in this case) corresponding to the read 4KiB data with the LBA (LBA13 in this case) specified by the read request. If the LBA comparison processing unit 125 confirms that these LBAs are consistent with each other, the read control unit 122 sends the read 4KiB data to the host 2.

[0188] Next, the re-efficiency process will be explained. Figure 21 This diagram illustrates the revalidation process performed in the SSD3 of the implementation when a revalidation request (Urerim instruction) is received from host 2 to revalidate the data corresponding to the logical address specified by the invalidation request (Trim instruction).

[0189] exist Figure 21 In this context, it is assumed that the host 2 receives an Untrim instruction specifying LBA13 and size = 2.

[0190] The re-validation processing unit 126 first obtains the physical address PBA(BLK1, offset +2) corresponding to LBA13 and the physical address PBA(BLK1, offset +3) corresponding to LBA14 from L2P table 31 by referring to L2P table 31.

[0191] The physical address PBA(BLK1, offset + 2) represents the third storage location from the beginning within block BLK1. Therefore, the revalidation processing unit 126 updates the third valid data identifier from the beginning of the valid sector mapping 32-1 corresponding to block BLK1 from the invalid value "0" to the valid value "1". In the L2P table 31, the physical address PBA(BLK1, offset + 2) is maintained in the entry corresponding to LBA13. Therefore, it is not necessary to store the physical address PBA(BLK1, offset + 2) again in the entry corresponding to LBA13.

[0192] The physical address PBA(BLK1, offset + 3) represents the fourth storage location starting from the beginning within block BLK1. Therefore, the revalidation processing unit 126 updates the fourth valid data identifier starting from the beginning of the valid sector mapping 32-1 corresponding to block BLK1 from the invalid value "0" to the valid value "1". In the L2P table 31, the physical address PBA(BLK1, offset + 3) is maintained in the entry corresponding to LBA14. Therefore, it is not necessary to store the physical address PBA(BLK1, offset + 3) again in the entry corresponding to LBA14.

[0193] Next, the migration of the contents of the effective sector mapping 32 will be explained. Figure 22 It is a diagram that represents the data configuration within a block, the valid sector mapping corresponding to that block, the content of the valid sector mapping after the invalidation request has been processed, and the content of the valid sector mapping after the re-validation request has been processed.

[0194] exist Figure 22 The example illustrates the valid sector mapping 32-1 corresponding to block BLK1. For instance, it is assumed that among the 16 4KiB data included in block BLK1, only the 4KiB data corresponding to LBA11, LBA13, LBA14, LBA81, LBA82, and LBA84 are valid data.

[0195] In this case, the 16 valid data identifiers, i.e., the 16-bit bit mapping flags included in the valid sector mapping 32-1, represent "1011000000001101".

[0196] Upon receiving a Trim instruction specifying LBA13 and size = 2 from host 2, the valid data identifier corresponding to the third storage location within block BLK1 containing data corresponding to LBA13 is updated from "1" to "0". Furthermore, the valid data identifier corresponding to the fourth storage location within block BLK1 containing data corresponding to LBA14 is also updated from "1" to "0". As a result, the 16 valid data identifiers included in valid sector mapping 32-1 represent "1000000000001101".

[0197] When block BLK1 is selected as the source block for garbage collection, the data stored in four of the 16 storage locations within block BLK1 that are associated only with the valid data identifier "1" is copied as valid data to the target block.

[0198] Upon receiving an Untrim command specifying LBA13 and size = 2 from host 2, the valid data identifier corresponding to the third storage location within block BLK1 containing data corresponding to LBA13 is updated from "0" to "1". Furthermore, the valid data identifier corresponding to the fourth storage location within block BLK1 containing data corresponding to LBA14 is also updated from "0" to "1". As a result, the 16 valid data identifiers included in valid sector mapping 32-1 represent "1011000000001101".

[0199] Furthermore, after garbage collection is performed on block BLK1, if block BLK1 is reused as a write target block, it is possible that data corresponding to an LBA other than LBA13 will be newly written to the third storage location within block BLK1. Similarly, data corresponding to an LBA other than LBA14 may also be newly written to the fourth storage location within block BLK1.

[0200] In this case, the LBA read from the third storage location within block BLK1 is inconsistent with LBA13. Therefore, upon receiving an Untrim instruction specifying LBA13, the process of updating the valid data identifier corresponding to the third storage location within block BLK1 from "0" to "1" is not performed. Similarly, the LBA read from the fourth storage location within block BLK1 is also inconsistent with LBA14, so the process of updating the valid data identifier corresponding to the fourth storage location within block BLK1 from "0" to "1" is also not performed.

[0201] Next, the waste recycling process will be explained. Figure 23It is a diagram representing the garbage collection action of copying valid data and logical addresses from the source block to the target block based on the valid sector mapping 32 corresponding to the source block.

[0202] The GC control unit 123 selects a source block for replication from valid blocks. Additionally, the GC control unit 123 selects a target block for replication from free blocks. Figure 23 In the example, it is shown that in Figure 19 The text describes a scenario where, after invalidating the data corresponding to LBA13-LBA14 using the Trim command, block BLK1 was selected as the copy source block. Furthermore, in... Figure 23 In this block, block BLK100 is the block selected as the target block for replication.

[0203] The GC control unit 123 selects a valid sector mapping 32-1 corresponding to the source block BLK1. This valid sector mapping 32-1 is represented as "1000000000001101". Based on the valid sector mapping 32-1, the GC control unit 123 copies only the valid data and the LBA corresponding to the valid data from the source block BLK1 to the target block BLK100.

[0204] In the source block BLK1, the 4KiB data stored in the first storage location within page P0 of the source block BLK1, and the 34KiB data stored in the first, second, and fourth storage locations within page P3 of the source block BLK1, are valid data. Therefore, these 4KiB data and the corresponding 4 LBAs (LBA11, LBA81, LBA82, and LBA84) within the source block BLK1 are read from the source block BLK1. The read 4KiB data and 4 LBAs (LBA11, LBA81, LBA82, and LBA84) are then written to the 4 target storage locations within page P0 of the target block BLK100.

[0205] Figure 24 It means in Figure 23 The diagram shows the action of updating L2P table 31 performed in the garbage collection process.

[0206] The GC control unit 123 updates the L2P table 31 by establishing associations between the LBA11, LBA81, LBA82, and LBA84 corresponding to the four 4KiB data to be copied and the four physical addresses PBA representing the four copy target storage locations.

[0207] That is, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA11 is updated from physical address PBA(BLK1, offset +0) to physical address PBA(BLK100, offset +0). Physical address PBA(BLK100, offset +0) represents the initial storage location of page P0 within block BLK100, that is, the storage location where 4KiB of data corresponding to LBA11 was copied.

[0208] The physical address PBA stored in the entry of L2P table 31 corresponding to LBA81 is updated from physical address PBA(BLK1, offset +12) to physical address PBA(BLK100, offset +1). Physical address PBA(BLK100, offset +1) represents the second storage location of page P0 within block BLK100, that is, the storage location where 4KiB of data corresponding to LBA81 has been copied.

[0209] Similarly, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA82 is updated from physical address PBA(BLK1, offset +13) to physical address PBA(BLK100, offset +2). Additionally, the physical address PBA stored in the entry of L2P table 31 corresponding to LBA84 is updated from physical address PBA(BLK1, offset +15) to physical address PBA(BLK100, offset +3).

[0210] Figure 25 It means in Figure 23 The diagram shows the actions performed during garbage collection, including updating and copying the valid sector mappings corresponding to the source block and the target block.

[0211] The GC control unit 123 first selects a valid sector mapping 32-1 corresponding to the source block BLK1. The initial valid data identifier in the valid sector mapping 32-1 corresponds to the storage location (source storage location) at the beginning of the block BLK1 that stores the valid data to be copied (data corresponding to LBA11). The GC control unit 123 updates this valid data identifier from a valid value "1" to an invalid value "0".

[0212] The thirteenth valid data identifier, starting from the beginning of the valid sector mapping 32-1, corresponds to the thirteenth storage location (copy source storage location) starting from the beginning of block BLK1, which stores the copied valid data (data corresponding to LBA81). The GC control unit 123 updates this valid data identifier from the valid value "1" to the invalid value "0".

[0213] Similarly, the GC control unit 123 will update the fourteenth and sixteenth valid data identifiers from the beginning of the valid sector mapping 32-1 from the valid value "1" to the invalid value "0".

[0214] Next, the GC control unit 123 selects valid sector mappings 32-100 corresponding to the target block BLK100. Four valid data identifiers starting from the beginning of each valid sector mapping 32-100 correspond to four storage locations (target storage locations) within page P0 of the target block BLK100. The GC control unit 123 updates these four valid data identifiers from the invalid value "0" to the valid value "1".

[0215] Next, the action of reusing the copied source block that has already undergone garbage collection for data writing will be explained. Figure 26 It is a diagram that shows the action of reusing the copied source block in order to write data after all valid data and all logical addresses in the source block have been copied.

[0216] When the copying of the four valid data entries and the four corresponding LBAs from the source block BLK1 to the target block is completed, the source block BLK1 becomes a free block that does not contain valid data. Therefore, block BLK1 can be reused as a new write target block.

[0217] When block BLK1 is reused as a new write target block, firstly, an erase operation is performed on block BLK1. This erases all data within block BLK1. Then, data and its corresponding LBA are written to block BLK1.

[0218] For example, upon receiving a write request from host 2 specifying LBA61 and size (=4), the write control unit 121 writes 16 KiB of data associated with the write request and four LBAs (61 to 64) to page P0 within block BLK1. In this case, the first 4 KiB of data and LBA61 of the 16 KiB associated with the write request are written at the initial storage location of page P0 within block BLK1. At the second storage location of page P0 within block BLK1, the second 4 KiB of data and LBA62 are written. At the third storage location of page P0 within block BLK1, the third 4 KiB of data and LBA63 are written. At the fourth storage location of page P0 within block BLK1, the fourth 4 KiB of data and LBA64 are written.

[0219] Then, the write control unit 121 updates the L2P table 31 to associate the four physical addresses representing the four storage locations where the four 4KiB data were written with the four LBA61 to LBA64 respectively.

[0220] Figure 27 This is a diagram showing the actions performed when the logical address from which the data is read along with the physical address PBA obtained from L2P table 31 is inconsistent with the logical address specified by the read request.

[0221] exist Figure 27 In this case, we assume that after block BLK1 is reused as the target block for writing, a request is made to read the data corresponding to LBA13, which has been invalidated by the Trim instruction.

[0222] Upon receiving a read request (read instruction) specifying LBA13 and size = 1 from host 2, read control unit 122 obtains the physical address PBA (BLK1, offset + 2) associated with LBA13 from L2P table 31 by referring to L2P table 31.

[0223] The physical address PBA(BLK1, offset + 2) represents the third storage location within page P0 of block BLK1. Therefore, the read control unit 122 reads the 4 KiB of data stored in the third storage location within page P0 of block BLK1 and the LBA corresponding to the 4 KiB of data from block BLK1.

[0224] The third storage location within page P0 of block BLK1 contains LBA63 and 4KiB of data corresponding to LBA63.

[0225] The LBA comparison processing unit 125 compares the LBA (LBA63 in this case) corresponding to the 4 KiB data read from block BLK1 with the LBA (LBA13 in this case) specified by the read request. If the LBA comparison processing unit 125 confirms that these LBAs are inconsistent with each other, the read control unit 122 does not send the read 4 KiB data to the host 2.

[0226] In this case, the read control unit 122 may also notify the host 2 that the host 2 has requested data that does not exist in the SSD3. As a method for notifying the host 2 that the host 2 has requested data that does not exist in the SSD3, a method of sending an error code indicating that the host 2 has requested data that does not exist in the SSD3 to the host 2 may be used, or a method of sending data with a predetermined specific data pattern to the host 2 may be used.

[0227] Next, the data writing action, garbage collection action, invalidation processing, re-validation processing, and data reading action will be explained. Figure 28 This is a diagram showing the timing of data write operations, garbage collection operations, invalidation processing, re-validation processing, and data read operations performed in the SSD3 implementation.

[0228] exist Figure 28 In this context, wLBA and wData represent the LBA and data associated with the write request. wPBA represents the physical address PBA of the data to be written. fLBA represents the LBA that is written to the NAND flash memory along with the data.

[0229] rLBA and rData represent the LBA associated with the read request and the data to be read according to the read request. rPBA represents the physical address (PBA) of the data to be read.

[0230] sPBA represents the physical address PBA of the copy source storage location used as the GC source. dPBA represents the physical address PBA of the copy target storage location used as the GC destination.

[0231] tLBA represents the LBA specified by the Trim directive (Trim request). uLBA represents the LBA specified by the Untrim directive (Untrim request).

[0232] Upon receiving a write request from host 2, write control unit 121 determines the physical address wPBA of the data wData associated with the received write request to be written. Then, write control unit 121 writes wData and wLBA to the storage location in NAND flash memory 5 represented by physical address wPBA.

[0233] Furthermore, the write control unit 121 establishes an association between wPBA and wLBA by storing wPBA in the entry in the L2P table 31 corresponding to wLBA. The valid data identifier in the valid sector mapping 32 corresponding to the wPBA to which wData has been written is updated to "1".

[0234] Based on the valid sector mapping 32, the GC control unit 123 determines the physical address sPBA of each replication source storage location within the replication source block containing valid data. The GC control unit 123 reads the valid data and its fLBA from the determined physical address sPBA. Then, the GC control unit 123 copies the read valid data and the read fLBA to the replication target storage location within the replication target block represented by dPBA.

[0235] The GC control unit 123 updates the L2P table 31 in a manner that establishes an association between the dPBA and the read fLBA. The valid data identifier in the valid sector mapping 32 corresponding to the dPBA with copied valid data is updated to "1". In addition, the valid data identifier in the valid sector mapping 32 corresponding to the sPBA with stored valid data is updated to "0".

[0236] Upon receiving a Trim request for a specified tLBA from host 2, the PBA associated with the tLBA is retrieved from L2P table 31. The valid data identifier in the valid sector mapping 32 corresponding to the retrieved PBA is updated to "0".

[0237] Upon receiving an Untrim request for a specified uLBA from host 2, the PBA associated with the uLBA is retrieved from L2P table 31. The valid data identifier in the valid sector mapping 32 corresponding to the retrieved PBA is updated to "1".

[0238] Upon receiving a read request for a specified rLBA from host 2, the rPBA associated with the tLBA is retrieved from L2P table 31. Then, data and the corresponding fLBA are read from the NAND flash memory 5 at the storage location indicated by the rPBA. The LBA comparison processing unit 125 compares the fLBA read from the NAND flash memory 5 along with the data with the rLBA specified in the read request. If the fLBA matches the rLBA, the data read from the NAND flash memory 5 is sent to host 2 as rDATA. If the fLBA does not match the rLBA, the data read from the NAND flash memory 5 is not sent to host 2.

[0239] Next, the order of data writing actions will be explained. Figure 29 This is a flowchart showing the sequence of data write operations performed in the SSD3 implementation.

[0240] Upon receiving a write request from host 2 (Yes in step S101), controller 4 allocates one of the multiple blocks within NAND flash memory 5 as the write target block (step S102). If the write target block has already been allocated, the processing in step S102 is not required.

[0241] Controller 4 determines the storage location (write target location) within the write target block to which the write data associated with the received write request should be written (step S103). Controller 4 writes both the write data and the LBA corresponding to the write data to the write target location within the write target block (step S104).

[0242] Controller 4 updates L2P table 31 by associating the physical address PBA representing the write target location with the LBA. Controller 4 selects a valid sector mapping corresponding to the write target block (step S106). Controller 4 updates the selected valid sector mapping by updating the valid data identifier (bit mapping flag) in the valid sector mapping corresponding to the write target location within the write target block to a valid value (step S107).

[0243] Then, controller 4 sends a response to host 2 indicating the completion of the write request (step S108).

[0244] Next, the sequence of waste recycling actions will be explained. Figure 30 This is a flowchart showing the sequence of garbage collection actions performed in the SSD3 implementation.

[0245] Controller 4 determines whether the GC start condition is met (step S111). For example, if the number of remaining free blocks reaches a threshold, it can be determined that the GC start condition is met.

[0246] If the GC start condition is met (as in step S111), controller 4 selects a copy source block from the valid blocks (step S112). Controller 4 allocates a copy target block (step S113).

[0247] Controller 4 copies valid data and the corresponding LBA from the source block to the target block based on multiple valid data flags in the valid sector mapping corresponding to multiple storage locations included in the source block (step S114). Controller 4 then updates L2P table 31 in a manner that associates the physical address PBA representing the target storage location within the target block with the copied valid data to the LBA of the valid data (step S115).

[0248] Controller 4 selects a valid sector mapping corresponding to the target block to be copied. Controller 4 updates the selected valid sector mapping in such a way that the valid data identifier (bit mapping flag) in the valid sector mapping corresponding to the target storage location within the target block to be copied is updated to a value indicating a valid data (step S116).

[0249] Controller 4 selects a valid sector mapping corresponding to the source block. Controller 4 updates the selected valid sector mapping in such a way that the valid data identifier (bit mapping flag) in the valid sector mapping corresponding to the source storage location in the source block containing the copied valid data is updated to a value indicating invalidity (step S117).

[0250] Controller 4 determines whether the copying of all valid data in the source block is complete (step S118). Steps S114 to S117 are repeated until the process of copying all valid data in the source block from the source block to the target block is completed.

[0251] Next, the steps for invalidation processing will be explained. Figure 31 This is a flowchart illustrating the invalidation process performed in the SSD3 implementation.

[0252] If a Trim request is received from host 2 for an LBA that specifies data to be invalidated (step S121), controller 4 obtains the physical address PBA associated with the LBA specified by the received Trim request from L2P table 31 by referring to L2P table 31 (step S122).

[0253] Controller 4 selects a valid sector mapping corresponding to a block, including the storage location specified by the acquired physical address PBA (step S123).

[0254] The controller 4 updates the selected valid sector mapping without updating the L2P table 31, while maintaining the acquired physical address PBA in the L2P table 31 (step S124). In step S124, the controller 4 updates the selected valid sector mapping in such a way that the valid data identifier corresponding to the storage location represented by the acquired physical address PBA is updated to a value indicating invalidity.

[0255] Next, the sequence of data reading actions will be explained. Figure 32 This is a flowchart showing the sequence of data readout operations performed in the SSD3 implementation.

[0256] When a read request for an LBA containing data to be read is received from host 2 (in step S131), controller 4 obtains the physical address PBA associated with the LBA specified by the received read request from L2P table 31 by referring to L2P table 31 (in step S132).

[0257] The controller 4 reads data and LBA from the storage location in the NAND flash memory 5 represented by the acquired physical address PBA (step S133). The controller 4 compares the LBA specified by the received read request with the read LBA (step S134).

[0258] If the read LBA matches the LBA specified in the received read request (yes in step S135), the controller 4 sends the read data to the host 2 (step S136). Then, the controller 4 sends a response to the host 2 indicating the completion of the read request (step S137).

[0259] If the LBA read is inconsistent with the LBA specified by the received read request (No in step S135), the controller 4 notifies the host 2 that the read object data corresponding to the LBA specified by the read request does not exist in the SSD 3 (step S138). In step S138, the read data is not sent to the host 2.

[0260] Next, the re-efficiency process will be explained. Figure 33 This is a flowchart illustrating the steps of the re-validation process performed in the SSD3 implementation.

[0261] If an Untrim request is received from host 2 specifying the LBA corresponding to the data to be revalidated (step S141), controller 4 obtains the physical address PBA associated with the LBA specified by the received Untrim request from L2P table 31 by referring to L2P table 31 (step S142).

[0262] The controller 4 reads the data and LBA from the storage location in the NAND flash memory 5 represented by the acquired physical address PBA (step S143). The controller 4 compares the LBA specified by the received Untrim request with the read LBA (step S144).

[0263] If the read LBA matches the LBA specified by the received Untrim request (Yes in step S145), the controller 4 selects a valid sector mapping corresponding to the block, including the storage location represented by the acquired physical address PBA (step S146).

[0264] The controller 4 updates the selected valid sector mapping so that the valid data identifier (bit mapping flag) corresponding to the storage location represented by the obtained physical address PBA is updated to a valid value (step S147).

[0265] If the LBA read is inconsistent with the LBA specified by the received Untrim request (No in step S145), the controller 4 does not update the selected valid sector mapping, but sends an error to the host 2 (step S146).

[0266] As explained above, according to this embodiment, during the data writing operation, both data and LBA (Local Basic Architecture) are written to the block. Therefore, during the garbage collection operation, the controller 4 can easily determine the LBA corresponding to the valid data copied from the copy source block to the copy target block based on the LBA stored in the copy source block along with the data. As a result, the controller 4 can easily associate the LBA corresponding to the copied valid data with the physical address representing the copy target storage location within the copy target block where the copied valid data was stored. The copy source block that has undergone garbage collection can be reused as a write target block.

[0267] Upon receiving an invalidation request (Trim instruction) from host 2, controller 4 retrieves the physical address representing the storage location containing data corresponding to the LBA specified by the invalidation request from L2P table 31. Then, while maintaining the retrieved physical address in L2P table 31, controller 4 updates the valid data identifier in valid sector mapping 32 corresponding to the storage location represented by the retrieved physical address to a value indicating invalidity.

[0268] As a result, data stored at the storage location represented by the obtained physical address will be treated as invalid data. Therefore, when a block including this storage location is selected as a replication source block for garbage collection, data stored at this storage location can be excluded from the replication object, thereby reducing write amplification.

[0269] In L2P table 31, the physical address corresponding to the LBA specified in the invalidation request remains undeleted. Therefore, even if host 2 erroneously issues an invalidation request specifying a certain LBA, it can still obtain the physical address corresponding to the LBA specified in the invalidation request from L2P table 31.

[0270] Therefore, even if host 2 issues an invalidation request specifying a certain LBA, it can still perform garbage collection on the block that stores the data corresponding to that LBA, and read the data corresponding to that LBA from the block before the block is reused as a new write target block.

[0271] Therefore, the invalidation process of updating only the valid sector mapping 32 without updating the L2P table 31 can achieve an effect equivalent to the original purpose of the invalidation request of reducing write amplification, and can enable the reading of data corresponding to the LBA specified by the invalidation request to take place for a certain period of time.

[0272] In addition, as mentioned above, the physical address corresponding to the LBA specified by the invalidation request remains in L2P table 31, so there is no need to perform additional processing such as storing the physical address corresponding to the specified LBA to other memory areas.

[0273] Therefore, invalidation processing can be implemented even if host 2 erroneously issues an invalidation request without increasing the required memory resources.

[0274] Several embodiments of the present invention have been described, but these embodiments are given by way of example and are not intended to limit the scope of the invention. These new embodiments can be implemented in various other ways, and various omissions, substitutions, and updates can be made without departing from the spirit of the invention. These embodiments and their variations are included within the scope or spirit of the invention, and are included within the scope of the invention as described in the claims and its equivalents.

[0275] Explanation of reference numerals in the attached figures

[0276] 2… host, 3… SSD, 4… controller, 5… NAND flash memory, 121… write control unit, 122… read control unit, 123… GC control unit, 124… invalidation processing unit, 125… LBA comparison processing unit, 126… re-validation processing unit.

Claims

1. A storage system capable of connecting to a host, comprising: Including non-volatile memory in multiple blocks; and The controller is configured to use a management table to manage multiple valid data identifiers for each block. These multiple valid data identifiers correspond to multiple storage locations included in each of the multiple blocks, and each valid data identifier indicates whether the data stored in its corresponding storage location is valid or invalid. The controller is further configured as follows: In response to receiving a write request for a specified first logical address from the host, the first data associated with the write request and the first logical address are written into the first block, so as to update the logical physical address translation table by associating the first physical address representing the first storage location in the first block where the first data has been written with the first logical address, and update the first valid data identifier in the management table corresponding to the first storage location in the first block with a valid value. In response to receiving an invalidation request from the host to invalidate the first data corresponding to the first logical address, the first physical address associated with the first logical address is obtained from the logical physical address translation table. While maintaining the obtained first physical address in the logical physical address translation table, the first valid data identifier in the management table corresponding to the first storage location in the first block represented by the obtained first physical address is updated to a value indicating invalidity. When performing garbage collection on the non-volatile memory, a copy source block for the garbage collection is selected from the plurality of blocks. Based on the plurality of second valid data identifiers in the management table corresponding to the plurality of storage locations within the copy source block, both valid data and the logical address corresponding to the valid data are copied from the copy source block to the copy target block. The logical physical address translation table is updated in such a way that the physical address representing the copy target storage location within the copy target block where the valid data has been copied is associated with the logical address of the valid data. The third valid data identifier in the management table corresponding to the copy source storage location within the copy source block where the valid data is stored is updated to an invalid value. The fourth valid data identifier in the management table corresponding to the copy target storage location within the copy target block is updated to a valid value. In response to receiving a revalidation request from the host to revalidate the first data corresponding to the first logical address, the system obtains the first physical address associated with the first logical address from the logical physical address translation table. Based on the obtained first physical address, it reads the logical address of the first storage location within the first block represented by the obtained first physical address, which is stored together with the data. It then determines whether the read logical address is consistent with the first logical address specified by the revalidation request. If the read logical address is consistent with the first logical address, the system updates the first valid data identifier corresponding to the first storage location within the first block represented by the obtained first physical address to a valid value. If the read logical address is inconsistent with the first logical address, the system notifies the host of an error.

2. The storage system according to claim 1, wherein, The controller is further configured as follows: In response to receiving a read request specifying the first logical address from the host, the system obtains the first physical address associated with the first logical address from the logical physical address translation table, reads the data stored in the first storage location within the first block represented by the obtained first physical address and the logical address corresponding to the data from the first block, and sends the read data to the host if the read logical address matches the first logical address specified by the read request, and does not send the read data to the host if the read logical address does not match the first logical address specified by the read request.

3. The storage system according to claim 1 or 2, wherein, The controller is further configured as follows: If the logical address read is inconsistent with the first logical address specified by the revalidation request, the first valid data identifier is not updated to the value indicating validity, and the error is notified to the host.

4. The storage system according to claim 1, wherein, The controller is further configured as follows: Upon receiving the invalidation request from the host, the first valid data identifier is updated to a value indicating invalidity, but the entry in the logical physical address translation table corresponding to the first logical address is not changed from the first physical address to the value indicating invalidity.

5. A control method for controlling a non-volatile memory comprising multiple blocks, the control method comprising the following steps: The management table is used to manage multiple valid data identifiers for each block. These multiple valid data identifiers are valid data identifiers that correspond to multiple storage locations included in each block. Each of these multiple valid data identifiers indicates whether the data stored in the corresponding storage location is valid or invalid. In response to receiving a write request specifying a first logical address from the host, The first data associated with the write request and the first logical address are written into the first block. The logical physical address translation table is updated in such a way that an association is established between the first physical address, which represents the first storage location within the first block where the first data has been written, and the first logical address. Update the first valid data identifier in the management table corresponding to the first storage location in the first block to a value indicating validity. In response to receiving an invalidation request from the host for invalidating the first data corresponding to the first logical address, Obtain the first physical address associated with the first logical address from the logical physical address translation table. While maintaining the obtained first physical address in the logical physical address translation table, the first valid data identifier in the management table corresponding to the first storage location in the first block represented by the obtained first physical address is updated to a value indicating invalidity. In the case of performing garbage collection on the non-volatile memory, Select a copy source block from the plurality of blocks for the garbage collection. Based on multiple second valid data identifiers in the management table corresponding to multiple storage locations within the source block, both valid data and the logical address corresponding to the valid data are copied from the source block to the target block. The logical physical address translation table is updated in a manner that establishes an association between the physical address representing the copy target storage location within the copy target block containing the copied valid data and the logical address of the valid data. Update the third valid data identifier in the management table corresponding to the replication source storage location within the replication source block that stores the valid data to a value indicating invalidity. Update the fourth valid data identifier in the management table corresponding to the storage location of the copy target within the copy target block to a valid value. In response to receiving a revalidation request from the host for revalidating the first data corresponding to the first logical address, Obtain the first physical address associated with the first logical address from the logical physical address translation table. Based on the obtained first physical address, the logical address of the first storage location within the first block represented by the obtained first physical address, which is stored together with the data, is read from the first block. Determine whether the logical address read out matches the first logical address specified by the revalidation request. If the read logical address matches the first logical address, the first valid data identifier corresponding to the first storage location within the first block represented by the obtained first physical address is updated to a valid value. If the read logical address is inconsistent with the first logical address, an error is notified to the host.

6. The control method according to claim 5, wherein, It also includes the following steps: In response to receiving a read request specifying the first logical address from the host, Obtain the first physical address associated with the first logical address from the logical physical address translation table. Read from the first block the data stored at the first storage location within the first block represented by the first physical address and the logical address corresponding to the data. If the read logical address matches the first logical address specified by the read request, the read data is sent to the host. If the logical address read is inconsistent with the first logical address specified by the read request, the read data will not be sent to the host.

7. The control method according to claim 5 or 6, wherein, The notification includes notifying the host of the error if the read logical address is inconsistent with the first logical address specified by the revalidation request, without updating the first valid data identifier to the value indicating validity.

8. The control method according to claim 5, wherein, It also includes the following steps: The update of the first valid data identifier includes, upon receiving the invalidation request from the host, updating the first valid data identifier to a value indicating invalidity, without changing the entry in the logical physical address translation table corresponding to the first logical address from the first physical address to the value indicating invalidity.

Images