Enhanced end-to-end protection in key value storage devices

Abstract

The key value (KV) pair data includes a key and a value, where the key addresses the value. The value can include one or more flash memory management units (FMUs). Since the value is read in order from one FMU to the next, end-to-end (E2E) protection of the value can be optimized and improved. The E2E protection can include using a checksum signature in which a cyclic redundancy code (CRC) signature is only one example to ensure that corrupted data is not returned to a host device. Optimizing a checksum signature for protecting the value can include generating an aggregated checksum signature for each FMU based on a current FMU and each previous FMU of the value, or generating only a single checksum signature for the entire value. Thus, the characteristics of this value can be utilized in order to improve and optimize E2E protection.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of the entire content of U.S. Non - provisional Application No. 18 / 359,167, titled "ENHANCED END TO END PROTECTION IN KEY VALUE STORAGE DEVICES", filed on July 26, 2023, with the United States Patent and Trademark Office, and incorporates it herein by reference for all purposes. Background of the Invention Field of the Invention

[0003] Embodiments of the present disclosure generally relate to data storage devices such as solid - state drives (SSDs), and more particularly to improving end - to - end (E2E) protection for key - value (KV) data storage devices.

[0004] Description of Related Technologies

[0005] KV databases work by storing a certain amount of user data associated with keys that can be addressed as complete entities. Examples of user data that can be stored in a KV database can include photos, records, and files. From the perspective of a host device, a photo, record, or file can be retrieved using a single key / address rather than using multiple addresses for the data that includes the photo, record, or file. The data is stored as unstructured data and can be addressed using variable - length keys. Storage space in a memory device can be allocated for KV - pair data in increments of bytes, where the length value of the KV - pair data is associated with the storage space required to store the KV - pair data.

[0006] Using a KV database in a data storage device can increase the performance of the data storage device. For example, the number of data transfers per second can be improved because the KV - pair data to the physical storage location translation layer in the host device can be removed. Additionally, the number of commands on the bus can be reduced because the entire KV - pair data can be transferred in a single transmission. End - to - end (E2E) protection of data is crucial because data integrity is one of the most important requirements of a data storage device, and this data integrity requirement has a very low probability of undetected data corruption. However, E2E protection for KV - pair data is generated for each FMU of the value without any optimization or awareness of the structure of the KV - pair data.

[0007] Accordingly, there is a need in the art for improved and optimized E2E protection for KV - pair data. Summary of the Invention

[0008] The present disclosure generally relates to data storage devices such as solid state drives (SSDs), and more particularly to improving end-to-end (E2E) protection for key-value (KV) data storage devices. A KV pair of data includes a key and a value, where the key addresses the value. The value can include one or more flash memory management units (FMUs). Since the value is read sequentially from one FMU to the next FMU, E2E protection for the value can be optimized and improved. E2E protection can include using a checksum signature to ensure that corrupted data is not returned to the host device. Optimizing the checksum signature used to protect the value can include generating an aggregated checksum signature for each FMU based on the current FMU of the value and each previous FMU, or generating only a single checksum signature for the entire value. Thus, the characteristics of the value can be utilized to improve and optimize E2E protection.

[0009] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to receive key-value (KV) pair data from a host device, where the KV pair data includes a key and a value, where the key addresses the value, and where the value includes two or more flash memory management units (FMUs); generate a first checksum signature for the received value, where the first checksum signature is generated for an aggregated number of consecutive adjacent FMUs of the value; and program the generated first checksum signature and the value to the memory device.

[0010] In another embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to generate a checksum signature for a value of key-value (KV) pair data. The KV pair data includes a key and a value. The key addresses the value. The value includes two or more flash memory management units (FMUs). A checksum signature is generated for a first FMU and every two or more consecutive adjacent FMUs after the first FMU.

[0011] In another embodiment, a data storage device includes means for storing data and a controller coupled to the means for storing data. The controller is configured to generate a checksum signature for each flash memory management unit (FMU) of a value of a key-value (KV) pair data, where the KV pair data includes a key and a value, where the key addresses the value, where the value includes a plurality of FMUs, and where the checksum signature generated for each FMU among the plurality of FMUs other than the first FMU is associated with the current FMU and each previous FMU among the plurality of FMUs; program the value and each checksum signature into the means for storing data; receive a read request including a key from a host device; retrieve the value and the checksum signature associated with the FMU requested by the read request from the means for storing data; generate another checksum signature for the retrieved value, where the another checksum signature is associated with the requested FMU and each previous FMU relative to the requested FMU; determine that the another checksum signature matches the retrieved checksum signature; and provide the value to the host device. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] To understand the above features of the present disclosure in detail, the present disclosure briefly outlined above may be described in more detail by referring to embodiments, some of which are shown in the drawings. However, it should be noted that the drawings only show typical embodiments of the present disclosure and should not be considered as limiting the scope of the present disclosure, as the present disclosure may allow other equivalent embodiments.

