Optimized KV metadata storage for machine learning applications

Abstract

This invention provides a storage device that optimizes the storage of key-value pair data and associated metadata in a data storage device. [Solution] In the storage system 100, the data storage device comprises a memory device and a controller coupled to the memory device. The controller receives data from the host in which the data is key-value (KV) pair data and stores the data in the KV namespace. The KV namespace contains keys and values, where the key addresses the value and the value contains a plurality of flash management units (FMUs). The controller receives a write command from the host for writing metadata, which is received following the reception of the KV pair data, and stores the second data in the KV namespace.

Description

Technical Field

[0001] (Field of the Invention) Embodiments of the present disclosure generally relate to data storage devices such as solid state drives (SSDs), and more particularly to optimizing the storage of key-value pair data and related metadata in data storage devices.

[0002] (Cross-Reference to Related Applications) A key value (KV) database functions 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 may include photos, records, and files. From the perspective of a host device, a photo, record, or file may be retrieved using a single key / address rather than using multiple addresses that include the data of the photo, record, or file. The data is stored as unstructured data and may be addressed using variable-length keys. The storage space of a memory device may be allocated in bytes for KV pair data, and the length value of the KV pair data is associated with the storage space required to store the KV pair data.

[0003] The performance of a data storage device may be improved by using a KV database. For example, the data transfer rate per second may be improved because the translation layer from KV pair data to physical storage location in the host device can be eliminated. Furthermore, the number of commands over the bus may be reduced because the entire KV pair data can utilize a single transfer. However, metadata associated with KV pair data may not be available for storage in the data storage device when the KV pair data is transferred to the data storage device. In other words, metadata associated with KV pair data may be generated after the KV pair data has been programmed into the data storage device. When metadata is transferred non-concurrently with the associated KV pair data, additional mapping is required to address the metadata and associate it with the KV pair data, which may increase latency when processing commands related to the KV pair data and associated metadata, and may require additional memory to store the additional mapping.

[0004] In this technical field, optimized storage of mappings for KV pair data and associated metadata is required. [Overview of the project]

[0005] Metadata generated during the lifespan of machine learning and artificial intelligence systems is valuable. However, such metadata is generated following the time of data generation and may therefore be written to storage devices later. Performance in terms of transfers per second can be improved by further supporting KV databases at the storage device level. This is achieved by eliminating the translation layer within the host, which was previously required for data storage. Eliminating the translation layer provides the elimination of two layers: mapping and transaction information. As a result, the number of transactions per second, write amplification, and read amplification increase, while latency decreases. Additionally, future additions of metadata are considered by reserving extra memory when storing the initial key value. Future additions are then stored later in the reserved memory.

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

[0007] In another embodiment, the 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, create a KV namespace in which 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), store the KV pair data in the KV namespace, receive a write command from the host for writing metadata to the KV namespace, the write command for writing metadata is received following the reception of the KV pair data, and store the metadata in the KV namespace.

[0008] In yet another embodiment, the data storage device includes means for storing data and a controller coupled to the means for storing data, the controller comprising a metadata translation module configured to translate metadata and a flash translation layer communicatively coupled to the metadata translation module and configured to translate KV values ​​or logical block addresses to physical block addresses, the controller receiving key-value (KV) pair data from a host, creating a KV namespace in which the KV namespace contains key and value, the KV pair data includes key and value, the key addresses value, the value includes a plurality of flash management units (FMUs), the KV namespace contains key and value, storing the KV pair data in the KV namespace, receiving a write command from the host for writing metadata to the KV namespace, the write command for writing metadata is received following the reception of the KV pair data, storing the metadata in the KV namespace, and reserving a portion of the value of the KV namespace for storing the metadata, the portion being the remainder of the value of the KV namespace after the KV pair data has been stored in the KV namespace. [Brief explanation of the drawing]

