Machine comprising a key-value storage device and method of operating a key-value storage device

Abstract

Machines including key-value storage devices and methods of operating key-value storage devices are disclosed. The key-value (KV) storage device can include a storage device, a KV translation layer, a KV interface, a block interface, and a block emulator. The storage device is to store a first object and a second object. Each object can include data associated with a key. The KV translation layer can translate the key to a physical address of the stored data in the storage device. The KV interface can receive a KV request involving the object, the block interface can receive a block request involving the object. The block emulator can generate a KV request containing a key generated from the block request.

Description

TECHNICAL FIELD

[0001] The inventive concept relates generally to storage devices, and more particularly to Key-Value (KV) storage devices that can handle block requests. BACKGROUND

[0002] Key-Value Solid State Drives (KV-SSDs) can provide an alternative way to store and access data. Non-KV based storage devices can provide Logical Block Addresses (LBAs), which a Solid State Drive (SSD) maps to Physical Block Addresses (PBAs) on the device. In the case of a KV-SSD, a host can assign a key to data. In the case that the key is provided to be unique with respect to other keys on the KV-SSD, the data can be stored on the KV-SSD. This results in a reduced instruction set for the KV-SSD: typically, the instructions can include a command to store a value associated with a key (PUT), a command to retrieve a value associated with a key (GET), and a command to delete a value associated with a key (DELETE) (the specific command names can vary).

[0003] However, while KV-SSDs have advantages in their operation, many applications still use block commands to read and write data to storage devices. Currently, KV-SSDs are unable to handle such block commands.

[0004] There is a need for KV-SSDs (and other KV storage devices) to handle block requests. SUMMARY

[0005] Some embodiments of the inventive concept provide a machine comprising a Key-Value (KV) storage device, wherein the KV storage device comprises: a storage device for a first object and a second object, the first object comprising first data associated with a first key and the second object comprising second data associated with a second key; a KV translation layer to translate the first key to a first physical address in the storage device storing the first data and to translate the second key to a second physical address in the storage device storing the second data; a KV interface to receive a first KV request involving the first object; a block interface to receive a block request involving the second object; and a block emulator to generate a second KV request comprising the second key from the block request.

[0006] Some embodiments of the inventive concept provide a method comprising: receiving a block request from a source at a block interface emulator for a KV storage device; determining a set of KV requests to the KV storage device to emulate the received block request; executing the set of KV requests to the KV storage device to generate a result; and returning the result from the KV storage device to the source.

[0007] Some embodiments of the inventive concept provide a product including a non-transitory storage medium, wherein the non-transitory storage medium has instructions stored on the non-transitory storage medium, which, when executed by a machine, cause: receiving a block request from a source at a block interface emulator for a key-value (KV) storage device; determining a set of KV requests for the KV storage device to emulate the received block request; executing the set of KV requests on the KV storage device to generate a result; and returning the result from the KV storage device to the source. Attached Figure Description

[0008] FIG. 1 A system including a key-value solid-state drive (KV-SSD) capable of processing block requests is shown according to an embodiment of the inventive concept.

[0009] FIG. 2 It shows FIG. 1 Additional details about the system.

[0010] FIG. 3 It shows FIG. 1 Details of the KV-SSD.

[0011] FIG. 4A-4B An embodiment of the inventive concept is shown for implementation. FIG. 3 Various layouts of the block simulator.

[0012] FIG. 5 It shows FIG. 3 A block emulator that converts block requests into key-value requests.

[0013] FIG. 6 An embodiment based on the inventive concept is shown. FIG. 3 Some additional details about the block simulator.

[0014] FIG. 7 The storage of an embodiment according to the inventive concept is shown. FIG. 3 Some details about the metadata in the metadata storage device.

[0015] FIG. 8 Some example operations associated with the processing of block write requests according to one embodiment of the inventive concept are shown.

[0016] FIG. 9 Some example operations associated with the processing of block read requests according to one embodiment of the inventive concept are shown.

[0017] FIG. 10 Some example operations associated with the processing of block trimming requests according to one embodiment of the inventive concept are shown.

[0018] FIG. 11Some example operations associated with the processing of block write requests according to another embodiment of the inventive concept are shown.

[0019] FIG. 12 It shows the relationship with FIG. 5 The metadata response FIG. 11 Here are some example operations associated with the update of the block write request.

[0020] FIG. 13 Some example operations associated with the processing of a second block write request according to another embodiment of the inventive concept are shown.

[0021] FIG. 14 It shows the relationship with FIG. 5 The metadata response FIG. 13 Some example operations associated with the second update of the block write request.

[0022] FIG. 15 Some example operations associated with the processing of block read requests according to another embodiment of the inventive concept are shown.

[0023] FIG. 16 Some example operations associated with the processing of block trimming requests according to another embodiment of the inventive concept are shown.

[0024] FIG. 17 It shows the relationship with FIG. 5 The metadata response FIG. 16 Here are some example operations associated with the update of the block trimming request.

[0025] FIG. 18 An embodiment of the invention is shown for use. FIG. 1 A flowchart illustrating an example process for handling block requests in a KV-SSD.

[0026] FIG. 19A-19B An embodiment of the invention is shown for use. FIG. 1 A flowchart illustrating an example process for handling block write requests in a KV-SSD.

[0027] FIG. 20A-20B An embodiment of the invention is shown for use in... FIG. 1 A flowchart illustrating an example process of updating metadata when a KV-SSD processes a block write request.

[0028] FIG. 21A-21C An embodiment of the invention is shown for use. FIG. 1 A flowchart illustrating an example process for handling block read requests in a KV-SSD.

[0029] FIG. 22A-22C An embodiment of the invention is shown for use.FIG. 1 A flowchart of an example process for handling block trimming requests in KV-SSD. Detailed Implementation

[0030] Detailed reference will now be made to embodiments of the invention, examples of which are illustrated in the accompanying drawings. In the following detailed description, several specific details are set forth to enable a thorough understanding of the invention. However, it should be understood that those skilled in the art can practice the invention without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments.

[0031] It will be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module without departing from the scope of the invention.

[0032] The terminology used in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. It will also be understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Components and features in the drawings are not necessarily drawn to scale.

[0033] By introducing the ability to receive block commands and convert those commands into key-value commands, KV-SSDs can be accessed by existing applications that use block commands without reprogramming or recompiling the applications, and without introducing a block interface storage device for application use.

[0034] There are at least two ways in which a KV-SSD can be enhanced to provide block interface emulation. In one embodiment of the inventive concept, the SSD may include an external block interface and a key-value (KV) interface, and has a block emulator physically located between the block interface and the KV flash translation layer. In another embodiment of the inventive concept, a device driver running on a host machine may receive block requests from an application and translate those block requests into KV requests, which can then be provided to the KV interface on the KV-SSD.

[0035] One problem with attempting to emulate block commands using KV commands is that direct mapping of commands (PUT for write, GET for read, DELETE for trim) may not work. For example, it might happen that a write request stores data at a specific LBA, and the provided LBA is used as the key on the KV-SSD. A simple conversion from write command to place command will work if an object with that key does not exist. However, if the KV-SSD already stores an object with that key, the place command will return an error.

[0036] This problem is complicated by the fact that write commands can span multiple LBAs: even if the LBA including the base address of the write command is not used as a key, the data still overlaps with data stored in another object. For example, consider a block approximately 4KB in size that has previously had data written to an LBA starting at address 0x2000. A write command to data starting at address 0x1000 will not occur, as if that write command overwrote any data already on the KV-SSD. However, if the write command includes more than approximately 4KB of data, at least a portion of the data previously written at address 0x2000 will be overwritten, but this fact may not be detectable using a direct mapping of the commands.

[0037] Similarly, read requests to the block interface storage device will work even if the data stored at the LBA has previously been invalidated. The block interface storage device will simply read any data stored at the corresponding PBA: this data may or may not be suitable for the application. However, retrieval commands sent to the KV-SSD for non-existent keys will return an error.

[0038] The prune command can cause a similar problem. If the prune command is used to delete data that is only part of a previously written LBA range, KV-SSD will attempt to delete objects that do not exist (because there will be no object with that LBA as a key). This will also cause KV-SSD to return an error.

[0039] Therefore, the block interface simulator may need to perform additional operations beyond mapping commands based on their names. Specifically, the block interface simulator can be used to check whether an LBA scope overlaps with an existing object storing data for other LBAs and determine how to handle such events. Furthermore, if overlap exists, the existing object can be partially or completely modified via write or prune commands.

[0040] It is important to note that the expected behavior of KV-SSD block interface emulation can be similar to that of block-based storage devices. Given an initial arrangement of “blocks,” the same or similar arrangements of “blocks” can exist after any operation, but with appropriate data modifications. Thus, for example, there could be a situation where “Object 1” could include data written to LBA0 through LBA3, “Object 3” could include data written to LBA4 through LBA5, and “Object 2” could include data written to LBA7 through LBA14. If new data is received and stored at LBA2 through LBA7, this partially overwrites the data in “Object 1” and “Object 2” (and completely overwrites the data in “Object 3”), resulting in an arrangement where “Object 1” includes data written to LBA0 through LBA1, “Object 4” includes new data written to LBA2 through LBA7, and “Object 2” includes data written to LBA8 through LBA14. Then, if a read command is sent to read data at LBA6 through LBA8, that data can be retrieved from “Object 4” and “Object 2” and returned.

[0041] Some non-limiting advantages of the embodiments described in the inventive concept may include a single device supporting both KV interfaces and block interfaces, rather than using separate devices for each type of interface. Furthermore, the block interface emulator can provide increased security. Because read commands for LBAs that do not store data (i.e., for LBAs that do not have corresponding objects) can be detected by the KV-SSD returning an error, security can be enhanced by detecting unauthorized reads and block accesses: the KV-SSD can then be locked to prevent intruders from accessing valid data from the KV-SSD.

[0042] Various algorithms exist that can be used to implement embodiments of the inventive concept. One such algorithm may be called a "split-merge" algorithm, and another may be called an "interval tree" algorithm.

[0043] When using a split-and-merge algorithm, each LBA can be stored as a separate object. The key for each object can be associated with an LBA. For example, the actual LBA can be used as the key, or the key can be generated from the LBA (e.g., using a hash function that is likely to avoid hash collisions). When using a range tree algorithm, metadata can be used to store which LBAs are associated with the object. In such embodiments of the inventive concept, the key can be generated in any suitable manner (because the key does not necessarily have to be associated with an LBA that the data spans).