[0013] Figure 1 is a schematic block diagram showing a storage system in which a data storage device can be used as a storage device of a host device according to some embodiments.

[0014] Figure 2 is a diagram of a memory device according to some embodiments.

[0015] Figure 3A is an exemplary illustration of KV pair data according to some embodiments.

[0016] Figure 3B is a table showing a command set for a KV database according to some embodiments.

[0017] Figures 4A to 4C is an exemplary illustration of a value stored in a memory device according to some embodiments.

[0018] Figure 5 is a flowchart showing a method for protecting a value using an exemplary checksum signature, a cyclic redundancy code (CRC) signature according to some embodiments.

[0019] Figure 6is a flowchart showing a method of protecting a value using an exemplary checksum signature, a cyclic redundancy code (CRC) signature according to certain embodiments.

[0020] Figure 7 is a flowchart showing a method of protecting a value using an exemplary checksum signature, a cyclic redundancy code (CRC) signature according to certain embodiments.

[0021] Figure 8 is a flowchart showing a method of protecting a value using an exemplary checksum signature, a cyclic redundancy code (CRC) signature according to certain embodiments.

[0022] For ease of understanding, where possible, the same reference numerals are used to denote the same elements common to the drawings. It is contemplated that elements disclosed in one embodiment can be beneficially utilized in other embodiments without specific recitation. DETAILED DESCRIPTION

[0023] In the following, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the following features and elements, whether or not relating to different embodiments, is contemplated for implementing and practicing the present disclosure. Moreover, although embodiments of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the present disclosure. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not to be considered elements or limitations of the appended claims unless expressly recited therein. Similarly, references to "the present disclosure" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered an element or limitation of the appended claims unless expressly recited therein.

[0024] The present disclosure generally relates to data storage devices such as solid state drives (SSDs), and more particularly to improving end-to-end (E2E) protection of key-value (KV) data storage devices. KV pairs of data include a key and a value, where the key addresses the value. The value can include one or more flash management units (FMUs). Since the value is read sequentially from one FMU to the next FMU in order, E2E protection of the value can be optimized and improved. E2E protection can include using a checksum signature to ensure that corrupted data is not returned to the host device, where a cyclic redundancy code (CRC) signature is only one example. Optimizing the checksum signature used to protect the value can include generating an aggregated checksum signature for each FMU based on the current FMU of the value and each previous FMU, or generating only a single checksum signature for the entire value. Thus, the characteristics of the value can be utilized to improve and optimize E2E protection.

[0025] Figure 1 FIG. 1 is a schematic block diagram of a storage system 100 having a data storage device 106 that can be used as a storage device for a host device 104, according to some embodiments. For example, the host device 104 can utilize non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes host DRAM 138. In some examples, the storage system 100 can include multiple storage devices that can operate as a storage array, such as the data storage device 106. For example, the storage system 100 can include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID), which together serve as a mass storage device for the host device 104.

[0026] The host device 104 can store data to and / or retrieve data from one or more storage devices, such as the data storage device 106. As Figure 1 shown, the host device 104 can communicate with the data storage device 106 via an interface 114. The host device 104 can include any of a wide range of devices, including: computer servers, network-attached storage (NAS) units, desktop computers, notebooks (i.e., laptops) computers, tablets, set-top boxes, telephone handsets (such as so-called "smart" phones, so-called "smart" tablets), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending or receiving data from a data storage device.

[0027] The host DRAM 138 can optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 that is allocated to the data storage device 106 for exclusive use by the controller 108 of the data storage device 106. For example, the controller 108 can store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, etc. in the HMB 150. In other words, the HMB 150 can be used by the controller 108 to store data that would typically be stored in volatile memory 112, buffer 116, internal memory of the controller 108 such as static random access memory (SRAM), etc. In an example where the data storage device 106 does not include DRAM (i.e., optional DRAM 118), the controller 108 can utilize the HMB 150 as the DRAM of the data storage device 106.