[0009] A more detailed description of the Disclosure, which is concisely summarized above, may be obtained by reference to embodiments, some of which are shown in the accompanying drawings, so that the above-mentioned features of the Disclosure may be understood in detail. However, it should be noted that the accompanying drawings show only typical embodiments of the Disclosure and should not be considered to limit its scope, as the Disclosure may allow for other equally valid embodiments. [Figure 1] This is a schematic block diagram showing a storage system in which, according to a particular embodiment, a data storage device may function as a storage device for a host device. [Figure 2] This is a diagram of a conventional KV storage and KV stack according to a specific embodiment. [Figure 3A] This is an illustrative diagram of KV pair data according to a specific embodiment. [Figure 3B] This is a table showing the command set for a KV database according to a specific embodiment. [Figure 4] This is a schematic block diagram showing a memory system according to a specific embodiment. [Figure 5] This is a flowchart illustrating a method for a KV metadata storage system according to a specific embodiment. [Figure 6] This is a flowchart illustrating a method for a KV metadata storage system according to a specific embodiment. [Figure 7] This is a flowchart illustrating a method for a KV metadata storage system according to a specific embodiment. [Figure 8] This is a flowchart illustrating a method for a KV metadata storage system according to a specific embodiment.

[0010] For ease of understanding, the same reference numerals are used to designate identical elements common to the drawings where possible. Elements disclosed in one embodiment are intended to be usefully utilized in other embodiments without specific description. [Modes for carrying out the invention]

[0011] The following refers to embodiments of the Disclosure. However, it should be understood that the Disclosure is not limited to any specific embodiment described. Instead, any combination of the following features and elements, whether related to a different embodiment or not, is intended to implement and practice the Disclosure. Furthermore, embodiments of the Disclosure may achieve advantages over other possible solutions and / or prior art, but whether a particular advantage is achieved by a given embodiment does not limit the Disclosure. Accordingly, the following aspects, features, embodiments, and advantages are merely illustrative and shall not be considered elements or limitations of the appended claims unless expressly enumerated in the claims. Similarly, references to “the Disclosure” shall not be construed as a generalization of the subject matter of any invention disclosed herein and shall not be considered elements or limitations of the appended claims unless expressly enumerated in the claims.

[0012] Metadata generated during the lifespan of machine learning and artificial intelligence systems is valuable. However, such metadata may be generated following the time of data generation and therefore later written to storage devices. Performance in terms of transfers per second can be improved by further supporting KV databases at the storage device level. This is due to the elimination of the translation layer within the host, which was previously required for data storage. The elimination of the translation layer provides the elimination of two layers: mapping and transaction information. As a result, the number of transactions per second increases, and write amplification, read amplification, and latency decrease. Additionally, future additions of metadata are considered by reserving extra memory when storing the initial key value. Future additions are then stored later in the reserved memory.

[0013] Figure 1 is a schematic block diagram showing a storage system 100 having a data storage device 106 which may function as a storage device for a host device 104 according to a particular embodiment. For example, the host device 104 may store and retrieve data using non-volatile memory (NVM) 110 contained in the data storage device 106. 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, which may operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID) which collectively function as a high-capacity storage device for the host device 104.

[0014] The host device 104 may store data in and / or retrieve data from one or more storage devices, such as the data storage device 106. As shown in Figure 1, the host device 104 may communicate with the data storage device 106 via the interface 114. The host device 104 may include any of a wide range of devices, including a computer server, a network-attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called "smart" phone, a so-called "smart" pad, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or other devices capable of sending or receiving data from a data storage device.

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

[0016] The 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 an optional DRAM 118. In some examples, the data storage device 106 may include additional components not shown in Figure 1 for clarity. For example, the data storage device 106 may include a printed circuit board (PCB) on which the components of the data storage device 106 are mechanically mounted and which includes conductive traces that electrically interconnect the components such as the data storage device 106. In some examples, the physical dimensions and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some exemplary 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), PCI-extended (PCI-X), and PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe MiniCard, MiniPCI, etc.). In some examples, the data storage device 106 may be directly coupled to the motherboard of the host device 104 (e.g., directly soldered or plugged into a connector).

[0017] Interface 114 may include either or both a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. Interface 114 may operate according to any preferred protocol. For example, interface 114 may operate according to the non-volatile memory express (NVMe) protocol, etc. Interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to the controller 108 to provide 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 interface 114 may also allow a data storage device 106 to receive power from the host device 104. For example, as shown in Figure 1, a power supply 111 may receive power from the host device 104 via interface 114.