[0044] For example, the scenario where block write commands across LBA2 to LBA7 are received is described. Depending on the algorithm used, there are at least two variations in which embodiments of the inventive concept can operate.

[0045] In the split-merge algorithm, each LBA is associated with a separate block. Therefore, when a block write command to write data to LBA2 through LBA7 is received, the block write command is split into six distinct place commands, each associated with a different key. Where data already exists (e.g., in LBA2 through LBA5 and LBA7), those objects are replaced with new objects storing the new data, and the old data is lost.

[0046] In the "interval tree" algorithm, metadata can be used to store which LBAs are associated with different objects. Therefore, metadata can indicate that "Object 1" includes data spanning LBA0 to LBA3, "Object 2" includes data spanning LBA7 to LBA13, and "Object 3" includes data spanning LBA4 to LBA5. In this embodiment, "Object 4" can be added along with metadata indicating that the data spans LBA2 to LBA7. "Object 1" can be modified to delete data previously associated with LBA2 to LBA3, and "Object 2" can be modified to delete data previously associated with LBA7. Such modifications can be implemented in any suitable manner. For example, if the KV-SSD supports commands that can prune data from one end or the other of an object, such commands can be used. Alternatively, an object can be read, internally modified to eliminate unwanted data, and then rewritten as an updated object with the same key. Furthermore, in some examples, "Object 3" can be deleted.

[0047] This describes the scenario where a block read command requesting data from LBA6 through LBA8 is received. If the "split-merge" algorithm is used, each LBA is stored as a separate object, those objects can be read, and the data is merged. If the "range tree" algorithm is used, an object can store multiple LBAs, and metadata can then be used to determine which objects store data. Continuing the example above, the metadata could indicate that "Object 4" includes LBA2 through LBA7 (and therefore includes two of the requested LBAs), and "Object 2" includes LBA8 through LBA13 (and therefore includes one of the requested LBAs). "Object 4" and "Object 2" can then be read, data is extracted from the values ​​in those objects, and this data is then merged and returned to the application via the block interface simulator.

[0048] The scenario where a block pruning command is received can also be described, requesting the deletion of data in LBA2 through LBA7. If a split-merge algorithm is used, the block pruning command can be split into independent delete commands (one delete command per LBA). Alternatively, if a range tree algorithm is used, the metadata can be used to determine which objects are affected by the block pruning command. As noted, when the block pruning command is received, "Object 1" includes data spanning LBA0 through LBA3, "Object 2" includes data spanning LBA7 through LBA13, and "Object 3" includes data spanning LBA4 through LBA5. Therefore, the pruning command involves deleting the tail of the data in "Object 1," the head of the data in "Object 2," and the entirety of "Object 3." Similar to block write commands, "Object 1" can be modified to delete data previously associated with LBA2 through LBA3, and "Object 2" can be modified to delete data previously associated with LBA7. Such modifications can be implemented in any suitable manner. For example, if the KV-SSD supports commands that can prune data from one end or the other of an object, such commands can be used. Optionally, an object can be read, internally modified to remove unwanted data, and then rewritten as an updated object with the same key. In some examples, "object 3" can be deleted.

[0049] While the above description uses tables to identify which objects store data associated with which LBA ranges, the disclosed system can use other implementations. For example, the disclosed system could implement a range tree to manage metadata information. The tree structure could be used for workloads with sequential writes (such as logs).

[0050] In some embodiments of the inventive concept, the disclosed system can create a hybrid model in which both interval trees and LBAs, stored as independent blocks (or small block ranges), are used. For example, the default structure could be to use interval trees. Then, if a node becomes sufficiently fragmented (i.e., fragmentation exceeds a threshold, or the number of LBAs in a node drops below a certain threshold), the split-merge method described above can be used for the data in the segmented nodes. Of course, if a previously segmented node is overwritten again with sufficiently large sequential data, then that node can return to the interval tree.

[0051] Some advantages of embodiments of the inventive concept described herein may include, but are not limited to, the disclosed system configured to support per-namespace configuration, user-defined key sizes (e.g., approximately 4 bytes), user-defined block sizes (e.g., approximately 512 bytes, approximately 4KB, approximately 8KB, approximately 16KB, approximately 32KB, etc.), and user-defined ordering or atomicity (which may conform to the semantics of target device protocols such as AT Attachment (ATA), Serial Attached Small Computer System Interface (SCSI) (SAS), and Non-Volatile Memory High Speed ​​(NVMe) etc.).

[0052] Components supporting the operations described herein may include, but are not limited to, splitters, mergers, and batch command processors (for issuing multiple KV commands suitable for simulation), as further described below. In some examples, a splitter can split large data into a series of fixed-size blocks, generate a series of keys mapping the blocks, create batch operations for placement using a series of (key, block) operations, issue batch placement commands, and return completion to the user with the first key upon processing. A merger can merge small blocks into large data, generate a series of keys for retrieving blocks, create batch operations for retrieval using the appropriate keys, issue batch retrieval commands, and merge the retrieved blocks into a single large block upon processing, returning completion and the first key to the user.

[0053] Various pruning semantics can be supported. These pruning semantics can include: Non-deterministic TRIM (each read command on the LBA can return different data after pruning), Deterministic TRIM (DRAT) (all read commands on the LBA should return the same data or become deterministic after pruning), and Deterministic Read Zero after TRIM (RZAT) (all read commands on the LBA should return zero after pruning).

[0054] FIG. 1 A machine comprising a key-value solid-state drive (KV-SSD) configured to process block requests is shown as an embodiment according to the inventive concept. FIG. 1 The image shows machine 105. Machine 105 may include processor 110. Processor 110 may be any type of processor. Although FIG. 1 A single processor 110 in machine 105 is shown, but machine 105 may include any number of processors, each of which may be a single-core processor or a multi-core processor, and may be mixed in any suitable combination.