[0028] The data storage device 106 includes a controller 108, an NVM 110, a power supply 111, a volatile memory 112, an interface 114, a write buffer 116, and an optional DRAM 118. In some examples, the data storage device 106 may include additional components that are not shown in Figure 1 for clarity. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed circuit board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some example standard form factors include, but are not limited to, 3.5-inch data storage devices (e.g., HDD or SSD), 2.5-inch data storage devices, 1.8-inch data storage devices, Peripheral Component Interconnect (PCI), Extended PCI (PCI-X), Express PCI (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, Mini PCI, etc.). In some examples, the data storage device 106 may be directly coupled (e.g., directly soldered or inserted into a connector) to the motherboard of the host device 104.

[0029] The interface 114 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface eXtension (CCIX), Open Channel SSD (OCSSD), etc. The interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to the controller 108, providing an electrical connection between the host device 104 and the controller 108, enabling data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of the interface 114 may also allow the data storage device 106 to receive power from the host device 104. For example, as Figure 1 shown, the power supply 111 may receive power from the host device 104 via the interface 114.

[0030] The NVM 110 may include multiple memory devices or memory cells. The NVM 110 may be configured to store and / or retrieve data. For example, the memory cells of the NVM 110 may receive data and a message indicating that the memory cell stores the data from the controller 108. Similarly, the memory cell may receive a message from the controller 108 indicating that the memory cell retrieves data. In some examples, each of the memory cells may be referred to as a die. In some examples, the NVM 110 may include multiple dies (i.e., multiple memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).

[0031] In some examples, each memory cell may include any type of non-volatile memory device such as: flash memory devices, phase change memory (PCM) devices, resistive random access memory (ReRAM) devices, magnetoresistive random access memory (MRAM) devices, ferroelectric random access memory (F-RAM), holographic memory devices, and any other type of non-volatile memory device.

[0032] The NVM 110 may include multiple flash memory devices or memory cells. The NVM flash memory devices may include NAND or NOR-based flash memory devices and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In the NVM flash memory devices, the flash memory devices may be divided into multiple dies, where each of the multiple dies includes multiple physical blocks or logical blocks, and the multiple physical blocks or logical blocks may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of the NVM cells may be electrically connected using word lines to define the pages among the multiple pages. The corresponding cells in each of the multiple pages may be electrically connected to corresponding bit lines. In addition, the NVM flash memory devices may be 2D or 3D devices and may be single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), or quad-level cell (QLC). It should be understood that the listed memory architectures are not intended to be limiting, but rather provide examples of possible implementations. For example, it is envisioned that memories with more levels of cells may be applicable, such as five-level cell (PLC) memories, etc. (e.g., 6-level cells, 7-level cells, etc.). The controller 108 may write data to and read data from the NVM flash memory devices at the page level and erase data from the NVM flash memory devices at the block level.

[0033] Power supply 111 can supply power to one or more components of data storage device 106. When operating in standard mode, power supply 111 can use power provided by an external device such as host device 104 to supply power to one or a component. For example, power supply 111 can use power received from host device 104 via interface 114 to supply power to one or more components. In some examples, power supply 111 can include one or more power storage components, which are configured to supply power to one or more components when operating in shutdown mode, such as in the case of stopping receiving power from an external device. In this way, power supply 111 can be used as an on-vehicle backup power source. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of electric power that can be stored by one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of one or more power storage components. In other words, as the amount of electric power stored by one or more power storage components increases, the cost and / or size of one or more power storage components also increase.

[0034] Controller 108 can use volatile memory 112 to store information. Volatile memory 112 can include one or more volatile memory devices. In some examples, controller 108 can use volatile memory 112 as a cache. For example, before the information in the cache is written to NVM 110, controller 108 can store the information in the cache in volatile memory 112. As Figure 1 shown, volatile memory 112 can consume the power received from power supply 111. Examples of volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)), pseudo SRAM (PSRAM), block RAM (BRAM), thyristor RAM (TRAM), accelerator RAM (XRAM), etc. Similarly, optional DRAM 118 can be used to store mapping data, buffered commands, logical to physical (L2P) tables, metadata, cached data, etc. in optional DRAM 118. In some examples, data storage device 106 does not include optional DRAM 118, such that data storage device 106 is DRAM-less. In other examples, data storage device 106 includes optional DRAM 118.

[0035] The controller 108 can manage one or more operations of the data storage device 106. For example, the controller 108 can manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 can initiate a data storage command to store data in the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data in an internal memory or a write buffer 116 before sending the data associated with the write command to the NVM 110.