[0018] The NVM110 may include multiple memory devices or memory units. The NVM110 may be configured to store and / or retrieve data. For example, a memory unit of the NVM110 may receive data and messages from controller 108 instructing the memory unit to store the data. Similarly, a memory unit may receive messages from controller 108 instructing the memory unit to retrieve data. In some examples, each of the memory units may be called a die. In some examples, the NVM110 may include multiple dies (i.e., multiple memory units). In some examples, each memory unit may be configured to store relatively large amounts of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0019] In some examples, each memory unit 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, magneto-resistive random-access memory (MRAM) devices, ferroelectric random-access memory (F-RAM), holographic memory devices, and any other type of non-volatile memory device.

[0020] The NVM 110 may include a plurality of flash memory devices or memory units. The NVM flash memory device may include a NAND or NOR-based flash memory device, 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 device, the flash memory device may be divided into a plurality of dies, each die of the plurality of dies includes a plurality of physical blocks or logical blocks, and the plurality of physical blocks or logical blocks may be further divided into a plurality of pages. Each block of the plurality of blocks within a specific memory device may include a plurality of NVM cells. The rows of NVM cells may be electrically connected using word lines to define one of the plurality of pages. Each cell in each of the plurality of pages may be electrically connected to a respective bit line. Further, the NVM flash memory device may be a 2D or 3D device, and may be a single level cell (SLC), multi-level cell (MLC), triple level cell (TLC), or quad level cell (QLC). The controller 108 writes data to the NVM flash memory device at the page level, reads data from the NVM flash memory device, and erases data from the NVM flash memory device at the block level.

[0021] The power supply 111 may supply power to one or more components of the data storage device 106. When operating in standard mode, the power supply 111 may supply power to one or more components using power provided by an external device, such as a host device 104. For example, the power supply 111 may supply power to one or more components using power received from the host device 104 via interface 114. In some examples, the power supply 111 may include one or more power storage components configured to supply power to one or more components when operating in shutdown mode, such as when power is no longer received from an external device. In this way, the power supply 111 may function as an onboard backup power supply. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, and batteries. In some examples, the amount of power that can be stored by one or more power storage components may be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of power stored by one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0022] The volatile memory 112 can be used by the controller 108 to store information. The volatile memory 112 may include one or more volatile memory devices. In some examples, the controller 108 can use the volatile memory 112 as a cache. For example, the controller 108 may store the cached information in the volatile memory 112 until the cached information is written to the NVM 110. As shown in FIG. 1, the volatile memory 112 may consume power received from the power supply 111. Examples of the 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, the optional DRAM 亦可以用于将映射数据,缓冲命令,逻辑-物理(L2P)表,元数据,缓存数据等存储在可选的DRAM 118中。在一些示例中,数据存储设备106不包括可选的DRAM 118,因此数据存储设备106是无DRAM的。在其他示例中,数据存储设备106包括可选的DRAM 118。

[0023] It should be noted that there seems to be an incomplete or incorrect part in the translation of the content of "同样に,任意選択のDRAM118は,マッピングデータ,バッファリングされたコマンド,論理-物理(L2P)テーブル,メタデータ,キャッシュされたデータなどを任意選択のDRAM118に記憶するのに利用されてもよい。" in the above translation. The correct translation should be: Similarly, the optional DRAM 118 may be used to store mapping data, buffered commands, logical-physical (L2P) tables, metadata, cached data, etc. in the optional DRAM 118.The controller 108 may manage one or more operations of the data storage device 106. For example, the controller 108 may 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 may initiate a data storage command to store data in the NVM 110 and monitor the progress of the data storage command. The controller 108 may determine at least one operational characteristic of the storage system 100 and store at least one operational 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 associated with the write command in internal memory or a write buffer 116 before sending the data to the NVM 110. The controller 108 may include circuitry or a processor configured to execute a program for operating the data storage device 106.

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

[0025] One of the promising new areas of industrial development is SSDs that support KV databases. NVMe standard version 2.0 introduced a dedicated application programming interface (API) for supporting these databases at the storage device level.