[0055] Machine 105 may also include memory 115. Memory 115 may be any type of memory (such as flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory, ferroelectric random access memory (FRAM), or non-volatile random access memory (NVRAM) (such as magnetoresistive random access memory (MRAM)). Memory 115 may also be any suitable combination of different memory types. Machine 105 may also include a memory controller 120 for managing access to memory 115.

[0056] Machine 105 may include key-value storage device 125 (shown as a key-value solid-state drive (KV-SSD)). KV-SSD 125 can access data using a key-value interface. An application or operating system can provide a key (such as key 130 for object 135) to KV-SSD 125, which can then map that key to a location on KV-SSD 125. KV-SSD 125 can then access and retrieve the value stored at that location on KV-SSD 125 (shown as data 140 for object 135). Unlike the relatively complex command sets provided by some file systems on the storage device, the KV-SSD 125 can provide a simplified command set, such as: GET (for retrieving a value associated with a provided key), PUT (for storing a provided value on the KV-SSD, the provided value being associated with a provided key or a key generated by the KV-SSD, the key generated by the KV-SSD can be returned), and ERASE (for deleting a value associated with a key provided from the KV-SSD and removing the key-value association from the KV-SSD table). The KV-SSD 125 may also support other commands, and may use command names different from those shown, but the principle is generally the same as described. The KV-SSD 125 can also be replaced by any other storage device that supports object storage as described below in embodiments of the inventive concept.

[0057] Processor 110 can run device drive 145 that supports access to KV-SSD 125. Although FIG. 1 KV storage device 125 is specifically shown as a KV-SSD, but embodiments of the inventive concept can be extended to any type of KV storage device, regardless of its underlying hardware or storage mechanism.

[0058] although FIG. 1Machine 105 is described as a server (which may be a standalone server or a rack server), but embodiments of the inventive concept may include any type of machine 105 without limitation. For example, machine 105 may be replaced by a desktop computer or laptop computer or any other machine that may benefit from embodiments of the inventive concept. Machine 105 may also include dedicated portable computing machines, tablet computers, smartphones, and other computing machines. Furthermore, applications that can access data from the KV-SSD 125 may reside in another machine, which is separate from machine 105 and accesses machine 105 via a network connection traversing one or more networks of any type (wired, wireless, global, etc.).

[0059] FIG. 2 It shows FIG. 1 Additional details about Machine 105. FIG. 2 Typically, machine 105 includes one or more processors 110, which may include a memory controller 120 and a clock 205, which can be used to coordinate the operation of components of machine 105. Processor 110 may also be coupled to memory 115, which, for example, may include random access memory (RAM), read-only memory (ROM), or other state-keeping media. Processor 110 may also be coupled to storage device 125 and to network connector 210, which may be, for example, an Ethernet connector or a wireless connector. Processor 110 may also be connected to bus 215, to which user interface 220 and input / output interface ports, as well as other components, may be attached. The input / output interface ports may be managed using input / output engine 225.

[0060] FIG. 3 It shows FIG. 1 Details of the KV-SSD. FIG. 3 In this device, the KV-SSD 125 may include a Host Interface Logic (HIL) 305, an SSD controller 310, and various flash memory chips 315-1 to 315-8 (also referred to as "flash storage devices"), which can be organized into various channels 320-1 to 320-4. The Host Interface Logic 305 manages the KV-SSD 125 with other components (such as...). FIG. 1Communication between the processor 110 and the host interface logic 305. The host interface logic 305 can also manage communication with devices remote from the KV-SSD 125 (i.e., devices that may not be considered part of the machine 105 but communicate with the KV-SSD 125, for example, via one or more network connections). These communications may include read requests for reading data from the KV-SSD 125, write requests for writing data to the KV-SSD 125, and delete requests for deleting data from the KV-SSD 125. The host interface logic 305 can manage an interface spanning only a single port, or it can manage an interface spanning multiple ports. Optionally, the KV-SSD 125 may include multiple ports, each of which may have a separate host interface logic 305 to manage the interface spanning that port. The disclosed system may also include a combination of the above embodiments of the inventive concept (e.g., an SSD with three ports may have one host interface logic managing one port and a second host interface logic managing the other two ports).

[0061] SSD controller 310 can use flash controller ( FIG. 3 (not shown) to manage read and write operations, garbage collection operations, and other operations on flash memory chips 315-1 to 315-8.

[0062] In block-based storage devices (specifically, block-based SSDs), the host can assign logical block addresses (LBAs) to data, and the storage device can map LBAs to physical block addresses (PBAs). The storage device can maintain a record of these mappings, thus freeing the SSD and the host from having to ensure that the host is up-to-date with the data's current PBA. The host can use the LBA; the storage device maps the LBA to the PBA and returns the appropriate information. If data is internally moved to the storage device (as can happen during, for example, data overwrite or garbage collection on an SSD), such data movement occurs without notifying the host (accompanied by updating the mapping with the new PBA of the data). Such a structure that maps LBAs to PBAs can be called a translation layer (or, specifically, in the context of SSDs and other devices using flash memory, a flash translation layer).

[0063] Conversely, as discussed above, KV-SSDs can manage data differently from block-based storage devices. Data (which may be called values ​​or data values) can be assigned keys (which may be called object keys), rather than data being assigned LBAs. Aside from the terminology change (“object key” replaces “LBA”), other differences can exist between object keys and LBAs (and between KV-SSDs and block-based SSDs). The block size in a block-based SSD is fixed at manufacturing time. For example, in a block-based SSD with blocks of approximately 4KB, each block is approximately 4KB in size: there is no flexibility. This fact means that LBAs are also divided into units of approximately 4KB to efficiently map to blocks on the SSD. KV-SSDs, on the other hand, allow for flexible sizes of data values. For example, to specify some possible sizes, objects can be stored in units such as approximately 512B, approximately 4KB, approximately 8KB, approximately 16KB, and approximately 32KB. Furthermore, the size of the data values ​​can change as sorting and / or atomicity may be altered (e.g., from approximately 4 bytes to approximately 255 bytes). For example, KV-SSDs can use protocols such as ATA, SAS, NVMe, etc. These arrangements allow for greater flexibility in how data is stored compared to the arrangements that can be provided by block-based SSDs.

[0064] Therefore, the KV-SSD 125 may include a mapping from object keys to addresses where data values ​​are stored (such as a translation layer 325), rather than a flash translation layer. The translation layer 325 can map from object keys to addresses where the corresponding data is stored on the KV-SSD 125. The translation layer 325 may also store additional data. For example, the additional data may relate to the size of the object (and therefore how the entire object can be stored on the KV-SSD 125).

[0065] Finally, to support block request processing, the host interface logic 305 may include a block emulator 330 and / or a metadata storage device 335. The block emulator 330 can use KV storage device semantics to emulate block request processing. The metadata storage device 335 can be used to store metadata related to block requests. See below for further details. FIG. 12 Further discussion is needed regarding information that can be stored as metadata in metadata storage device 335. Although FIG. 3 The host interface logic 305 is shown as including a block emulator 330 and a metadata storage device 335, but various embodiments of the inventive concept may include different configurations of the KV-SSD 125 where these components are located elsewhere within the KV-SSD 125. For example, the block emulator 330 and / or the metadata storage device 335 may be located within the SSD controller 310 or elsewhere. FIG. 1 The device driver 145 is managed.

[0066] although FIG. 3 The KV-SSD 125 is shown as comprising eight flash memory chips 315-1 to 315-8 organized into four channels 320-1 to 320-4, but embodiments of the inventive concept can support any number of flash memory chips organized into any number of channels. Similarly, although FIG. 3 The structure of a KV-SSD is shown, but other storage devices (e.g., hard disk drives) can be implemented using different but similarly beneficial structures, including both security and data deduplication.

[0067] FIG. 4A-4B Various layouts of the KV-SSD 125 and device drives 145-1 and 145-2 according to embodiments of the inventive concept are shown. FIG. 4A In the diagram, the KV-SSD 125 is shown as including a flash memory chip 315, a conversion layer 325, and a block emulator 330 (and also including, although in...) FIG. 4A Not shown FIG. 3 The metadata storage device 335). The KV-SSD 125 may also include a KV interface 405 for receiving KV requests and a block interface 410 for receiving block requests. The KV interface 405 and block interface 410 can communicate with KV device driver 145-1 and block device driver 145-2, respectively. KV device driver 145-1 and block device driver 145-2 may each include interfaces for receiving data from... FIG. 1 The processor 110 (and any software executing in the processor 110) receives requests via interfaces 415 and 420. Note that requests received via KV interface 405 can bypass the block emulator 330 and be processed directly.

[0068] On the other hand, FIG. 4B In the diagram, the KV-SSD 125 is shown as a standard KV-SSD. (Compared to...) FIG. 4A In comparison, FIG. 4B In the KV-SSD 125, the block emulator 330 and block interface 410 can be omitted. Instead, the block device driver 145-2 may include the block emulator 330 (and also includes, although...) FIG. 4B Not shown FIG. 3 The metadata storage device 335) is used to process data from the interface (e.g., block interface) 420. FIG. 1 The simulation of block requests received by processor 110 (and any software executed in processor 110). Both KV device driver 145-1 and block device driver 145-2 can issue KV requests to KV interface 405 for processing by KV-SSD 125.

[0069] FIG. 5 It shows FIG. 3 The block emulator 330 converts block requests into key-value requests. FIG. 5 In this context, the block emulator 330 can receive block requests 505. In embodiments of the inventive concept described below, block request 505 can be a write request, a read request, or a trim (delete) request, but block request 505 can also include other block requests. In response to receiving block request 505, the block emulator 330 can generate a set of KV requests 510, each of which can include a key (or KV key) 130 (of course, different requests can include different keys). Although in FIG. 5 Not shown in the diagram, but depending on the specific KV request 510 generated, the KV request 510 may also include the parts to be written. FIG. 1 Data from the KV-SSD 125.

[0070] Key 130 can be generated using any suitable method. For example, an LBA can be used as the key of an object without modification. Alternatively, an LBA can be hashed (or manipulated otherwise) to generate key 130. In some examples, key 130 can be randomly generated or assigned using a table stored somewhere that maps specific LBAs to specific keys.

[0071] One reason why a single block request 505 can lead to multiple KV requests 510 can be based on the way the block request is sent. Although there may be practical limitations on the amount of data to be written to, read from, or deleted from the storage device (e.g., physical capacity limitations of the storage device), there may be no additional practical limitations on how much data can be written, read, or deleted in a single block request.

[0072] For example, each block can exist (as per...) FIG. 1 The processor 110 (or any application running on it) is expected to be approximately 4KB in size. Block request 505 can request to write some amount of data, for example, to LBA 0x1000. If the amount of data to be written is actually approximately 8KB in size, then that amount of data can span two blocks on the block-based storage device: the block at address 0x1000 and the block at address 0x2000. Similarly, larger amounts of data spanning more than two blocks can also be... FIG. 1 The processor 110 writes to it. Block-based storage devices can handle such requests.

[0073] One direct implementation of the block emulator 330 is to assign a key to data based on the LBA provided in the write request. Therefore, the KV request 510 can use the key 0x1000 to store approximately 8KB of data.

[0074] whenFIG. 1 A problem arises when processor 110 issues a request affecting some data written in a block different from LBA 0x1000 but actually written in that block. For example, consider the following scenario: FIG. 1 The processor 110 issues a request to read data at LBA 0x2000. A block-based storage device can handle such requests: any data stored at a specified LBA can be read and returned. FIG. 1 The processor 110. However, when the block emulator 330 attempts to determine the key associated with LBA 0x2000, such a key may not be found (because a block request with that specific LBA has not yet been generated by the processor 110). FIG. 1 If the KV-SSD 125 receives the signal, the block emulator 330 will return an error. FIG. 1 The problem worsens if the processor 110 attempts to write "new" data to LBA 0x2000. The block emulator 330 interprets the block write request as storing data in an LBA that has not yet been written to. Therefore, FIG. 1 The KV-SSD 125 will ultimately store the data for LBA 0x2000 in two different objects: once in the object for LBA 0x1000 (the first write request), and once in the object for LBA 0x2000. Therefore, from... FIG. 1 The data returned by the KV-SSD 125 depends on which LBA is requested in the block read request and how much data will be read. Furthermore, it's possible for data for the same LBA to be stored three or more times (written using different LBAs): theoretically, this applies when different LBAs are provided for each block write request. FIG. 1 The KV-SSD 125 will ultimately store any number of different data for the “same” LBA in different objects.

[0075] Embodiments of the inventive concept include those for use in FIG. 1 Two different methods for storing data on the KV-SSD 125 avoid the aforementioned problems. See below for details. FIG. 8-10 One such method discussed can be called the "split-merge" method; see below. FIG. 11-17 Another approach discussed uses metadata to manage data overlap and can be called the interval tree approach.

[0076] In the split-merge method, a single block request 505 (e.g., a single block write request) can be split into multiple KV write requests, each targeting a different LBA. That is, if block request 505 spans multiple different blocks, the block emulator 330 can split the request into multiple individual KV write requests, each of which can be used to write data to a different block. (Note that the number of KV write requests generated can depend on both the size of the data written in the block write request and the size of the individual blocks, which can be user-defined and even vary for different users or different applications.) Similarly, a block read request that spans multiple blocks can be split into multiple distinct KV read requests, one for each affected block, after which data from the individual KV read requests can be merged to generate the result of the block read request. (Again, the number of distinct KV read requests can depend on the amount of data to be read and the defined size of the individual blocks.) Block pruning requests can also result in multiple KV delete requests (again, depending on the amount of data to be deleted and the defined size of the individual blocks).

[0077] Using the split-and-merge approach, a given block operation involving n blocks can be divided into n key-value operations (where n is an integer greater than 1), and the results are then merged together. The split-and-merge approach works well when the workload involves many small random writes (i.e., given a transaction history, there is little pattern as to what LBA will be requested next, and each transaction tends to involve no more than a few blocks at a time). However, some workloads may not meet these conditions.

[0078] The interval tree approach works well for workloads involving sequential writes, such as logs. Instead of storing each block as a separate object, a single object can store data for multiple objects. The interval tree can be used to track which objects include data for which blocks. Then, the interval tree can be used to determine if a particular block operation involves any overlap with existing objects: those objects can then be identified and processed as needed.

[0079] For example, to handle a block write request, at least two possibilities exist. In the first case, the new LBA may not be related to the one already stored in the memory. FIG. 1 In the KV-SSD 125, any existing blocks may overlap; in the other case, some overlap may exist. If there is no overlap, the new data can be stored in an object with the newly selected key, and the new node can be inserted into the range tree. If some overlap exists, existing objects that overlap with the new address range can be updated to eliminate the overlapping addresses, and the range tree can be updated to reflect the new address range. FIG. 1Updating objects on the KV-SSD 125. At this point, there may be no overlap with any existing objects, so new objects can be added. FIG. 1 The KV-SSD 125 was used, and the new node was added to the interval tree.

