Optimized kv metadata storage for machine learning applications

Abstract

Metadata generated during the life cycle of the machine learning and artificial intelligence system is valuable. However, such metadata may be generated after the time at which the data is generated, and thus written later to the storage device. By further supporting a KV database at the storage level, performance in transfer per second may be increased. This is due to the removal of a translation layer in the host, which is required for previous data storage. The removal of the translation layer provides for two-layer mapping and removal of transaction information. Thus, the number of transactions per second, write amplification, and read amplification are increased, while latency is reduced. In addition, future addition of metadata is considered by reserving additional memory when storing the start key value. The future addition is then later saved to the reserved memory.

Description

Background Technology Invention Field

[0001] The embodiments disclosed herein relate generally to data storage devices such as solid-state drives (SSDs), and more specifically to optimizing the storage of key-value pair data and associated metadata in data storage devices.

[0002] Description of related technologies

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

[0004] Using a key-value (KV) database in a data storage device can increase its performance. For example, the number of data transfers per second can be improved because the KV pair data, which translates to the physical storage location in the host device, can be removed. Furthermore, the number of commands on the bus can be reduced because the entire KV pair data can be transferred in a single transaction. However, the metadata associated with the KV pair data may not be available for storage in the data storage device when the KV pair data is transferred to it. In other words, the metadata associated with the KV pair data may be generated after the KV pair data is programmed into the data storage device. When metadata and associated KV pair data are not transferred simultaneously, additional mappings are required to address the metadata and associate it with the KV pair data. This can increase latency when processing commands related to the KV pair data and associated metadata, and additional memory is needed to store the additional mappings.

[0005] There is a need in this field for optimized storage for mapping KV pair data and associated metadata. Summary of the Invention

[0006] Metadata generated during the lifecycle of machine learning and artificial intelligence systems is valuable. However, such metadata can be generated after the data is generated and therefore written to storage devices later. Performance in terms of transfers per second can be increased by further supporting KV databases at the storage device level. This is due to the removal of the translation layer in the host, which was previously required for data storage. The removal of the translation layer provides the removal of two layers of mapping and transaction information. Therefore, the number of transactions per second, write amplification, and read amplification increase, while latency decreases. Additionally, future additions of metadata are accounted for by reserving additional memory when storing the initial key-value pairs. These future additions are then later saved to the reserved memory.

[0007] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive data from a host, wherein the data is key-value (KV) pair data; store the data in a KV namespace, wherein: the KV namespace includes keys and values; the keys address the values; the values ​​include a plurality of flash management units (FMUs); receive from the host a write command to write second data to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and store the second data in the KV namespace.

[0008] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive key-value (KV) pair data from a host, wherein the KV pair data includes a key and a value; the key addresses the value; the value includes a plurality of flash management units (FMUs); create a KV namespace, wherein the KV namespace includes a key and a value; store the KV pair data in the KV namespace; receive from the host a write command to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and store the metadata in the KV namespace.

[0009] In another embodiment, a data storage device includes: a component for storing data; and a controller coupled to the component for storing data, wherein the controller includes: a metadata conversion module configured to convert metadata; and a flash conversion layer communicatively coupled to the metadata conversion module and configured to convert key-value (KV) values ​​or logical block addresses into physical block addresses; the controller is configured to: receive key-value (KV) pair data from a host, wherein: the KV pair data includes a key and a value; the key addresses the value; the value includes a plurality of flash management units (FMUs); create a KV namespace, wherein the KV namespace includes a key and a value; store the KV pair data in the KV namespace; receive from the host a write command to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; store the metadata in the KV namespace; and reserve a portion of the value in the KV namespace for storing metadata, wherein the portion is the remaining portion of the value in the KV namespace after the KV pair data is stored in the KV namespace. Attached Figure Description

[0010] To gain a more detailed understanding of the features described above, the disclosure can be further described with reference to embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings only show typical embodiments of the disclosure and are therefore not intended to limit the scope of the disclosure, as other equivalent embodiments are permissible.

[0011] Figure 1 This is a schematic block diagram illustrating a storage system according to certain embodiments, in which the data storage device can be used as a storage device for the host device.

[0012] Figure 2 This is a diagram of a traditional key-value store and key-value heap according to certain implementation schemes.

[0013] Figure 3A This is an exemplary illustration of KV pairs of data according to certain implementation schemes.