[0026] A KV database works by storing a certain amount of user data associated with a key that can be addressed as a complete entity, such as a photograph, record, or file. From the host's perspective, a photograph or file can be retrieved using a single key address, rather than multiple addresses containing the data that makes up the photograph. This can potentially abstract and simplify database management for specific applications, resulting in performance advantages for those applications.

[0027] The following are examples of the main differences between standard block storage and key-value (KV) storage, and how the software stack supports them. In block storage, data is stored in fixed-size blocks, addressed by logical block addresses (LBAs), which are a fixed number of bytes, the storage space is allocated in integer multiples of the block size, and logical blocks are associated one-to-one with physical blocks. In contrast, in KV storage, data is stored as unstructured data, addressed by keys, which are of variable length, the storage space is allocated in bytes, and the value is associated with the amount of physical storage required. In fact, there are many KV applications that are implemented in software on standard I / O storage devices.

[0028] Figure 2 shows a conventional KV storage and KV stack according to a specific embodiment. The KV format and KV storage are often 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.

[0029] Therefore, the advantage of supporting KV databases at the storage device level is increased transfer performance per second. Performance improvements occur because the in-host translation layer from KV to block storage is eliminated. As a result, this eliminates two layers of mapping and transaction information, thereby reducing latency while increasing the number of transactions per second and write amplification. Additionally, commands on the bus are reduced to a single transfer for the entire KV pair. This reduction to a single transfer for the entire KV pair presents a second latency reduction, but it is not as significant as the savings from eliminating the translation operation that would otherwise have to be performed in-host. Another advantage of supporting KV databases at the storage device level is the simplification and enablement of compute storage (e.g., near-storage compute). Here, user data on the device is identifiable as a complete unit, as opposed to various parts that may or may not be contiguous in normal storage operation.

[0030] As shown in Figure 2, a conventional KV store includes host software, a block device driver, and a block device. A conventional KV store includes a translation layer within the host that translates KV pairs into LBAs and PBAs when stored in the data storage device. However, support for KV databases in KV stacks, etc., represents a complete unit, and in some embodiments, includes a thin KV library, a KV device driver, and a KV device. Eliminating the translation layer present in conventional KV stores results in improved performance (e.g., transactions per second, TX / s) and reduced write amplification factor (WAF) and read amplification factor (RAF), as well as reduced latency.

[0031] Figure 3A is an exemplary diagram of KV pair data 300 according to a particular embodiment. The KV pair data 300 includes a key 302 and a value 304, where the data, which may be host data for value 304, is addressed by key 302. Key 302 may have a size of about 1 byte to about 64 bytes, and value 304 may have a size of about 0 bytes to about 2 bytes. 32 It may have a size of -1 byte. For example, if value 304 has a size of approximately 0 bytes, then value 304 is empty. It should be understood that the values ​​described above are not intended to be limiting, but rather to provide an example of an embodiment. Since value 304 may have a size larger than a physical word line (e.g., larger than 16KB), value 304 may be split across several word lines, which can result in misalignment. Misalignment can occur when partial data from multiple values ​​is stored on a single word line, or when a portion of value 304 is partially stored on a single word line. Misalignment of stored data can result in multiple reads, which can degrade the quality of service of a data storage device storing misaligned data, and may increase the power consumption of the data storage device.

[0032] Figure 3B is Table 350, showing a command set for a KV database according to a particular embodiment. For illustrative purposes, an embodiment of the storage system 100 in Figure 1 may be referenced herein. The KV system may include a command set that includes, in a non-limiting list, delete commands, list commands, retrieve commands, exist commands, and store commands. The delete command causes the controller 108 to delete key 302 and the value 304 associated with key 302. The list command causes the controller 108 to list the keys that exist in the KV namespace starting from a specified key. The exist command causes the controller 108 to return a status to a command generator, such as the host device 104, indicating whether KV pair data 300 for a specified key exists. The store command causes the controller 108 to store KV pair data in the KV namespace. The retrieve command causes 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 to transfer the KV pair data 300 is specified by either a scatter gather list (SGL) pointer or a physical region page (PRP) pointer in the retrieve command. If the length specified in the retrieve command is shorter 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 length specified in the retrieve command is longer than the length of the KV pair data 300 being retrieved, the controller 108 returns data from the NVM 110, and the length of the KV pair data 300 is returned to the completion queue.