[0080] To handle block read or block pruning requests, the range tree can be searched to locate all objects that overlap with the requested address range. Those objects can be read or deleted; if those objects are read, the data can be parsed (if only a portion of the object is needed), and then the data of objects that do not overlap with the requested address range, along with the parsed data, can be returned to the requester.

[0081] Note that if the interval tree does not include all blocks within the specified address range for a block read request or block pruning request, the block emulator 330 may return an error. This behavior can differ from that of block-based storage devices (which can even read data from blocks that are not currently storing data): and this change in behavior can be considered a security enhancement. For example, an intruder might be probing... FIG. 1 KV-SSD 125, to determine what data is in FIG. 1 The KV-SSD 125 was found. If the number of improperly formed block read requests received exceeds a threshold (i.e., too many block read requests request data from blocks that are not currently storing data), then the block emulator 330 can trigger a lock on the KV-SSD 125 to prevent intruders from making further attempts to access it. FIG. 1 The KV-SSD accesses 125 data. (Also note that this threshold number of inappropriate block requests may exceed...) FIG. 1 The lifespan of the KV-SSD 125, or it can be locked for a threshold amount of time: for example, beyond the most recent 5 minutes. The lock can last for a predetermined amount of time (e.g., 10 minutes), during which time... FIG. 1 The KV-SSD 125 can refuse to process requests from either intruders or any user, or the lock can remain in place until an administrator unlocks it. FIG. 1 The KV-SSD 125 allows FIG. 1 The KV-SSD 125 will process the request again.

[0082] Note that although the data structure discussed above can be called a range tree, it can take any suitable form. For example, metadata can be stored in an array (or “array”) or linked list instead of a tree structure. Even as a tree structure, variations are possible: for example, the tree can be balanced or unbalanced (a balanced tree is one in which, for any node in the tree, the depth of the left branch from that node can be no more or less than the depth of the right branch from that node). Also note that more specific range trees can be used given the operations performed on the range tree. For example, for any given block address, the range tree can include no more than one node containing that block address. Therefore, while a general range tree can identify any number of ranges including a particular address, the range tree used in the embodiments of the inventive concept may not need to address this more general problem. That is, the range tree in question may not need to identify more than one range overlapping any particular block address. Refer below. FIG. 7 , FIG. 12 and FIG. 17 The structure of metadata will be discussed further.

[0083] When data is written FIG. 1 When using KV-SSD 125, nodes can be inserted into the interval tree. When data comes from... FIG. 1 When KV-SSD 125 is deleted, the node can be removed from the interval tree. See below for reference. FIG. 12 and FIG. 17 Let's discuss how to perform these operations.

[0084] FIG. 6 An embodiment based on the inventive concept is shown. FIG. 3 Details of the block emulator 330. For example... FIG. 6 As shown, the block emulator 330 may include a splitter 605 and a merger 610. As discussed above, in some embodiments of the inventive concept, FIG. 5 A single block request 505 can result in FIG. 5 Multiple KV requests 510, affected FIG. 5 The block request 505 affects a KV request 510 for each LBA. The splitter 605 can generate KV requests for the blocks involved in the block request, and the merger 610 can combine the results of those independent operations into a single result. (Batch processor in...) FIG. 6(Not shown, it can manage the batch measurement operations of all individual KV requests generated by splitter 605.) Optionally, splitter 605 can generate one or more KV requests, but the number of one or more KV requests need not be the same as the number of blocks involved in the block request. For example, in the interval tree method, a single block request (whether a block write request, block read request, or block pruning request) can involve one or more KV write requests (in the case of any object being modified to delete some of its header or tail data), one or more KV read requests (for reading the object being modified), and one or more KV delete requests (for deleting the object being completely overwritten). Splitter 605 can be responsible for generating these different KV requests, and merger 610 is responsible for combining any results to pass back to the requester of the block request.

[0085] FIG. 7 The storage of an embodiment according to the inventive concept is shown. FIG. 3 Details of the metadata stored in metadata storage device 335. FIG. 7 The example interval tree is shown below. In this example interval tree, three nodes representing three objects are shown. Node 705 could represent the object identified as object 4 (which could be used to extract from...). FIG. 1 The key to the KV-SSD 125 access object, or the associated key, can be stored in node 705 (in addition to or as a substitute for the object identifier). Object 4 can be shown as storing data spanning blocks 4 through 6. Node 710 can represent the object identified as object 0, which can be shown as storing data spanning blocks 0 through 3. Node 715 can represent the object identified as object 7, which can be shown as storing data spanning blocks 7 through 15. Note that... FIG. 7 The example interval tree shown can be a balanced tree, but as discussed above, unbalanced trees, another type of tree, or another data structure can be used to store the same information.