[0036] The controller 108 can include an optional second volatile memory 120. The optional second volatile memory 120 can be similar to the volatile memory 112. For example, the optional second volatile memory 120 can be SRAM. The controller 108 can allocate a portion of the optional second volatile memory 120 to the host device 104 as a controller memory buffer (CMB) 122. The CMB 122 can be directly accessed by the host device 104. For example, the host device 104 can utilize the CMB 122 to store one or more submission queues that are typically maintained in the host device 104 instead of maintaining the one or more submission queues in the host device 104. In other words, the host device 104 can generate commands and store the generated commands with or without associated data in the CMB 122, where the controller 108 accesses the CMB 122 to retrieve the stored generated commands and / or associated data.

[0037] Figure 2 is a diagram of a memory device 200 according to certain embodiments. The memory device 200 can be Figure 1 the NVM 110. The memory device 200 includes a plurality of dies 202a - 202n, collectively referred to as dies 202, where each die in the plurality of dies 202a - 202n includes a first plane 204a and a second plane 204b, collectively referred to as planes 204. Each plane in the planes 204 includes a plurality of blocks 206a - 206n, collectively referred to as blocks 206. Although 32 dies 202 are shown in the memory device 200, any number of dies can be included.

[0038] Figure 3Ais an exemplary illustration of KV - pair data 300 according to some embodiments. The KV - pair data 300 includes a key 302 and a value 304, where the data of the value 304 (which may be host data) is addressed by the key 302. The key 302 may have a size of approximately 1 byte to approximately 64 bytes, and the value 304 may have a size of approximately 0 bytes to approximately 2 32 - 1 byte. For example, when the value 304 has a size of approximately 0 bytes, the value 304 is a null value. It should be understood that the values mentioned above are not intended to be limiting, but rather provide examples of embodiments. Since the value 304 can have a size greater than the physical word line (e.g., greater than 16 KB), the value 304 can be divided across several word lines and can result in misalignment. Misalignment can occur when partial data from multiple values is stored in a single word line or when a portion of the value 304 is partially stored on a single word line. Since misalignment of the stored data can result in multiple reads, the quality of service of a data storage device storing misaligned data can be reduced, and the power consumption of the data storage device can be increased.

[0039] Figure 3B is Table 350 showing a command set for a KV database according to some embodiments. For illustrative purposes, aspects of the storage system 100 of Figure 1 may be referred to herein. The KV system may include a command set that, in a non - restrictive list, includes a delete command, a list command, a retrieve command, an exists command, and a store command. The delete command may cause the controller 108 to delete the key 302 and the value 304 associated with the key 302. The list command may cause the controller 108 to list the keys present in the KV namespace starting with a specified key. The exists command may cause the controller 108 to return to a command generator such as the host device 104 a status indicating whether KV - pair data 300 exists for a specified key. The store command may cause the controller 108 to store the KV - pair data into the KV namespace.

[0040] The retrieve command may cause the controller 108 to retrieve the value 304 associated with a specified key from the KV namespace. The length of the KV - pair data 300 to be retrieved is specified in the retrieve command, and the location for transferring the KV - pair data 300 is specified by a scatter - gather list (SGL) pointer or a physical region page (PRP) pointer in the retrieve command. If the specified length in the retrieve command is less than the length of the KV - pair data 300 being retrieved, the controller 108 returns the requested amount and the length of the KV - pair data 300 to the completion queue. However, if the specified length in the retrieve command is greater than the length of the KV - pair data 300 being retrieved, the controller 108 returns the data from the NVM 110, and the length of the KV - pair data 300 is returned to the completion queue.

[0041] Figures 4A to 4Cis an exemplary illustration of different embodiments that store values (e.g., value 400, value 430, and value 460) in a memory device such as a memory device 200 of Figure 2 For exemplary purposes, aspects of the storage system 100 of Figure 1 may be referred to herein. The values 400, 430, 460 may be the values 304 of the KV pair data 300 of FIG. 3. The values 400, 430, 460 include a plurality of flash memory management units (FMUs) 402a - 402n, 432a - 432n, 462a - 462n. Each FMU of the plurality of FMUs 402a - 402n, 432a - 432n, 462a - 462n may have a size of approximately 4KB. It should be understood that the described embodiments are not intended to be limiting, but rather provide examples of possible embodiments.