[0033] Therefore, by abstracting database management and storage devices (e.g., SSDs), KV SSDs, due to their inherent structure, enable potential advantages in optimization, simplification, and improvement on both the host and the SSD. Currently, development is underway on SSDs that present a KV database interface instead of traditional block devices. Adding a KV database interface to an SSD adds only a small amount of complexity to the SSD's flash conversion layer and removes many redundant abstractions on the host software side. As a result, performance can be remarkably higher compared to running KV database applications on a traditional file system on an SSD.

[0034] The NVMe Key Value (NVMe-KV) command set is standardized as one of the new I / O command sets supported by the NVM Express® base specification. NVMe-KV enables access to data on an NVMe SSD controller using keys rather than block addresses. The NVMe-KV command set provides keys for storing corresponding values ​​on a non-volatile medium, and then retrieves those values ​​from the medium 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.

[0035] Conventional flash memory operates in 4KB chunks called flash management units (FMUs). This is the basic addressable unit for reading and writing. While not limited to this size, the size can range from 4B to 4GB. In some applications, large values ​​are used, and storing them in flash memory offers significant benefits. In some machine learning (ML) and artificial intelligence (AI) applications, metadata generated during the system's lifetime is valuable. However, metadata may be generated after the data generation time and therefore written to memory later. In some situations, there may even be several pieces of metadata written at different times. Furthermore, when using data later, it is also beneficial to use the associated set of metadata.

[0036] Previously, there was no mechanism to efficiently add metadata to data after it had been written. Metadata is written like regular data and attached to content at the host level. A naive KV storage system adding metadata to a key may read the value information associated with the key. The KV storage system then adds the metadata information to the value and rewrites the entire value, or, in some cases, modifies the value. This approach is inefficient because the host needs to read the entire value associated with the metadata, even if it only wants to add something. Alternatively, another naive system simply writes the metadata to a new key and uses 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.

[0037] Optimized methods for storing metadata in a KV storage system are described further below. The relevant apparatus and methods allow for easy retrieval of the metadata along with the original data, thus improving the performance of the system.

[0038] Figure 4 is a schematic block diagram showing a storage system 400 according to a particular embodiment. The storage system 400 is configured to store metadata for 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, and the storage controller 406 includes a metadata conversion module 408 and a flash conversion layer 410. The storage system 400 may be an implementation of the storage system 100 of Figure 1 according to one or more embodiments, or may be combined with other embodiments. The host 402 may be the host 104 in Figure 1. The storage controller 406 may be the controller 108 in Figure 1. In some embodiments, the storage system 400 may use a dedicated API between the host and the device. In some embodiments, the dedicated API of the storage system 400 may be used in applications associated with ML training and inference based on metadata collection and processing.

[0039] The metadata KV storage command module 404 is configured to indicate to the controller 406 that module 404 is passing metadata associated with a particular key (e.g., operations 502 and 602). The metadata translation module 408 is configured to determine whether there is sufficient space for metadata or corresponding values ​​of key-value pairs (e.g., operations 504 and 604). The flash translation layer 410 is communicatively coupled to the metadata translation module 408 and acts as an intermediary between the host and the storage device (e.g., SSD). The flash translation layer 410 is configured to translate either the KV value or LBA used by the host into a PBA in the storage device during data storage. The flash translation layer 410 is further configured to read, modify, and write any corresponding values ​​(e.g., operations 506, 606), and to create any new keys internally and link them to data keys (e.g., operations 508, 510, 608, 610).

[0040] Figure 5 is a flowchart of Method 500 of a KV metadata storage system according to a specific embodiment. Method 500 creates a value that takes into account the possibility of future additions of metadata. For example, if user information requires 10KB, the value itself may contain 100KB. The beginning of the value contains 10KB of source information, while the remainder of the value is reserved for future metadata additions. In some embodiments, there may be a special command for adding metadata to a specific key.