[0014] Figure 3B This is a table that shows the set of commands for a KV database according to certain implementation schemes.

[0015] Figure 4 This is a schematic block diagram illustrating a storage system according to certain implementation schemes.

[0016] Figure 5 This is a flowchart illustrating a method for a KV metadata storage system according to certain implementations.

[0017] Figure 6This is a flowchart illustrating a method for a KV metadata storage system according to certain implementations.

[0018] Figure 7 This is a flowchart illustrating a method for a KV metadata storage system according to certain implementations.

[0019] Figure 8 This is a flowchart illustrating a method for a KV metadata storage system according to certain implementations.

[0020] For ease of understanding, the same reference numerals have been used where possible to designate common elements in the figures. It is contemplated that elements disclosed in one embodiment may be advantageously used in other embodiments without further description. Detailed Implementation

[0021] In the following text, reference is made to embodiments of this disclosure. However, it should be understood that this disclosure is not limited to the specifically described embodiments. Rather, any combination of the following features and elements (whether or not different embodiments are involved) is contemplated to realize and practice this disclosure. Furthermore, while embodiments of this 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 this disclosure. Therefore, the following aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims. Similarly, reference to “this disclosure” should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0022] Metadata generated during the lifecycle of machine learning and artificial intelligence systems is valuable. However, such metadata can be generated after the data is generated and therefore written to storage devices later. Performance in terms of transfers per second can be increased by further supporting KV databases at the storage device level. This is due to the removal of the translation layer in the host, which was previously required for data storage. The removal of the translation layer provides the removal of two layers of mapping and transaction information. Therefore, the number of transactions per second increases, while write amplification, read amplification, and latency decrease. Additionally, future additions of metadata are accounted for by reserving additional memory when storing the initial key-value pairs. These future additions are then later saved to the reserved memory.

[0023] Figure 1This is a schematic block diagram illustrating a storage system 100 according to some embodiments, the storage system having a data storage device 106 that can be used as a storage device for a host device 104. For example, the host device 104 may utilize non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes host dynamic random access memory (DRAM) 138. In some examples, the storage system 100 may include multiple storage devices such as the data storage device 106 that can operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 configured as a low-cost / independent redundant disk array (RAID) that collectively serves as a large-capacity storage device for the host device 104.

[0024] Host device 104 can store data to or retrieve data from one or more storage devices, such as data storage device 106. Figure 1 As shown, host device 104 can communicate with data storage device 106 via interface 114. Host device 104 can include any of a wide range of devices, including: computer servers, network attached storage (NAS) units, desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone receivers (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 data storage devices.

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

[0026] Data storage device 106 includes a controller 108, an NVM 110, a power supply 111, volatile memory 112, an interface 114, a write buffer 116, and optional DRAM 118. In some examples, data storage device 106 may include components not shown for clarity. Figure 1 Additional components are shown in the diagram. For example, data storage device 106 may include a printed circuit board (PCB) to which components of data storage device 106 are mechanically attached, and the PCB includes conductive traces for electrically interconnecting components of data storage device 106, etc. In some examples, the physical dimensions and connector configuration of 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., HDDs or SSDs), 2.5-inch data storage devices, 1.8-inch data storage devices, peripheral component interconnect (PCI), peripheral component interconnect extension (PCI-X), peripheral component fast interconnect (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe mini-cards, mini PCI, etc.). In some examples, data storage device 106 may be directly coupled (e.g., directly soldered or inserted into a connector) to the motherboard of host device 104.

[0027] Interface 114 may include one or both of a data bus for exchanging data with host device 104 and a control bus for exchanging commands with host device 104. Interface 114 may operate according to any suitable protocol. For example, interface 114 may operate according to a Fast Non-Volatile Memory (NVMe) protocol, etc. Interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to controller 108, thereby providing an electrical connection between host device 104 and controller 108, allowing data exchange between host device 104 and controller 108. In some examples, the electrical connection of interface 114 may also allow data storage device 106 to receive power from host device 104. For example, as... Figure 1 As shown, power supply 111 can receive power from host device 104 via interface 114.

[0028] 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, a memory cell of the NVM 110 may receive data and messages from controller 108 instructing the memory cell to store data. Similarly, a memory cell may receive messages from controller 108 instructing the memory cell to retrieve data. In some examples, each memory cell in the memory cell 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., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0029] 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.