[0042] When the controller 108 receives the values 400, 430, 460, the controller 108 may generate a checksum signature for each of the FMUs 402a - 402n, 432a - 432n, 462a - 462n, where the cyclic redundancy code (CRC) signature is only one example (e.g., CRC signatures 404a - 404n, 434a - 434n, 464n). It should be understood that although the CRC signature is illustrated as the checksum signature in Figures 4A to 4C the checksum signature is not limited to the CRC signature. Instead, other checksum signatures are envisioned. The CRC signature is only for illustrative purposes. In other words, each FMU is associated with a checksum signature. The checksum signature can be used to ensure that the data requested by the host device 104 is returned to the host device 104 without corruption. When the checksum signature and the requested data are read back from the NVM 110, another checksum signature is generated based on the requested data read from the NVM 110. The checksum signature for the data read from the NVM 110 is compared with the other checksum signature (generated based on the requested data read from the NVM 110). If the checksum signatures match, the requested data is sent back to the host device 104. However, if the checksum signatures do not match, a read failure indicating that the data has been corrupted may be sent back to the host device 104.

[0043] The value 400 shows an example where the checksum signature associated with the corresponding FMU is programmed together with the corresponding FMU. For example, when programming the value 400 into the NVM 110, the first FMU 402a is programmed first, then the first CRC signature 404a is programmed after the first FMU 402a, and then the second FMU 402b is programmed after the first CRC signature 404a, and so on. The value 430 shows an example where the checksum signature associated with the FMU of the value 430 is programmed after programming the FMU of the value 430 into the NVM 110. For example, the FMUs 432a - 432n are programmed into the NVM 110, and then after the FMUs 432a - 432n are programmed into the NVM 110, the CRC signatures 434a - 434n are programmed. In addition, the CRC signatures 434a - 434n are programmed in the order of the FMUs 432a - 432n to ensure read consistency when reading the value 430 from the NVM 110. It should be understood that the CRC signatures 434a - 434n can be programmed to the same location as the FMUs 432a - 432n or to a different location from the FMUs 432a - 432n (including different memory devices). The value 460 shows an example where the CRC signature 464n associated with all the FMUs of the value 460 is programmed together with the last FMU 462n of the value 460.

[0044] Reference Figure 4A and Figure 4B , the CRC signatures 404b - 404n, 434b - 434n can be associated with two or more consecutive adjacent FMUs. In other words, the checksum signature can be associated with the current FMU (i.e., the FMU for which the checksum is generated) and each previous adjacent FMU (i.e., the FMU of the value before the current FMU). For example, for the second FMUs 402b, 432b, the current FMU is the second FMU 402b, and the previous FMU is the first FMU 402a. Each of the generated checksum signatures can have a constant size or a variable size. In an example where each checksum signature is of variable size, each subsequent adjacent checksum signature (i.e., the second CRC signature 404b after the first CRC signature 404a) is larger than the previous checksum signature by a predetermined size. For example, if the first checksum signature has a size of approximately 16 bits, then the second checksum signature adjacent and immediately following the first checksum signature is 18 bits. In other words, the predetermined size can be 2 bits. It should be understood that the values listed above are not intended to be limiting, but rather provide examples of possible implementations.