[0041] In some embodiments, metadata may be generated or collected by the host after the data itself has already been stored on the device. For example, in a recommendation system, the data may be log entries of a user's location at a particular time. The metadata may consist of the user associated with a specific activity (inferred from the host's other interests or applications), such as playing basketball. The system can then better recommend specific activities to this user at future locations.

[0042] Method 500 begins with operation 502, in which the controller (e.g., controller 406 in Figure 4) receives a write command from the host (e.g., host 402 in Figure 4) and writes metadata to a specific data key. In operation 504, the controller determines whether there is sufficient space in the corresponding value to append the new metadata. If there is sufficient space, in operation 506, the controller may read the value internally, modify it, or write it to non-volatile memory (e.g., non-volatile memory 110 in Figure 1). Note that it is not necessary to read the entire value, but only the portion to be modified. If there is not sufficient space in the corresponding value to append the new metadata, in operation 508, the controller creates a new key and value and writes the corresponding value portion. In operation 510, if there was sufficient space in the value, the controller internally links the new key to the original data key to which the new key was to be appended. In some embodiments, the described link is transparent to the host. In other words, the host is unaware that the described link is stored together with or separately from the data value itself.

[0043] Figure 6 is a flowchart illustrating Method 600 of a KV metadata storage system according to a specific embodiment. In the KV metadata storage system of Method 600, the write granularity is that of a full FMU. This can be controlled by the host writing to a full FMU or by the device padding before writing missing data portions at FMU granularity. In this scenario, there is no need to read and correct the corresponding value portions; the controller only needs to write the corresponding empty value portions.

[0044] Method 600 begins with operation 602, in which the controller (e.g., controller 406 in Figure 4) receives a write command from the host (e.g., host 402 in Figure 4) and writes metadata to a specific data key. In operation 604, the controller determines whether there is enough space in the corresponding value to append the new metadata. If there is enough space, in operation 606, the controller may write the value internally to non-volatile memory (e.g., non-volatile memory 110 in Figure 1). Note that it is not necessary to read the entire value, but only the portion that needs to be modified. If there is not enough space in the corresponding value to append the new metadata, in operation 608, the controller creates a new key and value and writes the corresponding value portion. In operation 610, if there was enough space in the value, the controller internally links the new key to the original data key to which the new key was to be appended.

[0045] Figure 7 is a flowchart of Method 700 of a KV metadata storage system according to a particular embodiment. Sometimes, source data can be separated from metadata. Since “values” need to be read from their beginning, starting values ​​with source data can lead to unnecessary read data if the host only needs metadata information. When reading, modifying, and / or rewriting metadata values, the controller of the data storage device (e.g., controller 406 in Figure 4) may decide to sort the values. The host (e.g., host 402 in Figure 4) may indicate that it only wants certain parts of the values ​​so that the controller can stop reading once it has read the metadata the host wants. For example, values ​​may be ordered so that the most recent metadata most likely to be read by the host is written first.

[0046] Method 700 can be applied to ML models. For example, in an embodiment where the entire model is written with a single value or several values ​​according to a logical allocation such as the layer-specific values ​​of NN weights. Since the model is often read sequentially during the inference step, this has the advantage of reducing the overhead for inference. Method 700 optimizes training and tuning when applied to ML models. When training ML and AI models, weights can often change. However, in later stages of training, and when tuning the last layer of the model, only a subset of weights may change. During such an ML application of Method 700, if the host (e.g., host 402 in Figure 4) is trying to update some of the weights, the controller (e.g., controller 406 in Figure 4) may pass the weights that the controller wants to change and their model components (e.g., offsets) in the corresponding layer values. The model components (e.g., offsets) are associated with the representation of the model weights. Note that the model components may also refer to other parts of the model, such as the tree leaf values ​​(in a tree model). The controller updates the corresponding physical position by reading, modifying, and / or writing only the FMU containing the weights that need to be changed.

[0047] Therefore, method 700 begins with operation 702, in which the host tunes the ML model by updating some weights. In operation 704, the controller receives from the host a list of weights in values ​​and their offsets. In operation 706, the controller reads only the FMU from the values ​​corresponding to the offsets passed by the host. In operation 708, the controller modifies and writes the FMU, which includes the updates to the layer values.