[0030] 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 in the floating gate of the transistors contained in each flash memory cell. In an NVM flash memory device, the flash memory device may be divided into multiple dies, each of which includes multiple physical or logical blocks, which may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. Rows of NVM cells may be electrically connected using word lines to define pages within the multiple pages. A corresponding cell in each of the multiple pages may be electrically connected to a corresponding bit line. Furthermore, the NVM flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), or four-level cell (QLC). Controller 108 may write data to and read data from the NVM flash memory device at the page level and erase data from the NVM flash memory device at the block level.

[0031] Power supply 111 can provide 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 provide power to one or more components. For example, power supply 111 can use power received from host device 104 via interface 114 to provide power to one or more components. In some examples, power supply 111 may include one or more power storage components configured to provide power to one or more components when operating in a shutdown mode (such as when power is stopped from external devices). In this way, power supply 111 can be used as an onboard 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 electrical energy 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 electrical energy stored by one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0032] Controller 108 may use volatile memory 112 to store information. Volatile memory 112 may include one or more volatile memory devices. In some examples, controller 108 may use volatile memory 112 as a cache. For example, controller 108 may store cached information in volatile memory 112 until the cached information is written to NVM 110. Figure 1 As shown, volatile memory 112 can consume 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), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)). Similarly, optional DRAM 118 can be used to store mapped data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, etc. In some examples, data storage device 106 does not include optional DRAM 118, making data storage device 106 DRAM-free. In other examples, data storage device 106 includes optional DRAM 118.

[0033] Controller 108 may manage one or more operations of data storage device 106. For example, controller 108 may manage reading data from and / or writing data to NVM 110. In some embodiments, when data storage device 106 receives a write command from host device 104, controller 108 may initiate a data storage command to store data to NVM 110 and monitor the progress of the data storage command. Controller 108 may determine at least one operating characteristic of storage system 100 and store that at least one operating characteristic in NVM 110. In some embodiments, when data storage device 106 receives a write command from host device 104, controller 108 may temporarily store the data associated with the write command in internal memory or write buffer 116 before sending the data associated with the write command to NVM 110. Controller 108 may include a circuitry or processor configured to execute programs for operating data storage device 106.

[0034] Controller 108 may include optional second volatile memory 120. Optional second volatile memory 120 may be similar to volatile memory 112. For example, optional second volatile memory 120 may be SRAM. Controller 108 may allocate a portion of the optional second volatile memory as a controller memory buffer (CMB) 122 to host device 104. CMB 122 may be directly accessed by host device 104. For example, host device 104 may utilize CMB 122 to store one or more submission queues that are normally maintained in host device 104, rather than maintaining those one or more submission queues in host device 104. In other words, host device 104 may generate commands and store the generated commands (with or without associated data) in CMB 122, wherein controller 108 accesses CMB 122 to retrieve the stored generated commands and / or associated data.

[0035] One promising new area for industry development is SSDs that support key-value databases. NVMe standard version 2.0 introduced dedicated application programming interfaces (APIs) for supporting these databases at the storage device level.

[0036] Key-value (KV) databases work by storing a fixed amount of user data associated with a key that can be used to address complete entities. Examples include photos, records, or files. From the host's perspective, a photo or file can be retrieved using a single key-address instead of multiple addresses containing the data that makes up the photo. This can potentially abstract away from and simplify database management for certain applications, resulting in performance advantages for those applications.

[0037] Below are examples of the key differences between normal block storage and key-value (KV) storage, and the software heap that supports them. In block storage, data is stored in fixed-size blocks, addressed by Logical Block Addresses (LBAs), which are fixed-length bytes. Storage space is allocated in integer multiples of the block size, and logical blocks are associated one-to-one with physical blocks. However, in key-value (KV) storage, data is stored as unstructured data, addressed by keys, which are variable in length. Storage space is allocated in byte increments, and values ​​are associated with the required amount of physical storage. In fact, many KV applications are implemented in software on ordinary I / O storage devices.

[0038] Figure 2 This is a diagram of a traditional key-value store and key-value heap according to certain implementations. Key-value formats and key-value stores are typically used by software (e.g., Java, Python). However, when host software data is stored in the non-volatile memory of a data storage device (e.g., SSD), the data is translated into LBAs and physical block addresses (PBAs) via the host's translation layer.