[0086] exist FIG. 8-10 The figure illustrates an embodiment of the inventive concept in which each block (such as LBA1 to LBA15 shown in the figures) can be stored as a separate object (such as object 1 to object 15 (“O1” to “O15”) shown in the figures). FIG. 1 On the KV-SSD 125. FIG. 8 An example of block write request processing according to an embodiment of the inventive concept is shown. FIG. 8 The diagram shows a block write request 805 requesting data to be written to blocks 2 through 7. Block emulator 330 (more specifically, FIG. 6The splitter 605 can split the block write request 805 into six independent KV place requests, as shown by the KV place request 810, one KV place request for each of blocks 2 through 7. Then, as described above... FIG. 6 As discussed, KV placement request 810 can be processed using a batch processor.

[0087] Note that, as shown in the original data 815, data has already been stored in "Blocks" 0 through "Blocks" 5 and "Blocks" 7 through "Blocks" 15. The result of the six KV placement requests ultimately overwrites the data in "Blocks" 2 through "Blocks" 5 and "Block" 7 (as indicated by the crosshairs of these objects in the original data 815). The result of performing the six KV placement requests can be shown in the modified data 820.

[0088] FIG. 9 An example of block read request processing according to an embodiment of the inventive concept is shown. Continuing from... FIG. 8 In the example, FIG. 9 The diagram shows modified data 820, and block emulator 330 is shown as receiving block read requests 905, requesting data from "block" 6 to "block" 8. Block emulator 330 (more specifically, FIG. 6 The splitter 605 can split the block read request 905 into three KV get requests as shown by the KV get request 910. Then, as described above... FIG. 6 As discussed, KV retrieval request 910 can be processed using a batch processor. Once data can be read from the individual objects using KV retrieval request 910, FIG. 6 The merger 610 can merge the data together to produce the data 915 requested by the block read request 905.

[0089] FIG. 10 An example of block trimming request processing according to one embodiment of the inventive concept is shown. Continuing from... FIG. 8-9 In the example, FIG. 10 The diagram shows modified data 820, and block emulator 330 is shown as receiving block pruning request 1005, requesting the deletion of data in "block" 6 to "block" 8. Block emulator 330 (more specifically, FIG. 6 The splitter 605 can split the block trimming request 1005 into three KV deletion requests as shown by the KV deletion request 1010. Then, as described above... FIG. 6 As discussed, KV delete request 1010 can be processed using a batch processor. Once the objects representing "blocks" 6 through "blocks" 8 are deleted (indicated by the crosshairs in modified data 820), the result can be second modified data 1015.

[0090] exist FIG. 11-17The image shows an embodiment of the inventive concept in which a range tree can be used to track which objects are stored. FIG. 1 Which "blocks" are on the KV-SSD 125? FIG. 11 An example of processing of a block write request 805 according to another embodiment of the inventive concept is shown. FIG. 11 The block write request 805 can be related to FIG. 8 The block write request is the same as 805.

[0091] When a block write request 805 is received, the block emulator 330 can check... FIG. 3 Metadata (such as range trees) in metadata storage device 335 is used to determine which objects are affected by block write request 805. For example, in raw data 1135 (some objects are referenced above) FIG. 7 As can be seen in the discussion of the interval tree (corresponding to the objects), there can be three objects affected by block write request 805 in the original data 1135 (as discussed above). FIG. 7 Additional objects (not shown) may exist in the interval tree or in the original data 1135 (these additional objects may not affect the operation of block write request 805). Object 0 (shown with a vertical shading) may have some data at the end of its data overwritten, object 4 (shown with a cross shading) may be completely overwritten, and object 7 (shown with a horizontal shading) may have some data at the beginning of its data overwritten. Note that, generally, although any number (zero or more) of objects may be completely overwritten (and thus deleted), and any number (zero or more) of objects may be completely unaffected by block write request 805, no more than two objects may have their data partially overwritten (potentially, one object is affected by the start of block write request 805, and potentially, one object is affected by the end of block write request 805).

[0092] Once the affected object has been identified, the block simulator 330 can generate an appropriate key-value request to modify the data accordingly. Because object 0 (1105) may lose some data at its tail, object 0 (1105) can be read (e.g., read into). FIG. 1 Within the KV-SSD 125's internal memory, appropriate data can be deleted from the original data 1105 of object 0 (in this case, the deleted data represents the original "blocks" 2 to "blocks" 3), and a new object (1110) (having the same key because the original LBA of the data in the object has not been changed and can still be identified as object 0) can be written. FIG. 1The KV-SSD 125. Alternatively, if the KV-SSD 125 supports requests that can simply delete portions of data at the tail of an object (similar to block trimming requests), such requests can be used instead.

[0093] Because object 7 (1115) can lose some data in its header, object 7 (1115) can be read (similarly, for example, read into). FIG. 1 Within the KV-SSD 125's internal memory, appropriate data can be deleted from the original data 1115 of object 7 (in this case, the deleted data represents the original "block" 7), and the remaining data can be written back. FIG. 1 In the KV-SSD 125. However, because object 7 (1115) may lose some data at its header, the LBA representing the first block of object 7 (1115) can change as a result of data deletion. Therefore, a modified version of object 7 (1115) can be written back using the new object key. FIG. 1 The KV-SSD 125 is treated as a new object (1120) (now recognizable as object 8), and the original object 7 (1115) can be deleted. Alternatively, if the KV-SSD 125 supports requests that can delete portions of data at the beginning of an object (similar to block trimming requests) and / or change the keys associated with the object, such requests can be used instead.

[0094] Object 4 (1125) can be completely overwritten by the data in block write request 805. Therefore, block emulator 330 can simply generate a KV delete request to retrieve data from the KV file. FIG. 1 Delete object 4 (1125) of KV-SSD 125.

[0095] Finally, the block simulator 330 can generate a KV placement request to write object 2 (1130) (with new data) to... FIG. 1 The KV-SSD 125. The original data 1135 and modified data 1140 can show the changes caused by all these operations.

[0096] FIG. 12 It shows FIG. 5 The metadata response FIG. 11 The block write request resulted in an 805 update error. FIG. 12On the left, the original metadata is shown. As discussed above, object 0 (1105) can lose two "blocks" of data at its tail, object 7 (1115) can lose one "block" of data at its head, object 4 (1125) can be completely deleted, and a new object 2 (1130) can be added. Therefore, node 710 can be modified to change the range of object 0 from spanning block 0 to block 3 to spanning block 0 to block 1 (as shown by node 1205), node 715 can be modified to change the range of object 7 from spanning block 7 to block 15 to spanning block 8 to block 15, and change the object identifier to object 8 (as shown by node 1210), and node 705 can be deleted (because object 4 (1125) can be deleted from...). FIG. 1 KV-SSD 125 is deleted), and node 1215 (representing new object 2 (1130)) can be added.

[0097] While in many cases the data to be written will overlap with the object at the beginning or end (especially when more than one object is affected), there is another possibility: the data to be overwritten may be in the middle of a single object. For example, consider continuing... FIG. 11 Example FIG. 13 .exist FIG. 13 In this context, block write request 1305 can be received and the data in "blocks" 4 to "blocks" 5 can be overwritten. Since "blocks" 4 to "blocks" 5 are entirely within object 2 (1130), there exists data within object 2 (1130) that can be overwritten and data that can remain unchanged. One possibility is: from... FIG. 1 The KV-SSD 125 reads object 2 (1130) (for example, reads object 2 (1130) from the KV-SSD 125 to...). FIG. 1 In the local storage of the KV-SSD 125, modify the data in the middle of object 2 (1130), and then write object 2 (1130) back. FIG. 1 The KV-SSD 125. This method avoids updates. FIG. 3 The metadata storage device 335 requires metadata. However, as FIG. 13 As shown, there is another method.

[0098] The block emulator 330 can read object 2 (1130) from the KV-SSD 125 and can divide object 2 (1130) into three parts: one part contains (unmodified) header data (in FIG. 13 In the example shown, the header portion may include "blocks" 2 through "blocks" 3, and a portion contains (unmodified) tail data (in... FIG. 13In the example shown, the tail portion may include "blocks" 6 to "blocks" 7, one section containing modified data (in... FIG. 13 In the example shown, this section may include “block” 4 to “block” 5. The unmodified header and tail portions may be stored as objects of themselves (shown as objects 2 (1310) and 6 (1315) in the second modified data 1320), and the modified data may be written as objects of themselves (shown as object 4 (1325) in the second modified data 1320).

[0099] Although both methods potentially involve from FIG. 1 The KV-SSD 125 reads the modified object and writes that object (and potentially other objects) back to the original system. FIG. 1 The first method, while using the KV-SSD 125, has the advantage of being able to delete data from the middle of an object (it completely omits the object containing the modified data, replacing the writing to that object). If data can be deleted from the middle of an object, the first method will leave "holes" (two "blocks" that don't store any data) in the data.

[0100] FIG. 14 It shows FIG. 5 The metadata response FIG. 13 The block write request is for update 1305. FIG. 14 On the left, the metadata before modification can be shown. As discussed above, object 2 (1130) (as shown by node 1215) can be divided into three parts, which include the first two "blocks" of object 2 (1130), the part to be written to... FIG. 1 The new data of KV-SSD 125 and the last two "blocks" of object 2 (1130); object 0 (1110) (as shown by node 1205) and object 8 (1120) (as shown by node 1210) can be unaffected. FIG. 13 The block write request 1305 has an impact. Therefore, node 1215 can be modified to change the scope of object 2 from spanning block 2 to block 7 to spanning block 2 to block 3 (as shown by node 1405), and nodes 1410 (representing object 4 (1325)) and 1415 (representing object 6 (1315)) can be added to the metadata. FIG. 14 The interval tree shown on the right has nodes arranged differently to illustrate a balanced interval tree; other balanced tree node arrangements are also possible; if the interval tree is not a balanced tree, other tree node arrangements are still possible, and the metadata arrangement can be different if another data structure is used.

[0101] FIG. 15An example of processing of a block read request 905 according to another embodiment of the inventive concept is shown. FIG. 15 The block read request 905 can be related to FIG. 9 The block read request is the same as 905.

[0102] When block read request 905 is received, block emulator 330 can read from... FIG. 3 The metadata storage device 335 accesses metadata to identify the affected objects. As can be seen in modified data 1140, "blocks" 6 through "blocks" 8 can be found in objects 2 (1130) and 8 (1120). Therefore, the block emulator 330 (more specifically, FIG. 6 The splitter 605 can issue a KV acquisition request to read object 2 (1130) and object 8 (1120). Then, the block simulator 330 can process the read data to extract "blocks" 6 to 7 from object 2 (1130) (as shown by object 2 (1505)) and "block" 8 from object 8 (1120) (as shown by object 8 (1510)). Then, FIG. 6 The merger 610 can merge the resulting data to produce data 915, which can then be sent back. FIG. 1 The processor 110 (or any software executing in the processor 110 that issues the block read request 905).

[0103] FIG. 16 An example processing of block trimming request 1005 according to another embodiment of the inventive concept is shown. FIG. 16 Block trimming request 1005 can be used with FIG. 10 The block trimming request is the same as 1005.

[0104] When block trimming request 1005 is received, block emulator 330 can... FIG. 3 The metadata storage device 335 accesses metadata to identify the affected objects. As can be seen in modified data 1140, "blocks" 6 through "blocks" 8 can be found in objects 2 (1130) and 8 (1120). Therefore, the block emulator 330 (more specifically, FIG. 6 The splitter 605 can issue a request to read object 2 (1130) and object 8 (1120) (for example, to read object 2 (1130) and object 8 (1120) into...). FIG. 1 (In the KV-SSD 125's memory). Then, data representing "blocks" 6 to "blocks" 7 from object 2 (1130) and data representing "block" 8 from object 8 (1120) can be removed from the object, and the object, including the remaining data, can be written back. FIG. 1The KV-SSD 125. Note that because object 8 (1120) can lose data at its header, the LBA representing the "block" at the header of object 8 (1120) can be changed, and therefore, the object can be assigned a new identifier (and / or a new key). The modified objects can be shown as object 2 (1605) and object 9 (1610). Object 2 (1130) and object 8 (1120) can be compared with those above. FIG. 11 The discussion focuses on how objects 0 (1105) and 7 (1115) are modified, and how they are modified in a similar way, and if FIG. 1 The KV-SSD 125 supports direct modification of objects without reading them, modifying local copies and writing the results back. FIG. 1 For a request to KV-SSD 125, such a request can be used alternatively. Once the objects representing "blocks" 6 to "blocks" 8 have been deleted, the result can be the second modified data 1615.

[0105] FIG. 17 It shows FIG. 5 The metadata response FIG. 16 The block trimming request is for update 1005. FIG. 17 On the left, the original metadata can be displayed, and... FIG. 17 On the right, the modified metadata can be shown. As discussed above, object 2 (1130) can lose two "blocks" of data at its tail, and object 8 (1120) can lose one "block" of data at its head. Therefore, node 1215 can be modified to change the range of object 2 from spanning block 2 to block 7 to spanning block 2 to block 5 (as shown by node 1705), and node 1210 can be modified to change the range of object 8 from spanning block 8 to block 15 to spanning block 9 to block 15 (and the object identifier can be changed to object 9 (as shown by node 1710)). Object 0 (1110) can be unaffected. FIG. 16 The block pruning request 1005 has an impact, therefore node 1205 can remain unchanged in the interval tree.

[0106] FIG. 18 An embodiment of the invention is shown for use. FIG. 1 A flowchart illustrating an example process for handling block requests using a KV-SSD 125. FIG. 18 In the middle, at position 1805, FIG. 1 The KV-SSD 125 can be viewed from FIG. 1 The processor 110 (or the software executing on the processor 110) receives FIG. 5 Block request 505. At box 1810, FIG. 3 The block emulator 330 can be based on FIG. 5 Block request 505 ConfirmationFIG. 5 A group (one or more) of KV requests 510. At box 1815, FIG. 1 The KV-SSD 125 can perform FIG. 5 A set of key-value requests, number 510, is located at box 1820. FIG. 1 The KV-SSD 125 can return results to the requester (such as confirmation that the request has been completed, reading the requested data, or an error (in case there was a problem in executing the request).

[0107] FIG. 19A-19B An embodiment of the invention is shown for use. FIG. 1 KV-SSD 125 processing FIG. 8 and FIG. 11 The flowchart shows an example of the block write request 805 process. As you can see, for processing... FIG. 8 and FIG. 11 The block write request returned error 805, indicating at least two viable paths exist. Based on one path (split-merge method), in... FIG. 19A In the middle, at position 1905, FIG. 6 The splitter 605 can FIG. 8 The block write request 805 is split into FIG. 8 KV write request (i.e., KV place request) 810 (subject to FIG. 8 The block write request 805 affects one such KV write request per "block", at box 1910. FIG. 1 The KV-SSD 125 can perform FIG. 8 Each of the KV write requests in 810.

[0108] Alternatively, based on another path (interval tree method), at box 1915, FIG. 3 The block emulator 330 can recognize through FIG. 11 The block write request 805 (partial or complete) is for objects that are overlapped. At box 1920, FIG. 3 The block simulator 330 can generate KV requests to delete data via... FIG. 11 The block write request 805 is completely overlaid on the object (this KV request can be made by...). FIG. 1 (KV-SSD 125 execution): The key of the object to be removed can be found in... FIG. 3 The metadata was found in the metadata storage device 335. In box 1925 ( FIG. 19B ) place, FIG. 3 The block simulator 330 can generate KV requests to obtain data from... FIG. 11 Block write request 805 was interrupted by partially overlapping objects, resulting in the removal of overlapping data (this KV request can be made by...). FIG. 1(KV-SSD125 execution): Similar to box 1920, the keys of these objects can be... FIG. 3 The metadata was found in the metadata storage device 335. At box 1930, FIG. 3 The block emulator 330 can be used for writing... FIG. 1 New data generation of KV-SSD 125 FIG. 1 Key 130. At box 1935, FIG. 3 The block simulator 330 can generate KV requests to add new objects (with...) FIG. 1 Key 130) write FIG. 1 The KV-SSD 125 (the KV request can be made by) FIG. 1 (KV-SSD 125 execution). Finally, at box 1940, FIG. 3 The block emulator 330 can be updated. FIG. 3 Metadata in metadata storage device 335 to reflect changes made by KV requests in boxes 1920, 1925 and 1935.

[0109] FIG. 13-14 An embodiment of the invention is shown for use in... FIG. 19B KV-SSD 125 processing FIG. 21A-21C The flowchart illustrates an example process of updating metadata when a block write request (805) fails. FIG. 1 In the middle, at position 2005, FIG. 9 The block emulator 330 can be derived from FIG. 15 KV-SSD 125 reading objects: The key of the object to be read can be found in... FIG. 21A The metadata was found in the metadata storage device 335. At box 2010, FIG. 3 The block simulator 330 can determine whether data is being removed from the head or tail of an object: that is, whether overlapping data is at the beginning or end of an object.

[0110] If the data being removed is in the header of the object, then in box 2015 ( FIG. 1 At box 2020, the data to be removed can be pruned from the data read from the object. FIG. 1 KV-SSD 125 is deleted: Because the data in the "block" at the object's header has been removed from the object, the LBA representing the start of data within that object will change, meaning the object's keys will also change. At box 2025, FIG. 3 The block simulator 330 can generate for objects used to store trimming data. FIG. 1 The new key is 130. Finally, at box 2030, FIG. 1The block emulator 330 can issue KV requests to transmit data with... FIG. 1 Write a new object to the new key 130 FIG. 3 KV-SSD 125 (then, FIG. 1 The KV-SSD 125 can execute this KV request.

[0111] Alternatively, if the data to be trimmed from the object can be at the tail of the object, then at box 2035, FIG. 21B The block simulator 330 can remove data from the tail of the object, at box 2040. FIG. 9 The block simulator 330 can issue KV requests to write modified data back to the object.

[0112] As shown above (refer to the reference) FIG. 15 The discussion also touches on the possibility of modifying data midway through an object. In this case, the sequences shown in boxes 2015 to 2030 and 2035 to 2040 can be modified and combined to achieve the desired result. For example, (unmodified) tail data can be separated from the rest of the data and written as its own object (similar to what is described for boxes 2015 and 2025 to 2030), (unmodified) head data can be retained as the original object (and the other data can be deleted as unwanted tail data, as in boxes 2035 to 2040), and then a new object containing the newly modified data can be written (as in...). FIG. 21B (The same as in the frame of 1935).

[0113] FIG. 6 An embodiment of the invention is shown for use. FIG. 9 KV-SSD 125 processing FIG. 9 and FIG. 9 A flowchart of an example procedure for a block read request 905. FIG. 1 In the middle, at frame 2105, FIG. 9 The block emulator 330 can check to see if the requested data exists in FIG. 6 On the KV-SSD 125. Note that this check may not be necessary: ​​if some data may not currently be stored... FIG. 9 On the KV-SSD 125, then FIG. 3 The block simulator 330 can fill in "missing" data with any suitable value (such as all zeros, all ones, or random data). The benefit of the check shown in box 2105 is that it checks data that does not actually exist if someone tries to read it. FIG. 15 Enhanced security is achieved by detecting data on the KV-SSD 125: then, FIG. 3The KV-SSD 125 can be locked to prevent such access. Note that this check can be performed without actual access. FIG. 15 Objects on the KV-SSD 125: This check can be performed by... FIG. 1 The metadata storage device 335 accesses the metadata.

[0114] If all requested data exists FIG. 3 On the KV-SSD 125, then as FIG. 6 As can be seen in the text, for processing FIG. 1 and FIG. 21C The block read request 905 indicates that at least two feasible paths exist. Based on one path (split-merge method), in box 2110 ( FIG. 3 ) place, FIG. 1 The splitter 605 can FIG. 3 The block read request 905 was split into FIG. 1 KV read request (i.e., KV get request) 910 (subject to FIG. 3 Block read request 905 affects one such KV read request per "block". At box 2115, FIG. 1 The KV-SSD 125 can perform FIG. 1 Each of the KV read requests in 910. Finally, at box 2120, FIG. 1 The merger 610 can merge components from... FIG. 22A-22C The KV read request 910 reads the data to produce a result that can be returned to the requester.

[0115] Alternatively, based on another path (interval tree method), at box 2125, FIG. 1 The block emulator 330 can recognize through FIG. 10 The block read request 905 is for objects that are (partially or completely) overlapped. At box 2130, FIG. 16 The block simulator 330 can generate KV requests to read data via... FIG. 22A A block read request 905 is for an object that is partially or completely overlapped (the KV request can be made by...). FIG. 3 (Execution of KV-SSD 125): The key of the object to be read can be found in... FIG. 1 The metadata was found in the metadata storage device 335. Then, at box 2120, FIG. 1 The merger 610 can (as above) merge data read from overlapping objects to produce a result that can be returned to the requester.

[0116] If not all requested data exists FIG. 3 On the KV-SSD 125, then in frame 2135 ( FIG. 1) place, FIG. 1 The block simulator 330 can check to see if a threshold number of inappropriate requests have been received. Note that the check in box 2135 can measure... FIG. 1 The number of inappropriate requests since the first power-on (or last power-on) of the KV-SSD 125, or the check in box 2135, can measure the number of inappropriate requests within a threshold time interval (e.g., the past five minutes). If the threshold number of inappropriate queries (requests) has been met, then at box 2140, FIG. 1 The block emulator 330 can be locked FIG. 3 The KV-SSD 125. At frame 2145, FIG. 1 The block emulator 330 can be unlocked after a threshold amount of time (e.g., five minutes) has elapsed. FIG. 22B The KV-SSD 125. Optionally, at box 2150, FIG. 10 The KV-SSD 125 can remain locked until unlocked by an administrator. FIG. 16 Up to the KV-SSD 125.

[0117] FIG. 22B An embodiment of the invention is shown for use. FIG. 6 KV-SSD 125 processing FIG. 10 and FIG. 10 A flowchart of an example process for block trimming request 1005. FIG. 10 In the middle, at frame 2205, FIG. 1 The block emulator 330 can check to see if the data to be deleted exists in FIG. 10 On the KV-SSD 125. Note that this check may not be necessary if the data is not currently stored. FIG. 3 On the KV-SSD 125, then FIG. 16 The block emulator 330 can easily "skip" deletions that are not present. FIG. 3 The "blocks" on the KV-SSD 125. The benefit of the inspection shown in box 2205 is that it detects blocks that do not actually exist when someone attempts to delete them. FIG. 16 The enhanced security is made possible by detecting the data on the KV-SSD 125: then, FIG. 1 The KV-SSD 125 can be locked to prevent such access. Note that this check can be performed without actual access. FIG. 3 Objects on the KV-SSD 125: This check can be performed by... FIG. 20A-20B The metadata storage device 335 accesses the metadata.

[0118] If all target data exists FIG. 1On the KV-SSD 125, then if in FIG. 22C As can be seen in the text, for processing FIG. 3 and FIG. 1 For block trimming request 1005, there are at least two feasible paths. Based on one path (split-merge method), in box 2210 ( FIG. 3 ) place, FIG. 1 The splitter 605 can FIG. 3 Block trimming request 1005 split into FIG. 1 KV deletion request 1010 (subject to FIG. 1 Block trimming request 1005 affects each "block" (one such KV delete request). At box 2215, FIG. 1 The KV-SSD 125 can perform FIG. 13-14 Each of the KV deletion requests in 1010.

[0119] Alternatively, based on another path (interval tree method), at box 2220, FIG. 18-22C The block emulator 330 can recognize through ​ The block trimming request 1005 is for objects that are (partially or completely) overlapped. At box 2225, ​ The block simulator 330 can generate KV deletion requests to retrieve data from the database via... ​ Block trimming request 1005 removes data from partially or completely overlapping objects (this request can be made by...). ​ (KV-SSD 125 execution): The key of the object to be removed can be found in... ​ The metadata was found in the metadata storage device 335. Note that box 2225 is similar to box 1925, and the method used to complete box 2225 is shown in... ​ middle.

[0120] If not all the data to be deleted exists ​ On the KV-SSD 125, then in box 2230 ( ​ ) place, ​ The block simulator 330 can check to see if a threshold number of inappropriate requests have been received. Note that the check in box 2230 can measure... ​ The number of inappropriate requests since the KV-SSD 125's first power-on (or last power-on), or the check in box 2230 can measure the number of inappropriate requests within a threshold time interval (e.g., the past five minutes). If the threshold number of inappropriate queries (requests) has been met, then at box 2235, ​ The block emulator 330 can be locked ​ The KV-SSD 125. At frame 2240, ​The block emulator 330 can be unlocked after a threshold amount of time (e.g., five minutes) has elapsed. ​ The KV-SSD 125. Optionally, at box 2245, ​ The KV-SSD 125 can remain locked until unlocked by an administrator. ​ Up to the KV-SSD 125.

[0121] As shown above (refer to the reference) ​ The discussion also touches on the possibility of deleting data from the middle of an object. In this case, the sequences shown in boxes 2210-2215 and 2220-2225 can be modified or combined to achieve the desired result. For example, the (unmodified) tail data can be separated from the rest of the data and written as its own object (similar to that described for boxes 2220-2225), the (unmodified) head data can be retained as the original object (and the other data can be deleted as unwanted tail data, as in boxes 2220-2225).

[0122] exist ​ Some embodiments of the invention are shown in the flowchart. However, those skilled in the art will recognize that other embodiments of the invention are also possible by changing the order of the boxes, by omitting boxes, or by including links not shown in the drawings. All such variations of the flowchart, whether explicitly described or not, are considered embodiments of the invention.

[0123] Embodiments of the inventive concept include technical advantages that surpass those of conventional storage devices. By including a block emulator, the KV storage device is able to handle block requests. This configuration allows software (such as operating systems, file systems, and applications) to access data from the KV storage device without having to be redesigned to generate KV requests. Furthermore, because the block emulator can detect requests for reading or deleting data that is not actually stored on the KV storage device, the security of the KV storage device is enhanced: the KV storage device can be locked to prevent unauthorized access to data.

[0124] The following discussion is intended to provide a brief, general description of one or more suitable machines in which specific aspects of the invention may be implemented. One or more machines can be controlled at least in part by input from conventional input devices (such as keyboards, mice, etc.) and by instructions received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system of machines, virtual machines, or devices that are communicatively combined and operate together. Exemplary machines include computing devices (such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc.) and transportation devices such as private or public transportation (e.g., cars, trains, taxis, etc.).

[0125] One or more machines may include embedded controllers (such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, etc.). One or more machines may utilize one or more connections to one or more remote machines, such as via network interfaces, modems, or other communication coupling. Machines may be interconnected via physical and / or logical networks (such as intranets, the Internet, local area networks, wide area networks, etc.). Those skilled in the art will understand that network communications may utilize technologies including radio frequency (RF), satellite, microwave, and IEEE 802.11. Various wired and / or wireless, short-range or long-range carriers and protocols, including optical, infrared, cable, and laser technologies.

[0126] Embodiments of the present invention can be described by referring to or in conjunction with associated data including functions, procedures, data structures, application programs, etc., which, when accessed by a machine, enable the machine to perform tasks or define abstract data types or low-level hardware contexts. For example, the associated data can be stored in volatile and / or non-volatile memory (e.g., RAM, ROM, etc.), or in other storage devices and their associated storage media (including hard disk drives, floppy disks, optical storage devices, magnetic tapes, flash memory, memory sticks, digital video disks, bio-storage devices, etc.). The associated data can be transmitted over a transmission environment (including physical and / or logical networks) in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in compressed or encrypted formats. The associated data can be used in a distributed environment and stored locally and / or remotely for machine access.

[0127] Embodiments of the invention may include a tangible, non-transitory machine-readable medium comprising instructions executable by one or more processors, the instructions including instructions for performing elements of the invention as described herein.

[0128] Having described and illustrated the principles of the invention with reference to the illustrated embodiments, it will be appreciated that the illustrated embodiments can be modified in arrangement and detail without departing from such principles, and can be combined in any desired manner. Although the foregoing discussion has focused on particular embodiments, other configurations (constructions) are contemplated. Specifically, although expressions such as "according to an embodiment of the invention" are used herein, these phrases are intended to refer generally to the possibilities of embodiments and are not intended to limit the invention to a particular embodiment configuration. As used herein, these terms can refer to the same or different embodiments that can be combined into other embodiments.

[0129] The foregoing illustrative embodiments are not to be construed as limiting the invention. Although some embodiments have been described, it will be readily understood by those skilled in the art that many modifications are possible with respect to those embodiments without substantially departing from the novel teachings and advantages of this disclosure. Therefore, all such modifications are intended to be included within the scope of the invention as defined in the claims.

[0130] The embodiments of the invention can be extended to the following statements without limitation:

[0131] Statement 1: Embodiments of the inventive concept include a key-value (KV) storage device, the key-value (KV) storage device comprising:

[0132] A storage device for a first object and a second object, the first object including first data associated with a first key, and the second object including second data associated with a second key;

[0133] The KV translation layer is used to convert the first key into the first physical address of the storage device for storing the first data, and to convert the second key into the second physical address of the storage device for storing the second data.

[0134] The KV interface is used to receive the first KV request involving the first object;

[0135] The block interface is used to receive block requests involving a second object; and

[0136] A block simulator is used to generate a second key-value request, which includes a second key generated from the block request.

[0137] Statement 2. Embodiments of the inventive concept include the KV storage device according to Statement 1, the KV storage device further comprising:

[0138] Machines, including KV storage devices; and

[0139] The processor executes a block device driver for the KV storage device, the block device driver including the block interface and the block emulator.

[0140] Statement 3: Embodiments of the inventive concept include the KV storage device according to Statement 1, the KV device further including host interface logic, the host interface logic including the block emulator.

[0141] Statement 4. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the block emulator generates at least one KV write request based at least in part on a block request including a block write request.

[0142] Statement 5. Embodiments of the inventive concept include the KV storage device according to Statement 4, wherein the block emulator also generates at least one KV deletion request based at least in part on the block write request.

[0143] Statement 6. Embodiments of the inventive concept include the KV storage device according to Statement 4, wherein the block emulator also generates at least one KV read request based at least in part on the block write request.

[0144] Statement 7. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the block emulator generates at least one KV read request based at least in part on a block request including a block read request.

[0145] Statement 8. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the block emulator generates at least one KV deletion request based at least in part on a block request including a block pruning request.

[0146] Statement 9. Embodiments of the inventive concept include the KV storage device according to Statement 8, wherein the block emulator further generates at least one KV read request and at least one KV write request based at least in part on a block pruning request.

[0147] Statement 10. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the block emulator comprises:

[0148] A splitter is used to split a block request into at least two block requests; and

[0149] A merger is used to combine the results of the at least two block requests into a single result.

[0150] Statement 11. Embodiments of the inventive concept include the KV storage device according to Statement 1, the KV storage device further including a metadata storage device for metadata about a second object.

[0151] Statement 12. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein if a request for a threshold number results in an error, the block emulator locks the KV storage device.

[0152] Statement 13. An embodiment of the inventive concept includes the KV storage device according to Statement 12, wherein if a request for a threshold number results in an error within a first threshold time, the block emulator locks the KV storage device.

[0153] Statement 14. An embodiment of the inventive concept includes the KV storage device according to Statement 12, wherein the block emulator unlocks the KV storage device after a second threshold time.

[0154] Statement 15: An embodiment of the inventive concept includes the KV storage device as described in Statement 12, wherein an administrator unlocks the KV storage device.

[0155] Statement 16. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the block size associated with a block request can be configured by the user.

[0156] Statement 17. Embodiments of the inventive concept include the KV storage device according to Statement 1, wherein the KV storage device includes a KV solid-state drive (KV-SSD).

[0157] Statement 18. An embodiment of the inventive concept includes a method comprising:

[0158] Receive block requests from the source at the block interface emulator for key-value (KV) storage devices;

[0159] Determine a set of KV requests for the KV storage device to simulate the received block requests;

[0160] Execute the set of KV requests on the KV storage device to generate results; and

[0161] Return the results from the KV storage device to the source.

[0162] Statement 19. Embodiments of the inventive concept include the method according to Statement 18, wherein the block request includes one of a block write request, a block read request, and a block trim request.

[0163] Statement 20: Embodiments of the inventive concept include the method according to Statement 18, wherein:

[0164] The step of receiving a block request from a source at a block interface emulator for a key-value (KV) storage device includes: receiving a block write request from the source at the block interface emulator for the KV storage device, the block write request including a logical block address (LBA) and data; and

[0165] The steps of executing the set of KV requests on the KV storage device include: executing a KV write request to store an object on the KV storage device, the object including data associated with a key.

[0166] Statement 21. Embodiments of the inventive concept include the method according to Statement 20, wherein the step of determining a set of KV requests for the KV storage device to emulate a received block request includes: generating keys for the data at least in part based on LBA.

[0167] Statement 22. Embodiments of the inventive concept include the method according to Statement 18, wherein the step of executing the set of KV requests on the KV storage device to generate a result further includes:

[0168] Use the second key to read the second data of the second object from the KV storage device;

[0169] Trim the tail portion of the second data of the object to produce trimmed data; and

[0170] Update the second object to store the trimmed data using the key.

[0171] Statement 23. Embodiments of the inventive concept include the method according to Statement 22, wherein the step of determining the set of KV requests to the KV storage device to emulate a received block request includes: determining that a block write request overlaps with a second object.

[0172] Statement 24. Embodiments of the inventive concept include the method according to Statement 18, wherein the step of executing the set of KV requests on the KV storage device to generate a result includes:

[0173] Use the second key to read the second data of the second object from the KV storage device;

[0174] Trim the header portion of the object's second data to produce trimmed data;

[0175] Generate a second key for pruning the data; and

[0176] Store the second object on the KV storage device to store the trimmed data using the second key.

[0177] Statement 25. Embodiments of the inventive concept include the method according to Statement 24, wherein the step of performing the set of KV requests on the KV storage device to generate a result further includes: removing a second object from the KV storage device.

[0178] Statement 26. Embodiments of the inventive concept include the method according to Statement 24, wherein the step of determining a set of KV requests for the KV storage device to simulate a received block request includes: determining that a block write request overlaps with a second object.

[0179] Statement 27. Embodiments of the inventive concept include the method according to Statement 18, wherein the step of performing the set of KV requests on the KV storage device to generate a result includes: removing objects on the KV storage device.

[0180] Statement 28. Embodiments of the inventive concept include the method according to Statement 18, wherein:

[0181] The step of receiving a block request from a source at a block interface emulator for a key-value (KV) storage device includes: receiving a block read request from the source at the block interface emulator for the KV storage device, the block read request including a logical block address (LBA); and

[0182] The steps of executing the set of KV requests on the KV storage device to generate a result include: reading an object from the KV storage device, the object including data associated with a key, and the object including the LBA.

[0183] Statement 29. Embodiments of the inventive concept include the method according to Statement 28, wherein the step of determining a set of KV requests for the KV storage device to emulate a received block request includes: identifying an object as including at least the LBA.

[0184] Statement 30, embodiments of the inventive concept include the method according to Statement 28, wherein the step of performing the set of KV requests on the KV storage device to generate a result further includes: selecting a portion of the data from the object.

[0185] Statement 31: Embodiments of the inventive concept include the method according to Statement 28, wherein the step of executing the set of KV requests on the KV storage device to generate a result further includes:

[0186] Read a second object from the KV storage device, the second object including second data associated with a second key; and

[0187] The data and the second data are combined to produce a result.

[0188] Statement 32. Embodiments of the inventive concept include the method according to Statement 31, wherein the step of determining a set of KV requests for the KV storage device to emulate a received block request includes: determining that a block read request overlaps with the object and a second object.

[0189] Statement 33. Embodiments of the inventive concept include the method according to Statement 18, wherein:

[0190] A block request must include at least the first LBA and the second LBA;

[0191] The steps of determining a set of KV requests for a KV storage device to emulate received block requests include: determining a first KV request for a first LBA and a second KV request for a second LBA; and

[0192] The steps of executing the set of KV requests on the KV storage device to generate a result include: executing both the first KV request and the second KV request.

[0193] Statement 34. Embodiments of the inventive concept include the method according to Statement 18, the method further comprising:

[0194] Receive a threshold number of error-causing block requests at the KV storage device; and

[0195] Lock the KV storage device.

[0196] Statement 35. Embodiments of the inventive concept include the method according to Statement 34, wherein the step of receiving a threshold number of error-causing block requests at the KV storage device includes: receiving the threshold number of error-causing block requests at the KV storage device within a first threshold time amount.

[0197] Statement 36. Embodiments of the inventive concept include the method according to Statement 34, the method further comprising: unlocking the KV storage device after a second threshold time amount.

[0198] Statement 37. Embodiments of the inventive concept include the method according to Statement 34, the method further comprising: unlocking the KV storage device by an administrator of the KV storage device.

[0199] Statement 38. Embodiments of the inventive concept include the method according to Statement 18, the method further comprising: configuring a block emulator to use a block size.

[0200] Statement 39. Embodiments of the inventive concept include a product comprising a non-transitory storage medium having instructions stored on the non-transitory storage medium, the instructions, when executed by a machine, causing:

[0201] Receive block requests from the source at the block interface emulator for key-value (KV) storage devices;

[0202] Determine a set of KV requests for the KV storage device to simulate the received block requests;

[0203] Execute the set of KV requests on the KV storage device to generate results; and

[0204] Return the results from the KV storage device to the source.

[0205] Statement 40: Embodiments of the inventive concept include the product described in Statement 39, wherein a block request includes one of a block write request, a block read request, and a block trim request.

[0206] Statement 41: Embodiments of the inventive concept include the product described in Statement 39, wherein:

[0207] The step of receiving a block request from a source at a block interface emulator for a key-value (KV) storage device includes: receiving a block write request from the source at the block interface emulator for the KV storage device, the block write request including a logical block address (LBA) and data; and

[0208] The steps of executing the set of KV requests on the KV storage device include: executing a KV write request to store an object on the KV storage device, the object including the data associated with a key.

[0209] Statement 42. Embodiments of the inventive concept include the product according to Statement 41, wherein the step of determining a set of KV requests for a KV storage device to emulate a received block request includes: generating keys for data at least in part based on LBA.

[0210] Statement 43. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the set of KV requests on the KV storage device to generate a result further includes:

[0211] Use the second key to read the second data of the second object from the KV storage device;

[0212] Trim the tail portion of the second data of the object to produce trimmed data; and

[0213] Update the second object to store the trimmed data using the key.

[0214] Statement 44. Embodiments of the inventive concept include the product according to Statement 43, wherein the step of determining a set of KV requests to a KV storage device to emulate a received block request includes: determining that a block write request overlaps with a second object.

[0215] Statement 45. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the set of KV requests on the KV storage device to generate a result includes:

[0216] Use the second key to read the second data of the second object from the KV storage device;

[0217] Trim the header portion of the object's second data to produce trimmed data;

[0218] Generate a second key for pruning the data; and

[0219] Store the second object on the KV storage device to store the trimmed data using the second key.

[0220] Statement 46. Embodiments of the inventive concept include the product described in Statement 45, wherein the step of performing the set of KV requests on the KV storage device to generate a result further includes: removing a second object from the KV storage device.

[0221] Statement 47. Embodiments of the inventive concept include the product according to Statement 45, wherein the step of determining a set of KV requests to a KV storage device to emulate a received block request includes: determining that a block write request overlaps with a second object.

[0222] Statement 48. Embodiments of the inventive concept include the product described in Statement 39, wherein the step of performing the set of KV requests on the KV storage device to generate a result includes: removing objects on the KV storage device.

[0223] Statement 49. Embodiments of the inventive concept include the product described in Statement 39, wherein:

[0224] The step of receiving a block request from a source at a block interface emulator for a key-value (KV) storage device includes: receiving a block read request from the source at the block interface emulator for the KV storage device, the block read request including a logical block address (LBA); and

[0225] The steps of executing the set of KV requests on the KV storage device to generate a result include: reading an object from the KV storage device, the object including data associated with a key, and the object including the LBA.

[0226] Statement 50. One embodiment of the inventive concept includes the product according to Statement 49, wherein the step of determining a set of KV requests to a KV storage device to emulate a received block request includes: identifying an object as including at least the LBA.

[0227] Statement 51: Embodiments of the inventive concept include the product described in Statement 49, wherein the step of performing the set of KV requests on the KV storage device to generate a result further includes: selecting a portion of the data from the object.

[0228] Statement 52: Embodiments of the inventive concept include the product according to Statement 49, wherein the step of executing the set of KV requests on the KV storage device to generate a result further includes:

[0229] Read a second object from the KV storage device, the second object including second data associated with a second key; and

[0230] Merge the data and the second data to produce the result.

[0231] Statement 53. One embodiment of the inventive concept includes the product according to Statement 52, wherein the step of determining a set of KV requests to a KV storage device to emulate a received block request includes: determining that a block read request overlaps with an object and a second object.

[0232] Statement 54. Embodiments of the inventive concept include the product described in Statement 39, wherein:

[0233] A block request must include at least the first LBA and the second LBA;

[0234] The steps of determining a set of KV requests for a KV storage device to emulate received block requests include: determining a first KV request for a first LBA and a second KV request for a second LBA; and

[0235] The steps of executing the set of KV requests on the KV storage device to generate a result include: executing both the first KV request and the second KV request.

[0236] Statement 55. Embodiments of the inventive concept include the product according to Statement 39, wherein the non-transitory storage medium has additional instructions stored on the non-transitory storage medium, which, when executed by a machine, cause:

[0237] Receive a threshold number of error-causing block requests at the KV storage device; and

[0238] Lock the KV storage device.

[0239] Statement 56. Embodiments of the inventive concept include the product according to Statement 55, wherein the step of receiving a threshold number of error-causing block requests at the KV storage device includes: receiving the threshold number of error-causing block requests at the KV storage device within a first threshold time amount.

[0240] Statement 57. Embodiments of the inventive concept include the product according to Statement 55, wherein the non-transitory storage medium has additional instructions stored on the non-transitory storage medium, which, when executed by a machine, cause the KV storage device to be unlocked after a second threshold time.

[0241] Statement 58. Embodiments of the inventive concept include the product according to Statement 55, wherein the non-transitory storage medium has additional instructions stored on the non-transitory storage medium, which, when executed by a machine, cause the KV storage device to be unlocked by an administrator of the KV storage device.

[0242] Statement 59. Embodiments of the inventive concept include the product according to Statement 39, wherein the non-transitory storage medium has additional instructions stored on the non-transitory storage medium, which, when executed by a machine, cause the block emulator to be configured to use the block size.

[0243] Therefore, given the wide variety of substitutions for the embodiments described herein, this detailed description and the appended materials are intended to be illustrative only and should not be considered as limiting the scope of the invention. Thus, what the invention claims is all such modifications that may fall within the scope and spirit of the claims and their equivalents.

Claims

1. A machine including a key-value storage device, the key-value storage device comprising: A storage device for storing a first object and a second object, the first object including first data associated with a first key, and the second object including second data associated with a second key; A key-value translation layer is used to convert a first key into a first physical address in the storage device for storing the first data, and to convert a second key into a second physical address in the storage device for storing the second data; The key-value interface is used to receive the first key-value request involving the first object; The block interface is used to receive block requests involving a second object; as well as A block emulator is used to generate a second key-value request, including a second key, from a block request.

2. The machine according to claim 1, further comprising: The processor executes a block device driver for the key-value storage device. The block device driver includes the block interface and the block emulator.

3. The machine according to claim 1, wherein, The block emulator generates at least one key-value write request based at least in part on a block request that includes a block write request.

4. The machine according to claim 3, wherein, The block emulator also generates at least one key-value deletion request based, at least in part, on the block write request.

5. The machine according to claim 3, wherein, The block emulator also generates at least one key-value read request based at least in part on the block write request.

6. The machine according to claim 1, wherein, The block emulator generates at least one key-value read request based at least in part on a block request that includes a block read request.

7. The machine according to claim 1, wherein, The block simulator generates at least one key-value deletion request based at least in part on a block request that includes a block trimming request.

8. The machine according to any one of claims 1 to 7, wherein, The block emulator includes: A splitter is used to split a block request into at least two block requests; and A merger is used to combine the results of the at least two block requests into a single result.

9. The machine according to any one of claims 1 to 7, further comprising a metadata storage device for metadata about the second object.

10. The machine according to any one of claims 1 to 7, wherein, If the number of received requests that cause errors exceeds a threshold, the block emulator locks the machine.

11. A method for operating a key-value storage device, comprising: Receive block requests from the source at the block interface emulator for key-value storage devices; Simulate the received block requests to determine a set of key-value requests for the key-value storage device; The set of key-value requests is executed on the key-value storage device to generate a result; as well as Return the result from the key-value storage device to the source.

12. The method according to claim 11, wherein: The step of receiving a block request from a source at a block interface emulator for a key-value storage device includes: receiving a block write request from a source at the block interface emulator for the key-value storage device, the block write request including a logical block address and data; and The step of executing the set of key-value requests on the key-value storage device to generate a result includes: executing a key-value write request to store an object on the key-value storage device, the object including the data associated with the key.

13. The method according to claim 12, wherein, The step of executing the set of key-value requests on the key-value storage device to generate a result further includes: Use the second key to read the second data of the second object from the key-value storage device; Trim the tail portion of the second data of the second object to produce trimmed data; and Use the second key to store trimmed data to update the second object.

14. The method according to claim 12, wherein, The step of executing the set of key-value requests on the key-value storage device to generate a result further includes: Use the second key to read the second data of the second object from the key-value storage device; Trim the header portion of the second data of the second object to produce trimmed data; Generate a third key for pruning data; and Use a third key to store trimmed data, so that a third object is stored on a key-value storage device.

15. The method according to claim 11, wherein, The step of executing the set of key-value requests on the key-value storage device to generate a result includes: removing the object on the key-value storage device.

16. The method according to any one of claims 11 to 15, wherein: The step of receiving a block request from a source at a block interface emulator for a key-value storage device includes: receiving a block read request from a source at the block interface emulator for the key-value storage device, the block read request including a logical block address; and The step of executing the set of key-value requests on the key-value storage device to generate a result includes: reading an object from the key-value storage device, the object including data associated with a key, and the object including the logical block address.

17. The method according to any one of claims 11 to 15, further comprising: Receive the block request that caused the error at the key-value storage device; as well as If the number of received block requests that cause errors exceeds a threshold, the key-value storage device is locked.

18. The method according to any one of claims 11 to 15, further comprising: Configure the block simulator to use the block size.

19. A product comprising a non-transitory storage medium having instructions stored on the non-transitory storage medium, the instructions, when executed by a machine, causing the machine to perform the method as described in any one of claims 11 to 18.

Images