[0048] Figure 8 is a flowchart of Method 800 of a KV metadata storage system according to a particular embodiment. After receiving a write command to write metadata to a specific data key, the controller (e.g., controller 406 in Figure 4) may first determine the write granularity of the storage device. In some embodiments, the controller is further configured to make the same determination before receiving a write command to write metadata. The write granularity may be adjusted based on the device's monitored data storage pattern or usage pattern.

[0049] Method 800 begins with operation 802, in which the controller receives a write command from the host to write KV pair data. In operation 804, the controller creates a new key and value and reserves a portion of the value for future metadata additions. The KV namespace value (i.e., the created key and value) is larger than the stored KV pair data to accommodate future metadata additions. For example, the initial KV pair data may require about 10KB, but the KV namespace value itself may include 100KB for future metadata additions. Thus, the value starts with 10KB of source information, while the rest of the value is reserved for future metadata additions. In some embodiments, the memory is non-volatile memory (e.g., non-volatile memory 110 in Figure 1). In operation 806, the controller receives a write command from the host (e.g., host 402 in Figure 4) to write metadata to a specific data key. In operation 808, the controller may determine or adjust the write granularity based on the previous storage or usage patterns of the storage device. The decision of whether to adjust the write granularity may also be based on whether there is sufficient space in the storage device for the extra FMU write overhead, as well as the trade-off of write speed. In some embodiments, the host may indicate the write granularity size to the controller. If the write granularity is less than a full FMU, in operation 810, the controller determines whether there is sufficient space for the corresponding value to append the new metadata. If the write granularity is greater than or equal to a full FMU, in operation 818, the controller determines whether there is sufficient space for the corresponding value to append the new metadata.

[0050] After operation 810, if there is sufficient space in the corresponding value, in operation 812 the controller may read the value internally, modify it, or write it to non-volatile memory (e.g., non-volatile memory 110 in Figure 1). Note that it is not necessary to read the entire value, but only the portion that needs to be modified. If there is not enough space in the corresponding value to append the new metadata, in operation 814 the controller creates a new key and value and writes the corresponding value portion. In operation 816, if there was sufficient space in the value the controller internally links the new key to the original data key to which the new key was to be appended.

[0051] After operation 818, if there is sufficient space in the corresponding value, in operation 820 the controller may write the value internally to non-volatile memory (e.g., non-volatile memory 110 in Figure 1). Note that it is not necessary to read the entire value, but only the part that needs to be modified. If there is not enough space in the corresponding value to append the new metadata, in operation 822 the controller creates a new key and value and writes the corresponding value portion. In operation 824, if there was sufficient space in the value the controller internally links the new key to the original data key to which the new key was to be appended.

[0052] In one embodiment, the data storage device includes a memory device and a controller coupled to the memory device, the controller being configured to receive data from a host, store the data in a KV namespace, the KV namespace containing keys and values, the keys addressing the values, the values ​​containing a plurality of flash management units (FMUs), and to receive a write command from a host for writing second data to the KV namespace, the write command for writing metadata being received following the reception of the KV pair data, and to store the second data in the KV namespace.

[0053] The second data is metadata, where the metadata keys correspond to the data keys. The controller is further configured to receive commands from the host to update at least one weight of a machine learning (ML) model. The commands further include commands to update at least one model component associated with at least one weight. The controller is further configured to read only the FMUs of multiple FMUs that correspond to at least one model component. The controller is further configured to write and modify the FMUs of multiple FMUs that contain at least one weight.

[0054] In another embodiment, the 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, create a KV namespace in which 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), store the KV pair data in the KV namespace, receive a write command from the host for writing metadata to the KV namespace, the write command for writing metadata is received following the reception of the KV pair data, and store the metadata in the KV namespace.