[0039] Therefore, the advantage of supporting KV databases at the storage device level is the increased transfers per second performance. This performance increase occurs because the KV-to-block storage translation layer in the host is removed. This eliminates two layers of mapping and transaction information, which increases the number of transactions per second and write amplification while reducing latency. Additionally, commands on the bus are reduced to a single transfer for the entire KV pair. While this reduction to a single transfer for the entire KV pair causes a second latency reduction, it is not as significant as the savings from removing the translation operation that must occur in the host. Another advantage of supporting KV databases at the storage device level is the simplification and implementation of computational storage (e.g., near storage compute). User data on the device can now be recognized as complete units, rather than various fragments that may be contiguous or discontinuous in normal storage operations.

[0040] like Figure 2 As shown, traditional KV storage includes a host service, block device drivers, and block devices. Traditional KV storage includes a translation layer in the host that translates KV pairs to LBAs and PBAs when stored to the data storage device. However, support for KV databases (such as in KV heaps) presents a complete unit and, in some implementations, includes a slim KV library, KV device drivers, and KV devices. The removal of the translation layer (such as those present in traditional KV storage) leads to an increase in performance aspects (e.g., transactions per second (TX / s)), as well as a reduction in write amplification factor (WAF) and read amplification factor (RAF), and latency.

[0041] Figure 3A This is an exemplary illustration of key-value pair data 300 according to certain implementations. The key-value pair data 300 includes a key 302 and a value 304, wherein data for the value 304 (which may be host data) is addressed via 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 bytes. 32 -1 byte size. For example, when value 304 has a size of approximately 0 bytes, value 304 is null. It should be understood that the values ​​mentioned above are not intended to be limiting, but rather to provide examples of implementation schemes. Since value 304 can have a size larger than a physical word line (e.g., greater than 16KB), value 304 can be divided across several word lines and can lead to misalignment. Misalignment can occur when portions of data from multiple values ​​are stored on a single word line, or when a portion of value 304 is partially stored on a single word line. Because misalignment of stored data can lead to multiple reads, it can degrade the quality of service of data storage devices storing misaligned data and increase the power consumption of data storage devices.

[0042] Figure 3B Table 350 illustrates a set of commands for a KV database according to certain implementation schemes. For illustrative purposes, this document may refer to... Figure 1 The storage system 100 includes various aspects. The KV system may include a set of commands, which in a non-limiting list includes delete commands, enumeration commands, retrieval commands, existence commands, and store commands. A delete command causes controller 108 to delete key 302 and the value 304 associated with key 302. An enumeration command causes controller 108 to enumerate keys existing in a KV namespace starting with a specified key. An existence command causes controller 108 to return a status indicating whether KV pair data 300 exists for a specified key to a command generator such as host device 104. A store command causes controller 108 to store KV pair data into a KV namespace. A retrieval command causes 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 retrieval command, and the location used to transfer the KV pair data 300 is specified by a scatter collection list (SGL) pointer or a physical region page (PRP) pointer in the retrieval command. If the specified length in the retrieval command is less than the length of the KV pair data 300 being retrieved, the controller 108 returns the requested quantity and the length of the KV pair data 300 to the completion queue. However, if the specified length in the retrieval 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.

[0043] Therefore, by abstracting database management and storage devices (e.g., SSDs), KVSSDs, due to the unique architecture of KV SSDs, allow for potential advantages in optimization, simplification, and improvement on both the host and SSD sides. Currently, SSDs providing KV database interfaces instead of traditional block devices are still under development. Adding a KV database interface to an SSD adds only a small amount of complexity to the SSD's flash translation layer, while removing many redundant abstractions on the host software side. Therefore, the performance can be remarkably high compared to running KV database applications on top of a file system on a traditional SSD.

[0044] The NVMe key-value (NVMe-KV) command set has been standardized to NVM. NVMe-KV is one of the new I / O command sets supported by the underlying specification. NVMe-KV allows access to data on an NVMe SSD controller using keys instead of block addresses. The NVMe-KV command set provides keys to store corresponding values ​​on non-volatile media, and then retrieves those values ​​from that media by specifying the corresponding key. NVMe-KV allows users to access KV data without the expensive and time-consuming overhead of additional translation tables between keys and logical blocks.