[0045] In addition, when the host device 104 sends a read request for the values 400, 430, 460, the host device 104 can send the corresponding keys associated with the values 400, 430, 460 (e.g.,Figure 3A requests for a particular FMU that reads values 400, 430, 460. Instead of reading each FMU and determining whether each FMU has valid data or corrupted data (by using checksum signature comparison), only the corresponding checksum signature associated with the requested FMU is needed. In other words, if the nth FMU is requested, the corresponding value is read from the NVM 110, and the corresponding nth checksum signature associated with the nth FMU is compared with the generated checksum signature associated with the requested nth FMU.

[0046] Since each checksum signature is associated with the current FMU and each previous FMU, a longer codeword is achieved, and the overall error detection and correction capabilities of the corresponding values are stronger. In addition, since the checksum signature for the value can be selected to use only the last checksum signature, a constant-size checksum signature, or a variable-size checksum signature, the end-to-end (E2E) protection of the data within the data storage device 106 can be improved. In some examples, the amount of E2E checksum overhead can be reduced, which can allow more space for metadata and user data. In the case where only the last checksum signature is utilized, the additional space saved (by not having checksum signatures for each previous FMU from the last FMU of the value) can be used for error correction code (ECC) improvements, such as more complex and advanced checksum codes, additional header information, or user data.

[0047] Figure 5 is a flowchart showing a method 500 for protecting values using checksum signatures, in which the cyclic redundancy code (CRC) signature is only one example. Method 500 can be implemented by a controller (such as Figure 1 the controller 108). For illustrative purposes, aspects of the storage system 100 may be referred to herein.

[0048] At block 502, host device 104 sends a value to controller 108. The value is associated with a key. At block 504, controller 108 generates a first checksum signature for each FMU of the value. The generated first checksum signature is associated with the corresponding FMU of the value. At block 506, controller 108 programs the value and each first checksum signature of the first checksum signatures into NVM 110. At block 508, controller 108 receives a read request from host device 104 to read the value using the key. At block 510, controller 108 reads each first checksum signature and the value from NVM 110. At block 512, the controller generates a second checksum signature for each FMU of the value, where the second checksum signature is based on the FMUs read from NVM 110. At block 514, the controller compares the first checksum signature with the corresponding second checksum signature. At block 516, controller 108 sends a read failure message to host device 104 after determining that at least one comparison has failed.

[0049] Figure 6 is a flowchart showing a method 600 for protecting values using checksum signatures, in which a cyclic redundancy code (CRC) signature is only one example. Method 600 may be implemented by a controller (such as Figure 1 controller 108). For illustrative purposes, aspects of storage system 100 may be referred to herein.

[0050] At block 602, host device 104 sends a value to controller 108. The value is associated with a key. At block 604, controller 108 generates a first checksum signature for each FMU of the value. The generated first checksum signature is associated with the corresponding FMU of the value (i.e., the current FMU) and each previous FMU (i.e., each previous adjacent FMU of the current FMU). At block 606, controller 108 programs the value and the first checksum signature associated with the last FMU into NVM 110. At block 608, controller 108 receives a read request from host device 104 to read the value using the key. At block 610, controller 108 reads the first checksum signature associated with the last FMU and the value from NVM 110. At block 612, the controller generates a second checksum signature for the value, where the second checksum signature is based on each of the FMUs read from NVM 110. At block 614, the controller compares the first checksum signature with the second checksum signature. At block 616, controller 108 sends a read failure message to host device 104 after determining that the comparison has failed.

[0051] Figure 7is a flowchart showing method 700 for protecting values using a checksum signature, where a cyclic redundancy code (CRC) signature is just one example. Method 700 may be implemented by a controller (such as Figure 1 controller 108). For illustrative purposes, aspects of storage system 100 may be referred to herein.

[0052] At block 702, host device 104 sends a value to controller 108. The value is associated with a key. At block 704, controller 108 generates a first checksum signature for each FMU of the value, where each first checksum signature has a constant size. The generated first checksum signatures are associated with the corresponding FMU of the value (i.e., the current FMU) and each previous FMU (i.e., each previous adjacent FMU of the current FMU). At block 706, controller 108 programs the value and each first checksum signature into NVM 110. At block 708, controller 108 receives a read request from host device 104 to read the value using the key. At block 710, controller 108 reads each first checksum signature and the value from NVM 110. At block 712, the controller generates a second checksum signature for each FMU of the value, where the second checksum signature is based on the FMUs read from NVM 110. At block 714, the controller compares the first checksum signatures with the corresponding second checksum signatures. At block 716, controller 108 sends a read failure message to host device 104 after determining that at least one comparison has failed.

[0053] Figure 8 is a flowchart showing method 800 for protecting values using a checksum signature, where a cyclic redundancy code (CRC) signature is just one example. Method 800 may be implemented by a controller (such as Figure 1 controller 108). For illustrative purposes, aspects of storage system 100 may be referred to herein.

[0054] At block 802, host device 104 sends a value to controller 108. The value is associated with a key. At block 804, controller 108 generates a first checksum signature for each FMU of the value, where each first checksum signature has a variable size, and where each subsequent first checksum signature is a predetermined size larger than the previous first checksum signature. The generated first checksum signatures are associated with the corresponding FMU of the value (i.e., the current FMU) and each previous FMU (i.e., each previous adjacent FMU of the current FMU). At block 806, controller 108 programs the value and each first checksum signature into NVM 110. At block 808, controller 108 receives a read request from host device 104 to read the value using the key. At block 810, controller 108 reads each first checksum signature and the value from NVM 110. At block 812, the controller generates a second checksum signature for each FMU of the value, where the second checksum signature is based on the FMUs read from NVM 110. At block 814, the controller compares the first checksum signatures with the corresponding second checksum signatures. At block 816, controller 108 sends a read failure message to host device 104 after determining that at least one comparison has failed.

[0055] By leveraging the characteristics of the value of key-value pair data, CRC signatures can be optimized to improve the integrity of the value and reduce the failure rate of the data storage device.

[0056] In one embodiment, a data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to receive key-value (KV) pair data from a host device, where the KV pair data includes a key and a value, where the key addresses the value, and where the value includes two or more flash management units (FMUs); generate a first checksum signature for the received value, where the first checksum signature is generated for an aggregated number of consecutive adjacent FMUs of the value; and program the generated first checksum signature and the value into the memory device.

[0057] The aggregated number of consecutive adjacent FMUs of a value is all the FMUs of the value. The aggregated number of consecutive adjacent FMUs of a value used for the first checksum signature is the first FMU of the value. The controller is further configured to generate a second checksum signature for the received value, wherein the second checksum signature is generated for the aggregated number of consecutive adjacent FMUs of the value, and the aggregated number of consecutive adjacent FMUs of the second checksum signature is the first FMU and the second FMU of the value. In one embodiment, the first checksum signature and the second checksum signature have the same size, and wherein the first checksum is a cyclic redundancy code (CRC) signature. In another embodiment, the second checksum signature is a predetermined size larger than the first checksum signature. The first checksum signature is used for two or more FMUs. The first checksum signature is generated after receiving the last FMU of two or more FMUs from the host. The controller is further configured to receive a key from a host device; retrieve a value from a memory device using the key, wherein retrieving the value further includes retrieving the first checksum signature; generate a read checksum signature for the value retrieved from the memory device and determine whether the read checksum signature matches the first checksum signature. The controller is further configured to send the value to the host device when the read checksum signature matches the first checksum signature. The controller is further configured to send an error message to the host device when the read checksum signature does not match the first checksum signature.

[0058] In another embodiment, the data storage device includes a memory device and a controller coupled to the memory device. The controller is configured to generate a checksum signature for the value of a key-value (KV) pair data. The KV pair data includes a key and a value. The key addresses the value. The value includes two or more flash management units (FMUs). The checksum signature is generated for the first FMU and every two or more consecutive adjacent FMUs after the first FMU.

[0059] The checksum signature is programmed into the memory device along with the last FMU among multiple FMUs of the value. The controller is further configured to receive a key in a read request for the value, where the key further includes a specific FMU of the value; retrieve the value and the checksum signature from the memory device, where the retrieved checksum signature corresponds to the specific FMU of the value. The controller is further configured to receive a key in a read request for the value, where the key further includes a specific FMU of the value, and retrieve the value and the checksum signature from the memory device, where the retrieved checksum signature corresponds to the last FMU among multiple FMUs of the value. In one embodiment, the checksum signatures for each FMU among two or more consecutive adjacent FMUs have the same size. In another embodiment, the checksum signatures for each FMU among two or more consecutive adjacent FMUs have a variable size. The two or more consecutive adjacent FMUs include each previous FMU of the current FMU among the two or more consecutive adjacent FMUs.

[0060] In another embodiment, the data storage device includes means for storing data and a controller coupled to the means for storing data. The controller is configured to generate a checksum signature for each flash memory management unit (FMU) of the value of a key-value (KV) pair of data, where the KV pair of data includes a key and a value, where the key addresses the value, where the value includes multiple FMUs, and where the checksum signature generated for each FMU among the FMUs other than the first FMU among the multiple FMUs is associated with the current FMU and each previous FMU among the multiple FMUs; program the value and each checksum signature into the means for storing data; receive a read request including the key from a host device; retrieve the value and the checksum signature associated with the FMU requested by the read request from the means for storing data; generate another checksum signature for the retrieved value, where the other checksum signature is associated with the requested FMU and each previous FMU relative to the requested FMU; determine that the other checksum signature matches the retrieved checksum signature; and provide the value to the host device. Each checksum signature generated for each FMU among the FMUs other than the first FMU among the multiple FMUs includes a constant size or a variable size.

[0061] While the foregoing is directed to embodiments of the present disclosure, other and additional embodiments of the present disclosure may be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A data storage device, the data storage device comprising: A memory device; And A controller, the controller being coupled to the memory device, wherein the controller is configured to: Receive key - value (KV) pair data from a host device, wherein: The KV pair data includes a key and a value; The key addresses the value; and The value includes two or more flash memory management units (FMUs); Generate a first checksum signature for the received value, wherein the first checksum signature is generated for an aggregated number of consecutive adjacent FMUs of the value; and Program the generated first checksum signature and the value into the memory device.

2. The data storage device according to claim 1, wherein the aggregated number of consecutive adjacent FMUs of the value is all of the FMUs of the value.

3. The data storage device according to claim 1, wherein the aggregated number of consecutive adjacent FMUs of the value for the first checksum signature is the first FMU of the value.

4. The data storage device according to claim 3, wherein the controller is further configured to: Generate a second checksum signature for the received value, wherein: The second checksum signature is generated for an aggregated number of consecutive adjacent FMUs of the value; and The aggregated number of consecutive adjacent FMUs of the second checksum signature is the first FMU and the second FMU of the value.

5. The data storage device according to claim 4, wherein the first checksum signature and the second checksum signature have the same size, and wherein the first checksum is a cyclic redundancy code (CRC) signature.

6. The data storage device according to claim 4, wherein the second checksum signature is larger than the first checksum signature by a predetermined size.

7. The data storage device according to claim 1, wherein the first checksum signature is for the two or more FMUs.

8. The data storage device according to claim 1, wherein the first checksum signature is generated after receiving the last FMU of the two or more FMUs from the host.

9. The data storage device according to claim 1, wherein the controller is further configured to: Receive the key from the host device; Retrieve the value from the memory device using the key, wherein retrieving the value further includes retrieving the first checksum signature; Generate a read checksum signature for the value retrieved from the memory device; And Determine whether the read checksum signature matches the first checksum signature.

10. The data storage device according to claim 9, wherein the controller is further configured to: When the read checksum signature matches the first checksum signature, send the value to the host device.

11. The data storage device according to claim 9, wherein the controller is further configured to: When the read checksum signature does not match the first checksum signature, send an error message to the host device.

12. A data storage device, the data storage device comprising: A memory device; And A controller, the controller being coupled to the memory device, wherein the controller is configured to: Generate a checksum signature for a value of key-value (KV) pair data, wherein: The KV pair data includes a key and the value; The key addresses the value; The value includes a plurality of flash memory management units (FMUs); and Generate the checksum signature for the first FMU and every two or more consecutive adjacent FMUs after the first FMU.

13. The data storage device according to claim 12, wherein the checksum signature is programmed into the memory device together with the last FMU of the plurality of FMUs of the value.

14. The data storage device according to claim 12, wherein the controller is further configured to: Receive the key in a read request for the value, wherein the key further includes a specific FMU of the value; and Retrieve the value and the checksum signature from the memory device, wherein the retrieved checksum signature corresponds to the specific FMU of the value.

15. The data storage device according to claim 12, wherein the controller is further configured to: Receive the key in a read request for the value, wherein the key further includes a specific FMU of the value; and Retrieve the value and the checksum signature from the memory device, wherein the retrieved checksum signature corresponds to the last FMU of the plurality of FMUs of the value.

16. The data storage device according to claim 12, wherein the checksum signature for each of the two or more consecutive adjacent FMUs has the same size.

17. The data storage device according to claim 12, wherein the checksum signature for each of the two or more consecutive adjacent FMUs has a variable size.

18. The data storage device according to claim 12, wherein the two or more consecutive adjacent FMUs include each previous FMU of the current FMU among the two or more consecutive adjacent FMUs.

19. A data storage device, the data storage device comprising: Means for storing data; And A controller, the controller being coupled to the means for storing data, wherein the controller is configured to: Generate a checksum signature for each flash memory management unit (FMU) of a value of key-value (KV) pair data, wherein: The KV pair data includes a key and the value; The key addresses the value; The value includes a plurality of FMUs; and The checksum signature generated for each FMU among the FMUs other than the first FMU of the plurality of FMUs is associated with the current FMU and each previous FMU of the plurality of FMUs; Program the value and each checksum signature into the means for storing data; Receive a read request including the key from a host device; Retrieve the value and the checksum signature associated with the FMU requested by the read request from the means for storing data; Generate another checksum signature for the retrieved value, where the another checksum signature is associated with the requested FMU and each previous FMU relative to the requested FMU; Determine that the another checksum signature matches the retrieved checksum signature; and Provide the value to the host device.

20. The data storage device according to claim 19, wherein each checksum signature generated for each FMU among the plurality of FMUs except the first FMU includes: A constant size; Or A variable size.

Images