[0055] The size of the KV pair data values ​​is smaller than the size of the KV namespace values. The controller is further configured to reserve a portion of the KV namespace values ​​to store metadata, the portion being the remainder of the KV namespace values ​​after the KV pair data has been stored in the KV namespace. The controller is further configured to determine whether the size of the metadata is less than or equal to the portion. 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 the metadata, modify the metadata, or write the metadata to the KV namespace. Based on the determination that the size of the metadata is greater than or equal to the portion, the controller is further configured to create a new KV namespace containing the keys and values. Based on the determination that the size of the metadata is greater than or equal to the portion, the controller is further configured to store the metadata in the new KV namespace. The controller is further configured to internally link the keys of the new KV namespace to the keys of the KV namespace. The controller is further configured to determine whether the write granularity is greater than or equal to a 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 metadata to the KV namespace. The controller is further configured to adjust the write granularity based on the data storage pattern and usage pattern. The size of the KV pair data values ​​is between 4 bytes and 4 gigabytes. The memory device is non-volatile memory.

[0056] In yet another embodiment, the data storage device includes means for storing data and a controller coupled to the means for storing data, the controller comprising a metadata translation module configured to determine whether there is sufficient space for metadata values ​​and a flash 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 receiving key-value (KV) pair data from a host, the KV pair data comprising a key and a value, the key addressing the value, the value comprising a plurality of flash management units (FMUs), creating a KV namespace, storing the KV pair data in the KV namespace, receiving a write command from the host for writing metadata to the KV namespace, the write command for writing metadata is received following the reception of the KV pair data, storing the metadata in the KV namespace, and reserving a portion of the value in the KV namespace for storing the metadata, the portion being the remainder of the value in the KV namespace after the KV pair data has been stored in the KV namespace.

[0057] While the above applies to embodiments of the present disclosure, other embodiments and further embodiments of the present disclosure can be devised without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the following claims.

Claims

1. A data storage device, Memory devices and, The memory device is coupled to a controller, and the controller is The data is a key-value (KV) pair of data, and the data is received from the host. The aforementioned data is stored in the KV namespace, The aforementioned KV namespace includes keys and values, The aforementioned key addresses the aforementioned value, The aforementioned value includes multiple flash management units (FMUs), A write command for writing second data to the KV namespace, wherein the write command for writing metadata is received from the host following the reception of the KV pair data, A data storage device configured to store the second data in the KV namespace.

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

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

4. The data storage device according to claim 3, wherein the command further includes a command for updating at least one model component associated with the at least one weight.

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

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

7. A data storage device, Memory devices and, The memory device is coupled to a controller, and the controller is Receive key-value (KV) pair data from the host, The aforementioned KV pair data includes key and value, The aforementioned key addresses the aforementioned value, The aforementioned value includes multiple flash management units (FMUs), A KV namespace is created in which the KV namespace includes keys and values. The KV pair data is stored in the KV namespace. A write command for writing metadata to the KV namespace, wherein the write command for writing metadata is received from the host following the reception of the KV pair data, A data storage device configured to store the aforementioned metadata in the KV namespace.

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

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

10. The data storage device according to 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 according to claim 10, wherein the controller is further configured to read the metadata, modify the metadata, or write the metadata to the KV namespace, based on a determination that the size of the metadata is less than or equal to the portion thereof.

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

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

14. The data storage device according to 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 according to claim 7, wherein the controller is further configured to determine whether the write granularity is full FMU or greater.

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

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

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

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

20. A data storage device, Means of storing data, The system comprises a controller coupled to means for storing the aforementioned data, and the controller is A metadata transformation module configured to determine whether there is sufficient space in the metadata value, The system comprises a flash conversion layer that is communicatively coupled to the metadata conversion module and configured to convert a KV value or logical block address to a physical block address, The aforementioned controller Receive key-value (KV) pair data from the host, The aforementioned KV pair data includes key and value, The aforementioned key addresses the aforementioned value, The aforementioned value includes multiple flash management units (FMUs), A KV namespace is created in which the KV namespace includes keys and values. The KV pair data is stored in the KV namespace. A write command for writing metadata to the KV namespace, wherein the write command for writing metadata is received from the host following the reception of the KV pair data, The metadata is stored in the KV namespace, A data storage device configured to reserve a portion of the value of the KV namespace for storing metadata, wherein the portion of the value is the remainder of the value of the KV namespace after the KV pair data has been stored in the KV namespace.

Images