[0045] Traditional flash memory operates in 4KB blocks called Flash Management Units (FMUs). This is the basic addressable unit used for reading and writing. While not limited to this size, it can range from 4KB to 4GB. For some applications, there are significant benefits to using large values ​​and storing them in flash memory. For some machine learning (ML) and artificial intelligence (AI) applications, metadata generated during the system's lifecycle is valuable. However, metadata generation can occur later than data generation and will therefore be written to the storage device later. In some cases, there may also be several fragments of metadata written at different times. Furthermore, it is beneficial to use the metadata associated with the data when it is used later.

[0046] Previously, there was no mechanism to effectively add metadata to data after it had been written. Metadata was written like regular data and linked to the content at the host level. Adding metadata to the key was a naive approach. A key-value (KV) storage system reads the value information associated with a key. Then, the KV storage system adds metadata information to that value and writes the entire value again. Alternatively, in some cases, the value is modified. This approach is inefficient because the host needs to read the entire value associated with the metadata, even if the host only wants to add to that value. Alternatively, another naive system would simply write the metadata to the new key and use host resources to associate the new key with the old key. However, there is overhead associated with the fact that more keys are used unnecessarily, and the host needs to manage their storage.

[0047] The following section further discusses methods for optimizing metadata storage in KV storage systems. Associated devices and methods enable metadata to be easily read along with the original data, thereby improving system performance.

[0048] Figure 4 This is a schematic block diagram illustrating a storage system 400 according to some embodiments. The storage system 400 is configured to store metadata for key-value (KV) storage and includes a host 402 and a storage controller 406. The host 402 and the storage controller 406 are communicatively coupled. The host 402 includes a metadata KV storage command module 404, while the storage controller 406 includes a metadata translation module 408 and a flash memory translation layer 410. The storage system 400 may be according to one or more embodiments. Figure 1 The storage system 100 is a specific implementation and can be combined with other implementations. The host 402 can be... Figure 1 The host 104. The storage controller 406 can be... Figure 1The controller 108. In some implementations, the storage system 400 may use a dedicated API between the host and the device. In some implementations, based on metadata collection and processing, the dedicated API of the storage system 400 may be used in applications associated with ML training and inference.

[0049] Metadata KV storage command module 404 is configured to pass metadata associated with a certain key to controller 406 instruction module 404 (e.g., operations 502 and 602). Metadata conversion module 408 is configured to determine whether there is sufficient space in the corresponding value for metadata or key-value pairs (e.g., operations 504 and 604). Flash conversion layer 410 is communicatively coupled to metadata conversion module 408 and acts as middleware between the host and storage device (e.g., SSD). Flash conversion layer 410 is configured to convert KV values ​​or LBAs used by the host into PBAs in the storage device during data storage. Flash conversion layer 410 is further configured to read, modify, and write any corresponding values ​​(e.g., operations 506, 606), and internally create any new keys and link those new keys to data keys (e.g., operations 508, 510, 608, 610).

[0050] Figure 5 This is a flowchart illustrating method 500 of a KV metadata storage system according to certain embodiments. Method 500 creates a value that takes into account the possibility of future additions of metadata. For example, if the information about a user takes 10KB, the value itself may contain 100KB. The beginning of the value will contain 10KB of source information, but the remainder of the value will be reserved for future metadata additions. In some embodiments, there may be a special command to add metadata to a specific key.

[0051] In some implementations, metadata can be generated or collected by the host after the data itself has been stored in the device. For example, in a recommendation system, the data could be a log entry of a user's location at a certain time. Metadata could consist of users associated with an activity, such as playing basketball (inferred from other interests or applications of the host). The system could then better recommend certain activities for that user's future locations.

[0052] Method 500 begins with operation 502, where the controller (e.g., Figure 4 The controller 406) is from the host (e.g., Figure 4 The host (402) receives a write command to write metadata to a data key. At operation 504, the controller determines if there is sufficient space in the corresponding value to append the new metadata fragment. If so, at operation 506, the controller may read, modify, or internally write the value to non-volatile memory (e.g., ...). Figure 1(Non-volatile memory 110). It should be noted that it is not necessary to read the entire value, but only the portion to be modified. If there is not enough space in the corresponding value to append the new metadata fragment, at operation 508, the controller creates a new key and value and writes the corresponding value portion. At operation 510, if there is enough space in the value, the controller internally links the new key to the original data key to which the new key should be appended. In some implementations, the described link is transparent to the host. That is, the host is unaware that the described link is stored jointly or separately from the data value itself.

[0053] Figure 6 This is a flowchart illustrating method 600 of a KV metadata storage system according to certain embodiments. In the KV metadata storage system of method 600, the write granularity is full FMU. This can be controlled by the host writing to the full FMU, or by the device filling in the missing data portion before writing the missing data portion at the FMU granularity. In this case, there is no need to read and modify the corresponding value portion, and the controller can write only the corresponding null value portion.

[0054] Method 600 begins with operation 602, where the controller (e.g., Figure 4 The controller 406) is from the host (e.g., Figure 4 The host (402) receives a write command to write metadata to a data key. At operation 604, the controller determines if there is sufficient space in the corresponding value to append the new metadata fragment. If so, at operation 606, the controller can internally write the value to non-volatile memory (e.g., ...). Figure 1 (Non-volatile memory 110). It should be noted that it is not necessary to read the entire value, but only the portion to be modified. If there is not enough space in the corresponding value to append the new metadata fragment, at operation 608, the controller creates a new key and value and writes the corresponding value portion. At operation 610, if there is enough space in the value, the controller internally links the new key to the original data key to which the new key should be appended.

[0055] Figure 7 This is a flowchart illustrating method 700 of a KV metadata storage system according to certain implementations. Sometimes, the source data may be separate from the metadata. Since the "value" needs to be read from the beginning of the "value," starting the value from the source data may incur unnecessary data reads if the host only needs the metadata information. When reading, modifying, and / or rewriting metadata values, the controller of the data storage device (e.g., Figure 4 The controller 406 can decide to reorder the value. The host (e.g., Figure 4The host (402) can indicate that it only wants a portion of the value, so that once the controller has read the metadata the host wants, the controller can stop reading. For example, the value can be sorted so that the most recent metadata is written first, which has the highest chance of being read by the host.

[0056] Method 700 can be applied to ML models. For example, in implementations where the entire model is written as a single value or several values ​​(such as the values ​​of each layer of NN weights) based on logical assignment. Since the model is often read sequentially during the inference step, there is an advantage in reducing the overhead used for inference. When applied to ML models, Method 700 optimizes training and tuning. Weights may frequently change when training ML and AI models. However, in later training phases and when tuning the last layer of the model, only a subset of the weights can change. During such ML applications of Method 700, if the host (e.g., Figure 4 The host (402) expects to update some weights in the weights, then the controller (e.g., Figure 4 The controller (406) can pass the weights and their model components (e.g., offsets) that the controller wants to change to the corresponding layer values. The model components (e.g., offsets) are associated with the representation of the model's weights. It should be noted that model components can also refer to other parts of the model, such as leaf values ​​(in a tree model). The controller updates the corresponding physical location by simply reading from, modifying, and / or writing to the FMU containing the weights to be changed.

[0057] Therefore, method 700 begins with operation 702, where the host tunes the ML model by updating several weights. At operation 704, the controller receives a list of weights and their offsets in the values ​​from the host. At operation 706, the controller reads the FMU only from the values ​​corresponding to the offsets passed by the host. At operation 708, the controller modifies the FMU containing the updated layer values ​​and writes it to that FMU.

[0058] Figure 8 This is a flowchart illustrating a method 800 of a KV metadata storage system according to certain implementations. After receiving a write command to write metadata to a specific data key, the controller (e.g., Figure 4 The controller (406) can first determine the write granularity of the storage device. In some implementations, the controller is further configured to make the same determination before receiving write commands for write metadata. The write granularity can be adjusted based on the monitored data storage patterns or usage patterns of the device.

[0059] Method 800 begins with operation 802, where the controller receives a write command from the host to write KV pair data. At operation 804, the controller creates new keys and values, reserving a portion of the values ​​for future metadata additions. The values ​​in the KV namespace (i.e., the created keys and values) will be larger in size than the KV pair data currently being stored to account for future metadata additions. For example, the initial KV pair data may be approximately 10KB, but the KV namespace itself may contain 100KB for future metadata additions. Therefore, the initial value will be 10KB of source information, but the remainder of the value will be reserved for future metadata additions. In some implementations, the memory is non-volatile memory (e.g., ...). Figure 1 The non-volatile memory 110). At operation 806, the controller receives data from the host (e.g., non-volatile memory 110). Figure 4 The host (402) receives a write command to write metadata to a data key. At operation 808, the controller may determine or adjust the write granularity based on the storage device's previous storage or usage patterns. The determination of whether to adjust the write granularity may also be based on whether there is sufficient space in the storage device for the write overhead of the additional FMU and a trade-off in write speed. In some implementations, the host may indicate the write granularity size to the controller. If the write granularity is smaller than the full FMU, at operation 810, the controller determines whether there is sufficient space in the corresponding value to append the new metadata fragment. If the write granularity is greater than or equal to the full FMU, at operation 818, the controller determines whether there is sufficient space in the corresponding value to append the new metadata fragment.

[0060] After operation 810, if there is sufficient space in the corresponding value, then at operation 812, the controller can read, modify, or internally write the value to non-volatile memory (e.g., ...). Figure 1 (Non-volatile memory 110). It should be noted that it is not necessary to read the entire value, but only the portion to be modified. If there is not enough space in the corresponding value to append the new metadata fragment, at operation 814, the controller creates a new key and value and writes the corresponding value portion. At operation 816, if there is enough space in the value, the controller internally links the new key to the original data key to which the new key should be appended.

[0061] After operation 818, if there is sufficient space in the corresponding value, then at operation 820, the controller can internally write the value to non-volatile memory (e.g., ...). Figure 1(Non-volatile memory 110). It should be noted that it is not necessary to read the entire value, but only the portion to be modified. If there is not enough space in the corresponding value to append the new metadata fragment, at operation 822, the controller creates a new key and value and writes the corresponding value portion. At operation 824, if there is enough space in the value, the controller internally links the new key to the original data key to which the new key should be appended.

[0062] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive data from a host, wherein the data is key-value (KV) pair data; store the data in a KV namespace, wherein: the KV namespace includes keys and values; the keys address the values; the values ​​include a plurality of flash management units (FMUs); receive from the host a write command to write second data to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and store the second data in the KV namespace.

[0063] The second data is metadata, and the key of the metadata corresponds to the key of the data. The controller is further configured to receive from the host a command to update at least one weight of a machine learning (ML) model. The command also includes a command to update at least one model component associated with the at least one weight. The controller is further configured to read only the FMUs among the plurality of FMUs corresponding to the at least one model component. The controller is further configured to write to and modify the FMUs among the plurality of FMUs containing the at least one weight.

[0064] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive key-value (KV) pair data from a host, wherein the KV pair data includes a key and a value; the key addresses the value; the value includes a plurality of flash management units (FMUs); create a KV namespace, wherein the KV namespace includes a key and a value; store the KV pair data in the KV namespace; receive from the host a write command to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and store the metadata in the KV namespace.

[0065] The size of the key-value pair data is less than the size of the key-value namespace. The controller is further configured to reserve a portion of the key-value namespace for storing the metadata, where this portion is the remaining portion of the key-value namespace after the key-value pair data is stored in the key-value namespace. The controller is further configured to determine if the size of the metadata is less than or equal to this portion. Based on the determination that the size of the metadata is less than or equal to this portion, the controller is further configured to read, modify, or write the metadata to the key-value namespace. Based on the determination that the size of the metadata is greater than this portion, the controller is further configured to create a new key-value namespace, where the new key-value namespace includes keys and values. Based on the determination that the size of the metadata is greater than this portion, the controller is further configured to store the metadata in the new key-value namespace. The controller is further configured to internally link the key of the new key-value namespace to the key of the key-value namespace. The controller is further configured to determine if the write granularity is greater than or equal to the full FMU. Based on the determination that the write granularity is greater than or equal to the full FMU, the controller is further configured to write the metadata to the KV namespace. The controller is further configured to adjust the write granularity based on the data storage style and usage style. The size of the KV pair data value is between 4 bytes and 4 gigabytes. The memory device is non-volatile memory.

[0066] In another embodiment, a data storage device includes: a component for storing data; and a controller coupled to the component for storing data, wherein the controller includes: a metadata conversion module configured to determine whether there is sufficient space in the value for metadata; and a flash conversion layer communicatively coupled to the metadata conversion module and configured to convert KV values ​​or logical block addresses into physical block addresses; the controller is configured to: receive key-value (KV) pair data from a host, wherein: the KV pair data includes a key and a value; the key addresses the value; and the... The value includes multiple flash management units (FMUs); creating a KV namespace, wherein the KV namespace includes keys and values; storing the KV pair data in the KV namespace; receiving a write command from the host to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; storing the metadata in the KV namespace; and reserving a portion of the value in the KV namespace for storing metadata, wherein the portion is the remaining portion of the value in the KV namespace after the KV pair data is stored in the KV namespace.

[0067] While the foregoing relates to embodiments of this disclosure, other and further embodiments of this disclosure may be designed without departing from the basic scope of this disclosure, and the scope of this disclosure is defined by the appended claims.

Claims

1. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, wherein the controller is configured to: Receive data from the host, wherein the data is key-value (KV) pair data; The data is stored in a KV namespace, where: The KV namespace includes keys and values; The key addresses the value; The values ​​include multiple Flash Management Units (FMUs); Receive a write command from the host to write second data to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and The second data is stored in the KV namespace.

2. The data storage device of claim 1, wherein the second data is metadata, and wherein the key of the metadata corresponds to the key of the data.

3. The data storage device of claim 1, wherein the controller is further configured to receive from the host a command to update at least one weight of a machine learning (ML) model.

4. The data storage device of claim 3, wherein the command further comprises a command to update at least one model component associated with the at least one weight.

5. The data storage device of claim 4, wherein the controller is further configured to read only the FMU among the plurality of FMUs corresponding to the at least one model component.

6. The data storage device of claim 5, wherein the controller is further configured to write to and modify the FMU among the plurality of FMUs containing the at least one weight.

7. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, wherein the controller is configured to: Receive key-value (KV) pair data from the host, where: The KV pair data includes a key and a value; The key addresses the value; The values ​​include multiple Flash Management Units (FMUs); Create a key-value namespace, wherein the key-value namespace includes keys and values; Store the key-value pairs into the key-value namespace; Receive a write command from the host to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; and The metadata is stored in the KV namespace.

8. The data storage device according to claim 7, wherein the value of the KV pair of data is smaller than the value of the KV namespace.

9. The data storage device of claim 7, wherein the controller is further configured to reserve a portion of the value of the KV namespace for storing metadata, wherein the portion is the remaining portion of the value of the KV namespace after the KV pair data is stored in the KV namespace.

10. The data storage device of claim 9, wherein the controller is further configured to determine whether the size of the metadata is less than or equal to the portion.

11. The data storage device of claim 10, wherein, based on the determination that the size of the metadata is less than or equal to the portion, the controller is further configured to read, modify, or write the metadata to the KV namespace.

12. The data storage device of claim 10, wherein, based on the determination that the size of the metadata is greater than the portion, the controller is further configured to create a new KV namespace, wherein the new KV namespace includes keys and values.

13. The data storage device of claim 12, wherein, based on the determination that the size of the metadata is greater than the portion, the controller is further configured to store the metadata in the new KV namespace.

14. The data storage device of claim 13, wherein the controller is further configured to internally link the keys of the new KV namespace to the keys of the KV namespace.

15. The data storage device of claim 7, wherein the controller is further configured to determine whether the write granularity is greater than or equal to the full FMU.

16. The data storage device of claim 15, wherein, based on the determination that the write granularity is greater than or equal to the full FMU, the controller is further configured to write the metadata to the KV namespace.

17. The data storage device of claim 16, wherein the controller is further configured to adjust the write granularity based on the data storage pattern and usage pattern.

18. The data storage device of claim 7, wherein the size of the KV pair data value is between 4 bytes and 4 gigabytes.

19. The data storage device of claim 7, wherein the memory device is a non-volatile memory.

20. A data storage device, the data storage device comprising: Components for storing data; and A controller, coupled to the component storing the data, wherein the controller includes: A metadata transformation module, configured to determine whether there is sufficient space in the value for metadata; and A flash memory translation layer, communicatively coupled to the metadata translation module, and configured to translate KV values ​​or logical block addresses into physical block addresses; The controller is configured to: Receive key-value (KV) pair data from the host, where: The KV pair data includes a key and a value; The key addresses the value; The values ​​include multiple Flash Management Units (FMUs); Create a key-value namespace, wherein the key-value namespace includes keys and values; Store the key-value pairs into the key-value namespace; Receive a write command from the host to write metadata to the KV namespace, wherein the write command to write metadata is received after receiving the KV pair data; Store the metadata in the KV namespace; and A portion of the value in the KV namespace is reserved for storing metadata, wherein the portion is the remaining portion of the value in the KV namespace after the KV pair data is stored in the KV namespace.

Images