Network storage gateway

A Solid State Drive (SSD) is disclosed. The SSD may include ports to receive requests from a host and to send requests to a second storage device. The SSD may include flash storage for data. An SSD controller may process the requests received from the host and generate the requests sent to the second storage device. The SSD may act as a cache for the second storage device.

FIELD

The inventive concepts relate generally to storage systems, and more particularly to storage systems that avoid bottlenecks in CPU and memory.

BACKGROUND

Accessing data stored on storage devices in an efficient manner is becoming increasingly important. Storage devices are increasing in size, the amount of data stored on storage devices is also increasing, and therefore it becomes even more important to efficiently process and use this data.

While historically storage has been handled separately from computing, with dedicated servers just for storage (and separate from computing servers), this arrangement has a potential bottleneck in the transmission of data between the computing servers and the storage servers. Thus, there has been a move to converge the computing server and the storage server into a single unit. But in a converged system, the central processing unit (CPU) becomes a bottleneck, which may slow down overall operations.

A need remains to improve storage systems that avoid bottlenecks in CPU and memory.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of the inventive concept, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to enable a thorough understanding of the inventive concept. It should be understood, however, that persons having ordinary skill in the art may practice the inventive concept without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

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 only used to distinguish one element from another. For example, a first module could be termed a second module, and, similarly, a second module could be termed a first module, without departing from the scope of the inventive concept.

The progression of technologies to be able to store and process data as data increases is expected to move through several variations, as shown inFIG. 1below, with each variation solving some problems but potentially introducing new ones.

A converged infrastructure puts everything—CPU, memory, cache, and storage devices all in the same box. This infrastructure has the advantage that with everything consolidated in a single box, it is easy to migrate both machine and data: there is no concern that, for example, the data might be left behind when the machine is migrated.

But the converged infrastructure has two problems. First, the CPU is very busy. Aside from executing commands associated with the operating system and applications, the CPU must also execute software commands to manage accessing data from the storage devices.

The second problem is that there is a limit to the number of SSDs that may be used in a converged infrastructure. A socket on the machine may only support up to 4 SSDs. Given that a typical machine only has two sockets, the machine itself may only support up to eight SSDs. As data grows, this number of SSDs may be insufficient for future needs.

A solution to the problems of the converged infrastructure is to disaggregate computing and storage. In a disaggregated infrastructure, the storage devices are again housed in a storage server rather than being integrated into the box with the computing server. The computing server and the storage server may then communicate over a network, such as using Ethernet protocol.

This infrastructure reduces the burden on the CPU, as it no longer has to handle communicating with the storage devices. This infrastructure also permits higher numbers of storage devices:24,36, or potentially more storage devices may be stored in a single storage server, thus overcoming the limit on the number of storage devices supported by the converged infrastructure.

But the CPU is still busy handling the operating system and executing instructions for various applications, so the CPU burden is only reduced, it is not eliminated as a possible bottleneck. If too many applications are requesting services from the CPU, the CPU may still be a potential bottleneck. In addition, when Peripheral Component Interconnect Express (PCIe) Gen 5 becomes standard, storage devices using PCIe Gen 5 will be able to send and receive data at a rate of 400 GB/second: faster than memory can process data. Thus, the memory in the storage server may be a bottleneck.

To address the potential problems of the disaggregated infrastructure, further modifications may be introduced. In a third architecture, the storage devices may be replaced with Ethernet SSDs, permitting remote access of the storage devices from the CPU. This change avoids the problem of memory becoming a bottleneck. But since this third architecture places responsibility for managing data read and writes back on the CPU, the CPU is once again burdened and may be a bottleneck, just as in the converged infrastructure. Further, because the storage devices are accessed remotely over a network, this third architecture may introduce latency issues in communications between the CPU and the storage devices.

Using a cache in this third architecture may both help and hinder operations. The cache may be able to provide data in a read request more quickly than a remote access to the Ethernet SSDs. But the cache must also be accessed when writing data, resulting in write requests that may make two or three hops to reach the SSD, rather than a more direct route, again impacting latency.

To address the problems of this third architecture, an SSD with some compute processing capability may be used to the compute server in a fourth architecture. This SSD effectively becomes the cache of the compute server. This SSD, which may include a storage-related processing unit (SPU), may handle storage management, freeing the CPU of that burden. The SPU may also handle data-related commands, such as acceleration, compression, encryption, etc. Overhead may be further reduced by replacing block SSDs with key-value (KV) SSDs in the storage server. This fourth architecture avoids any problems arising from memory bottlenecks or latency, and reduces the burden on the CPU (although the burden is not entirely eliminated, since the CPU still executes instructions from applications). Other downsides to this fourth architecture include that the caches (if there are more than one) do not communicate with each other, and that the SPU is typically not as powerful as a CPU (and so may not necessarily be able to execute every instruction like a CPU, or may not be able to execute instructions as efficiently as a CPU.

To address the problems with the fourth architecture, a fifth architecture may be used. In this fifth architecture the cache SSDs are enhanced with general data processing units (DPUs) that may operate similarly to the CPU. With the caches including DPUs, some or all of the applications may be shifted to the DPUs on the cache SSDs, freeing the host CPU to handle other tasks and eliminating the potential bottleneck of the CPU. In the fifth architecture (and the fourth architecture, as well), the SPUs may support block access to data and permit Erasure Coding or other techniques (such as Redundant Arrays of Independent Disks (RAIDs)) to spread data across multiple KV SSDs in the storage server.

In addition, the KV SSDs may include SPU units themselves, to carry out acceleration, compression, encryption, etc., just like the SPUs of the cache SSDs in the fourth architecture. SPUs may also implement cache management features.

SPUs may be implemented as part of a controller, using a Field Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), a Graphics Processing Unit (GPU), or any other desired implementation. DPUs, on the other hand, tend to need more processing power (since they may be asked to execute general instructions for an application), and therefore may be implemented using conventional processors.

In the fourth and fifth architectures, the cache SSDs use both PCIe and Ethernet: PCIe for communicating with the host processor and Ethernet for communicating with the KV SSDs in the storage server. Thus, the cache SSDs may include two ports: one for PCIe communication and one for Ethernet communication. The cache SSDs may communicate with any number of KV SSDs via the Ethernet port: there is no requirement that a single cache SSD may only communicate with a single KV SSD (which would prevent the cache SSD SPU from offering Erasure Coding/RAID functionality).

The cache SSDs may be organized using cache namespaces, with each namespace defining a logically separate area. Each namespace may have its own input and output queues. Since the cache SSDs use both PCIe and Ethernet, the cache namespaces have at least two queues: one on the PCIe side and one on the Ethernet side (there may be more than two queues, depending on how queues are structured: for example, each side has a submission queue and a completion queue: the submission queue is used to receive requests, and a completion queue is used to return results).

The SPU may execute various command, such as Nop (do nothing), Insert (insert partial data into the PU buffer), Write Once (to reconstruct data from Erasure Coding), XOR, Extended OP (to do a more complicated data reconstruction), or Compression, to identify a few.

FIG. 1shows a system including a compute server and a storage server, according to an embodiment of the inventive concept. InFIG. 1, compute server105may be reachable from client110via network115. Client110and compute server105may be in a client-server relationship: client110may issue commands and compute sever105may execute those commands. Alternatively, compute server105may be a computer being used directly by an end user, avoiding the involvement of client110. Compute server105may access storage server120for data via network115.

Network115may be any variety or varieties of network. For example, network115may include a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area

Network (MAN), or a global network such as the Internet, among other possibilities. Data may be sent across network115directly, or it may be protected: for example, using encryption or a Virtual Private Network (VPN). Network115may include wired or wireless connections. In addition, network115may include any desired combinations of these alternatives. For example, client110might be connected via a wireless connection to a LAN that in turn connects via a wired connection to the Internet, which in turn connects to another LAN to which compute server105and storage server120are connected. The connections between compute server105, client110, and storage server120may vary: the connections do not have to be the same in all situations. Further, storage server120may be omitted from the diagram if compute server105includes the necessary storage.

FIG. 2shows the compute server105ofFIG. 1using a converged architecture. InFIG. 2, compute server105is shown as including processor205, memory210, cache215, and Peripheral Component Interconnect Express (PCIe) Solid State Drives (SSDs)220-1and220-2. Processor205may include a software stack, including the operating system, applications, storage software (such as a file system), and controller software to manage devices attached to compute server105(such as memory210and PCIe SSDs220-1and220-2). Processor205may be any variety of processor: for example, an Intel Xeon, Celeron, Itanium, or Atom processor, an AMD Opteron processor, an ARM processor, etc. WhileFIG. 2shows a single processor205, compute server105may include any number of processors, each of which may be single core or multi-core processors, and may be mixed in any desired combination.

Memory210and cache215may be conventional memory and cache used in support of processing on processor205. Memory210may be any variety 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) etc. Memory210may also be any desired combination of different memory types. Memory210may be managed by a memory controller (not shown inFIG. 2), which may be a separate component in compute server105with a driver that is part of the software stack. Memory210may be used to store data that may be termed “short-term”: that is, data not expected to be stored for extended periods of time. Examples of short-term data may include temporary files, data being used locally by applications (which may have been copied from other storage locations), and the like. Cache215may act as very fast local storage (potentially even faster than memory210) for data being used by processor205, and may be include non-volatile storage.

Processor205and memory210may also support an operating system under which various applications may be running. These applications may issue requests to read data from or write data to either memory210or PCIe SSDs220-1and220-2. Whereas memory210may be used to store data that may be termed “short-term”, PCIe SSDs220-1and220-2are storage devices that may be used to store data that is considered “long-term”: that is, data expected to be stored for extended periods of time. PCIe SSDs220-1and220-2may be accessed using controller software in the software stack running on processor205. WhileFIG. 2shows two PCIe SSDs220-1and220-2, embodiments of the inventive concept may include storage devices of any type and connecting via any desired connection. Thus, PCIe SSDs220-1and220-2may be replaced with Serial AT Attachment (SATA) hard disk drives, Ethernet SSDs, or storage devices of any other types. Further, embodiments of the inventive concept may include any number (zero or more) of storage devices, and each storage device may be of any desired type: thus, multiple different types of storage devices may be mixed in compute server105.

Implementing compute server105as shown inFIG. 2has some advantages. The design is simple (only one “box” to consider), and compute server105may be relocated with all data being migrated at the same time. But compute server105as shown inFIG. 2also has some disadvantages. First, processor205is very busy, since it is responsible for managing all operations within compute server105: executing applications, running the operating system (and all its background operations), storing and retrieving data from PCIe SSDs220-1and220-2, and so on (this business may be termed CPU saturation). Further, compute server105typically only has two sockets, each of which usually supports no more than four storage devices. Thus, the total number of storage devices that may be installed in compute server105is typically eight, limiting the extent to which storage may be expanded within compute server105.

To address some of the disadvantages of compute server105as shown inFIG. 2, the arrangement shown inFIG. 3may be used. InFIG. 3, PCIe SSDs220-1and220-2ofFIG. 2have been removed from compute server105, and storage server120has been added. Storage server120may include processor305, memory310, cache315, and PCIe SSDs320-1and320-2. All of these components are functionally similar or identical to those described above with reference toFIG. 2, and their descriptions will not be repeated here. Further, as withFIG. 2, whileFIG. 3shows storage server120as including PCIe SSDs320-1and320-2, embodiments of the inventive concept may include any number of storage devices, of any types, and of mixed types. (In the remainder of this document, any reference to a particular type of storage device is intended to encompass any alternative types of storage devices, subject to any requirements of the described storage device.)

By moving PCIe SSDs220-1and220-2ofFIG. 2from compute server105ofFIG. 2to PCIe SSDs320-1and320-2in storage server120inFIG. 3, some of the burdens on processor205of compute server105are reduced. The controller software may be moved from the software stack of processor205to processor305, reducing the load on processor205. Further, because storage server120may be designed for that purpose (rather than as a more general compute server), storage server120may support more than eight storage devices. For example, rack versions of storage devices may support 32 SSDs using M.2 connectors (even more than 32 devices may be possible), providing potentially significantly more storage expandability than may be offered by compute server105ofFIG. 2.

WhileFIG. 3shows only one storage server120, embodiments of the inventive concept may include any number of storage servers. Further, compute server105may communicate with any and/or all of the available storage servers120, each of which may also communicate with each other.

It is important to note that inFIG. 3, compute server105and storage server120communicate machine to machine. That is, compute server105and storage server120each have network ports, and data exchanged between the two machines may pass through the network ports via processors205and305and memories210and310. Thus, whileFIG. 3reduces the demand on processor205of compute server105ofFIG. 2, the demand is not entirely eliminated: processor205may not have to manage the controller software in the software stack, but processor205still deals with the data flow. (Further, if there are multiple storage servers120, then the various storage servers120may communicate machine to machine as well.)

In addition, looking to the future, when PCIe generation 5 becomes established, PCIe SSDs320-1and320-2may be able to send and receive data faster than memory310may be able to process that data. Thus, memory310may become a bottleneck for data delivery in the embodiment of the inventive concept shown inFIG. 4.

To address some of the disadvantages of compute server105and storage server120as shown inFIG. 3, the arrangement shown inFIG. 4may be used. InFIG. 4, storage server120has been simplified, eliminating processor305, memory310, and cache315. Instead, storage server120may include backplane405, to which Ethernet SSDs410-1and410-2may be connected. Unlike storage server120ofFIG. 3, where data passes through memory310ofFIG. 3, Ethernet SSDs410-1and410-2permit direct communication to network115ofFIG. 1. (Note that Ethernet SSDs410-1and410-2do necessarily have their own Ethernet network ports: storage server120may still include a network port. But Ethernet SSDs410-1and410-2are capable of communicating directly with the network port on storage server120, without having to involve a processor and/or memory.) By eliminating memory310ofFIG. 3, storage server120will not have a bottleneck introduced when PCIe Gen 5 is used.

WhileFIG. 4shows embodiments of the inventive concept as including Ethernet SSDs410-1and410-2, embodiments of the inventive concept are not limited to Ethernet SSDs. Provided the storage devices include some protocol for communication with compute server105(and with the other network-connected storage devices), Ethernet SSDs410-1and410-2may be replaced with functionally equivalent storage devices.

As withFIG. 3, there may be multiple storage servers120inFIG. 4. If so, then compute server105may communicate with any Ethernet SSDs410-1and410-2installed in any and/or all of storage servers120. Further, Ethernet SSDs410-1and410-2may communicate with each other, and with Ethernet SSDs installed in other storage servers.

But on the side of compute server105, network traffic may still pass through processor205and memory210. Thus, memory210may still be a potential bottleneck, with data being requested by or sent from Ethernet SSDs410-1and410-2faster than memory210may be able to process. In addition, with the controller software back in the software stack on processor205, the burden on processor205may be increased (undoing some of the benefits of the embodiment of the inventive concept shown inFIG. 3). Finally, since compute server105and storage server120may communicate across a network, Input/Output latency (the time needed to complete communication) may become a factor in delaying data transmission.

Thus, inFIG. 5, embodiments of the inventive concept are shown that may resolve these issues. InFIG. 5, cache215ofFIG. 2has been removed from compute server105, and cache SSDs505-1and505-2have been added. Cache SSDs505-1and505-2may be SSDs (or other storage devices) that may act as local caches of data retrieved from storage server120. (But compute server105may still include a local cache other than cache SSDs505-1and505-2.) Cache SSDs505-1and505-2may be any desired variety of SSDs: for example, cache SSDs505-1and505-2may be PCIe SSDs (that is, SSDs that communicate with processor205over a PCIe bus). Cache SSDs505-1and505-2may therefore be block-based SSDs (although cache SSDs505-1and505-2may also use different storage methodologies than block-based storage). Cache SSDs505-1and505-2may be SSDs that are “smart”, in the sense that cache SSDs505-1and505-2may manage the storage and retrieval of data from storage server120. To that end, cache SSDs505-1and505-2may include storage processing units (SPUs)510-1and510-2. Cache SSDs505-1and505-2may also communicate directly over a network (such as network115ofFIG. 1), much like Ethernet SSDs410-1and410-2ofFIG. 4, rather than leaving communication to processor205.

SPUs510-1and510-2may handle any aspects of storage and retrieval of data. For example, SPUs510-1and510-2may handle encryption and decryption of data, compression and decompression of data, and the use of erasure coding and/or error correction codes (ECCs) when storing data on any and/or all storage devices within storage server120. Thus, if the data is stored across multiple storage devices, SPUs510-1and510-2may select the storage devices on which the data is stored, how the data is divided across those storage devices (including the generation of any ECC data that may be stored on the storage devices), how the data is compressed, and how the data is encrypted. By including SPUs510-1and510-2in cache SSDs505-1and505-2, the software stack within processor205is reduced (SPUs510-1and510-2act in place of the controller software in terms of directing data to the appropriate storage devices in storage server120). SPUs may be implemented as part of a controller (such as a SSD controller within cache SSDs505-1and505-2), using a Field Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), a Graphics Processing Unit (GPU), a general purpose GPU (GPGPU), or any other desired implementation.

Cache SSDs505-1and505-2may also include general data processing units (DPUs)515-1and515-2. While SPUs510-1and510-2enable the offloading of management of the storage devices within storage server120, DPUs515-1and515-2enable the offloading of application processing from processor205. That is, DPUs may be thought of as auxiliary processors that may be utilized by processor205to reduce its workload. Thus, DPUs515-1and515-2may be used to further reduce the burden on processor205, which may now be reduced to performing the basic management of compute server105.

DPUs515-1and515-2may also be used to perform acceleration functions on data. For example, an application running on processor205might wish to perform a query on a database to count the number of entries that satisfy a particular criteria. The entirety of the data may be retrieved and loaded into memory210so that processor205may perform the query. But if the data is to be discarded immediately after the query is completed, such an approach requires transmission of a great deal of data when only a small amount of data is ultimately needed. Instead of having processor205perform the query, DPU515-1and/or515-2may perform the query on the data retrieved from storage server120, and just return to processor205the results of the query. (It may even be possible to shift performance of the query all the way to storage server120to further increase efficiencies, as discussed in co-pending U.S. patent application Ser. No. 16/820,665, filed Mar. 16, 2020, and co-pending U.S. patent application Ser. No. 16/820,675, filed Mar. 16, 2020, both of which claim the benefit of U.S. Provisional Patent Application Ser. No. 62/819,499, filed Mar. 15, 2019, U.S. Provisional Patent Application Ser. No. 62/834,900, filed Apr. 16, 2019, U.S. Provisional Patent Application Ser. No. 62/945,877, filed Dec. 9, 2019, and U.S. Provisional Patent Application Ser. No. 62/945,883, filed Dec. 9, 2019, all of which are incorporated by reference herein for all purposes.)

While the above describes using DPUs515-1and515-2to perform the acceleration function, SPUs510-1and510-2may also be used to perform acceleration functions. But if SPUs510-1and510-2are not implemented using general processors, SPUs510-1and510-2may only be capable of implementing specific acceleration functions that for which they have been programmed. A general processor, such as may be used to implement DPUs515-1and515-2, may be able to perform any acceleration function without being specifically programmed to implement such acceleration functions.

DPUs515-1and515-2are optional equipment: any number of cache SSDs (from zero to every cache SSD) in compute server105may include DPUs. Because DPUs515-1and515-2tend to need more processing power as compared with SPUs510-1and510-2(since they may be asked to execute general instructions for an application), DPUs515-1and515-2may be implemented using conventional processors included within cache SSDs505-1and505-2. In addition, cache SSDs505-1and505-2may include a single component that acts as both SPU and DPU, rather than separate components. Thus, for example, cache SSD505-1might include a single component that functions as both SPU510-1and DPU515-1(with cache SSD505-2potentially similarly arranged). As with other descriptions relating to storage devices, different cache SSDs may be implemented differently. Thus, one cache SSD in compute server105might include only an SPU, another cache SSD in in compute server105might include both an SPU and a DPU, but implemented as separate components, and a third cache SSD in compute server105might include a single components that functions as both SPU and DPU.

InFIG. 5, storage server120is shown as including Key-Value SSDs (KV-SSDs)520-1and520-2. While Ethernet SSDs410-1and410-2ofFIG. 4may be used in storage server120in the embodiments of the inventive concept shown inFIG. 5, KV-SSDs tend to be more efficient than SSDs that use block-based storage. Thus, replacing Ethernet SSDs410-1and410-2ofFIG. 4with KV-SSDs520-1and520-2may introduce added efficiencies and reducing the workload on cache SSDs505-1and505-2(cache SSDs505-1and505-2do not necessarily need to track what is stored on which storage devices within storage server120) (although block-based storage may be used in the embodiments of the inventive concept shown inFIG. 5). Like Ethernet SSDs410-1and410-2ofFIG. 4, KV-SSDs520-1and520-2may communicate directly with components of compute server105(and with other KV-SSDs, both within storage server120and other storage servers not shown inFIG. 5). Like cache SSDs505-1and505-2, KV-SSDs520-1and520-2may be any desired variety of SSD: for example, KV-SSDs520-1and520-2may be Ethernet KV-SSDs (that is, SSDs that are designed to communicate across networks using Ethernet).

FIG. 6shows details of compute server105and storage server120ofFIG. 1. InFIG. 6, typically, compute server105and storage server120may include one or more processors205and/or305, which may include memory controllers605and clocks610, which may be used to coordinate the operations of the components of the machine. Processors205and305may also be coupled to memories210and/or310, which may include random access memory (RAM), read-only memory (ROM), or other state preserving media, as examples. Processors205and/or305may also be coupled to storage devices220,320,410,505, and/or520, and to network connector615, which may be, for example, an Ethernet connector or a wireless connector. Processors205and/or305may also be connected to buses620, to which may be attached user interfaces625and Input/Output interface ports that may be managed using Input/Output engines630, among other components.

FIG. 7shows messages being exchanged between compute server105ofFIG. 1, cache SSDs505-1and505-2ofFIG. 5, and KV-SSDs520-1and520-2ofFIG. 5. InFIG. 5, processor205of compute server105ofFIG. 1may send read request705and/or write request710. Requests705and710may be sent to cache SSD505-1(cache SSD505-2ofFIG. 5may also be the target of requests705and710, as may be any other cache SSDs in compute server105ofFIG. 1). Cache SSD505-1may then receive requests705and710and attempt to satisfy them locally. For example, if cache SSD505-1stores data requested in read request705, cache SSD505-1may return that data directly to processor205as result715. Similarly, if cache SSD505-1receives write request710, cache SSD505-1may store the data in cache SSD505-1before sending any requests to KV-SSD520-1(or any other KV-SSD in any storage server120ofFIG. 1). If so equipped, cache SSD505-1may even send result715back to processor205before the data is ultimately written to KV-SSD620-1(which is sometimes termed an early acknowledgment).

If cache SSD505-1does not store the data requested in read request705, or if cache SSD505-1receives write request710, cache SSD505-1may send read request720or write request725to KV-SSD520-1. KV-SSD520-1may then process requests720and725and may return result730(which may be the data requested in read request720or an acknowledgment that the data was written from write request725). Cache SSD505-1may then process result730and return result715to processor205in turn. (The above description refers to “processing” result730because if cache SSD505-1includes DPU515-1ofFIG. 5, or if SPU510-1ofFIG. 5is properly implemented, cache SSD505-1may, for example, execute an acceleration function on the data returned in result730.)

Ports805and810may be ports to communicate with various other components. For example, in one embodiment of the inventive concept, as discussed above, cache505-1may be a PCIe SSD and KV-SSDs520-1and520-2ofFIG. 5may be Ethernet-equipped KV-SSDs. Thus, port805may be a PCIe port for communicating with processor205ofFIG. 5and port810may be an Ethernet port for communicating with KV-SSDs520-1and520-2ofFIG. 5.

Persistent memory815may be used to store information that should not be lost, even if power were to be unexpectedly interrupted to cache SSD505-1. Examples of the information that might be maintained in persistent memory815may include information about which KV-SSDs520-1and520-2ofFIG. 5store data for which files (and where that data is stored on KV-SSDs520-1and/or520-2), or data that was subject to write request710ofFIG. 7from processor205ofFIG. 5but which has not yet been written to KV-SSDs520-1and/or520-2ofFIG. 5. Because persistent memory815should be persistent, persistent memory815may be implemented using any desired technology that protects against data loss: for example, non-volatile storage or volatile storage that is subject to battery backup.

Flash storage825may be used to store data as the cache for processor205ofFIG. 5. AsFIG. 8describes cache SSD505-1as an SSD, and SSDs typically use flash storage for data,FIG. 8shows cache SSD505-1as including flash storage825. But if cache SSD505-1were instead implemented using a different form of storage technology (for example, a hard disk drive), flash storage825may be replaced with the hardware appropriate to store data for that technology.

Persistent memory815and flash storage825may seem redundant: typically both are forms of storage that are protected against data loss due to power interruptions. But persistent memory815be a faster form of storage than flash storage825: persistent memory815may be, for example, a cache for cache SSD505-1. But in some embodiments of the inventive concept, as flash storage825may be used to store all data in non-volatile forms, persistent memory815may be omitted.

Volatile memory820may be used to store data whose loss due to an unexpected power interruption would not be a problem. For example, volatile memory820may be used to process data being subject to an acceleration function: if the data is only partially processed when power is lost, there may be little point in ensuring the data is not lost (it may not be possible to determine the portion of processing that has been completed on the data, and therefore the original data should be retrieved from KV-SSDs520-1and/or520-2again and the acceleration function executed from the start). Volatile memory820may also be used to store other data whose loss is not of concern. Volatile memory820may be any form of memory as discussed above with reference to memories210and310ofFIGS. 2-5.

FIG. 9shows details of SSDs505-1,505-2,520-1, and520-2ofFIG. 5. InFIG. 9, SSDs505-1,505-2,520-1, and520-2may include host interface layer (HIL)905, SSD controller910, and various flash memory chips825-1through825-8(also termed “flash memory storage”), which may be organized into various channels915-1through915-4. Host interface logic905may manage communications between SSDs505-1,505-2,520-1, and520-2and other components (such as processor205ofFIG. 5or other SSDs). These communications may include read requests705and/or720ofFIG. 7to read data from SSDs505-1,505-2,520-1, and520-2and write requests710and/or725ofFIG. 7to write data to SSDs505-1,505-2,520-1, and520-2. Host interface logic905may manage an interface across only a single port (for example, KV-SSDs520-1and520-2ofFIG. 5might only communicate with cache SSDs505-1and505-2ofFIG. 5), or it may manage interfaces across multiple ports (for example cache SSDs505-1and505-2ofFIG. 5may communicate using different approaches with both processor205ofFIG. 5and KV-SSDs520-1and520-2ofFIG. 5). Alternatively, an SSD that includes multiple ports may have a separate host interface logic905to manage interfaces across each port. Embodiments of the inventive concept may also mix the possibilities (for example, an SSD with three ports might have one host interface logic to manage one port and a second host interface logic to manage the other two ports).

SSD controller910may manage the read and write operations, along with garbage collection and other operations, on flash memory chips825-1through825-8using a flash memory controller (not shown inFIG. 9).

SSD controller910may include mapping920. Mapping920may manage where particular data is stored in flash memory chips825-1through825-8. The exact form mapping920may take may depend on the implementation of the SSD. An SSD that uses block addressing may implement mapping920as a translation layer (sometimes referred to as flash translation layer (FTL)). A translation layer may perform the conventional functions of translating logical block addresses (LBAs) into physical block addresses (PBAs) where the data is actually stored. On the other hand, if SSD uses a key-value storage model, then mapping920may map object keys to addresses into physical addresses.

WhileFIG. 9shows SSDs505-1,505-2,520-1, and520-2as including eight flash memory chips825-1through825-8organized into four channels915-1through915-4, embodiments of the inventive concept may support any number of flash memory chips organized into any number of channels. Similarly, whileFIG. 9shows the structure of an SSD, other storage devices (for example, hard disk drives) may be implemented using a different structure.

FIG. 10shows an alternative view of cache SSDs505-1and505-2ofFIG. 5.FIG. 10presents more of an architectural/software view of cache SSDs505-1and505-2: the hardware that supports this view is described further with reference toFIGS. 11A-11Cbelow.

InFIG. 10, cache SSD505-1is shown as including ports805and810. Cache SSD505-1may also include cache policy1005, SPU operations1010and DPU operations1015, and cache namespaces1020-1,1020-2, and1020-3. Cache namespaces1020-1,1020-2, and1020-3represent different ways to organize data moving through cache SSD505-1. For example, data relating to one application may go through one cache namespace, data for another application may go through a second cache namespace, and so on. A single cache namespace may support multiple applications, and a single application might use multiple cache namespaces to manage its data: embodiments of the inventive concept are intended to cover all such variations.

Cache policy1005represents rules by which data may be stored in and evicted from cache SSD505-1. There may be multiple cache policies, and different applications may specify different cache policies. For example, one application may prefer to use a Least Recently Used (LRU) cache policy, whereas another application may prefer to use a Least Frequently Used (LFU) cache policy. Other cache policies may also be used.

SPU operations1010and DPU operations1015describe operations that may be performed by SPUs510-1and510-2and DPUs515-1and515-2ofFIG. 5. Example operations that may be performed by SPU510-1and510-2ofFIG. 5may include a NOP (no operation), Insert (to insert partial data into a processing unit buffer), Write Once, XOR (exclusive OR), Extended Op (for example, data reconstruction from erasure coding information), and compression. But these operations are merely exemplary, and other operations may also be performed. More obvious examples include reading partial data from a processing unit buffer, dividing data into portions for erasure coding (such as spreading data across multiple storage devices, as well as generating parity information for data reconstruction in case a storage device fails), decompression, and so on.

Submission queues1105-1and1110-1and completion queues1110-1and1110-2may be used to send and receive data from various sources. Thus, submission queue1105-1may include requests submitted to cache namespace1020-1: for example, read request705or write request710ofFIG. 7that may originate from processor205ofFIG. 5. Completion queue1110-1may be used to send response715back to processor205ofFIG. 5. Similarly, submission queue1105-2may include requests submitted to KV-SSDs520-1and/or520-2ofFIG. 5by cache namespace1020-1: for example, read request720or write request725ofFIG. 7, and completion queue1110-2may be used to receive response730back from KV-SSDs520-1and/or520-2ofFIG. 5.

Submission queue1105-1and completion queue1110-1may form one queue pair, and submission queue1105-2and completion queue1110-2may for another queue pair. Each queue pair may be associated with a port on cache SSD505-1ofFIG. 5. Thus, for example, submission queue1105-1and completion queue1110-1may be associated with port805ofFIG. 8, and submission queue1105-2and completion queue1110-2may be associated with port810ofFIG. 8.

Queue pairs such as those shown inFIG. 11Aare not necessarily physically present; they may be merely symbolic. That is, there may not be a separate physical queue pair for each cache namespace within cache SSD505-1ofFIG. 5, but each queue pair may be more a “virtual” queue pair for the associated cache namespace. Which “virtual” queue pair a particular message belongs to may be identified by other data in the request: for example, the application issuing the request (for requests received via submission queue1105-1) or data in the result (for results received via completion queue1110-2) that identifies the request to which the result is responsive.

Cache manager1115may use cache policy1005ofFIG. 10along with information from SPU510-1and/or DPU515-1(if included in cache namespace1020-1) to determine how to handle a particular request received from processor205ofFIG. 5via submission queue1105-1. Thus, cache manager1115may access both submission queue1105-1and completion queue1110-1(to access requests705and/or710ofFIG. 7received from processor205ofFIG. 5and to send result715ofFIG. 7back to processor205ofFIG. 5. Cache manager1115may also communicate with both SPU510-1and DPU515-1to determine how to handle the request. Further, since handling a particular request may involve sending further requests to KV-SSDs520-1and/or520-2ofFIG. 5, cache manager1115may also access submission queue1105-2(to send requests720and/or725ofFIG. 7to KV-SSDs520-1and/or520-2ofFIG. 5) and completion queue1110-2(to access result730ofFIG. 7received from KV-SSDs520-1and/or520-2ofFIG. 5).

PU buffer1120may be used to disassemble data (when writing data to multiple KV-SSDs520-1and520-2ofFIG. 5: for example, when data is being split across multiple storage devices) or to reassemble data (when reading data from multiple KV-SSDs520-1and520-2of

FIG. 5: for example, when data was previously split across multiple storage devices. Finally, multiplexer1125may be used to direct data to various destinations, based on its intended use.

FIG. 11Bshows a flow diagram for handling write request710ofFIG. 7from processor205ofFIG. 5. InFIG. 11B, the various components within cache namespace1020-1have been rearranged to show data flow more simply, but this rearrangement is simply for simpler understanding ofFIG. 11B. InFIG. 11B, both data and control are used by cache namespace1020-1. Control flow is depicted using solid lines, and data flow is depicted using dashed lines.

When write request710ofFIG. 7is accessed from submission queue1105-1, write request710ofFIG. 7may be delivered to cache manager1115, and the data is sent to PU buffer1120, and thence to multiplexer1125. Cache manager1115may then determine, using cache policy1005ofFIG. 10, where the data should be sent from multiplexer1125. If the data is to be stored within cache namespace1020-1(and not written to KV-SSDs520-1and/or520-2ofFIG. 5), then the data may be directed to persistent memory815(the data may also be sent to flash storage820ofFIG. 8in addition to or instead of persistent memory815). If the data is to be stored on KV-SSDs520-1and/or520-2ofFIG. 5, then the data may be directed to DPU515-1. (Note that these alternatives are not “either-or” alternatives: the data may be sent to both persistent memory815and ultimately to KV-SSDs520-1and/or520-2ofFIG. 5.)

DPU515-1may perform any appropriate pre-storage operations handled by DPU515-1. For example, if some acceleration function is to be applied to the data before storage, DPU515-1may execute this acceleration function. The data may then be delivered to SPU510-1, which may perform storage-related operations. For example, SPU510-1may encode, encrypt, and/or compress the data; SPU510-1may add Error Correcting Codes to the data; and SPU510-1may divide the data into smaller portions to perform erasure coding (again, these are not alternatives: SPU510-1may perform any desired combination of storage-related operations on the data prior to storage.) SPU510-1(and/or cache manager1115) may then generate the appropriate commands to store the data on KV-SSDs520-1and/or520-2ofFIG. 5(reflected by the convergence of the lines representing control and data flow to submission queue1110-1. Such command generation may include, for example, generating a KV command to store an object with a particular key on KV-SSDs520-1and/or520-2ofFIG. 5. This key may be generated in any manner desired: for example, as a hash of the name of the file representing the data or some other identifier associated with the data (such as the LBA assigned to the data by processor205ofFIG. 5). By placing the appropriate command in submission queue1110-1, the data may then be stored on KV-SSDs520-1and/or520-2ofFIG. 5. (KV-SSDs520-1and520-2ofFIG. 5may handle the KV commands using conventional KV-SSD storage techniques.) The keys used to store the objects containing the data may be stored for later use: persistent memory815or mapping920ofFIG. 9are two possible locations to store such key information.

Note that the above discussion said that the data may be divided into portions, so that different portions may be stored on different KV-SSDs520-1and/or520-2ofFIG. 5. (Of course, even with the data being divided into different portions, at least some of the different portions might end up being stored on the same KV-SSD, much like how a file that is too large to fit into a RAID stripe across the available disks may store data in multiple stripes that span all of the available disks.) While KV storage devices may expect each object stored on a single KV storage device to have a unique key, it is not necessarily true that keys are unique across multiple KV storage devices. That is, the same key might be used to store data on each of KV-SSDs520-1and520-2ofFIG. 5. SPU510-1(and cache manager1115) may leverage this fact to keep the keys that identify objects including data that is part of the same file related. In other words, the same key may be used to store one portion of data on KV-SSD520-1ofFIG. 5, a second portion of data on KV-SSD520-2ofFIG. 5, and so on (up to the number of KV storage devices in storage server120ofFIG. 5).

Alternatively, SPU510-1(and cache manager1115) may assign different (but still potentially related) keys to portions of data stored on different KV storage devices. For example, after hashing the file name or other data (such as the LBA), SPU510-1(and cache manager1115) might append an index to each key to identify the order in which the portions of data should be reassembled upon read request705ofFIG. 7. (Cache namespace1020-1may track such ordering information regardless of what methodology is used to generate the keys, but there is no harm in redundant approaches.) Thus, if the key assigned to the data was the string “object key”, the key used for the first portion of the data might be “object key_1”, the key used for the second portion of the data might be “object key_2”, and so on.

There are a number of reasons why SPU510-1(and cache manager1115) might divide the data into portions. Aside from erasure coding, it might be that the total data is too large to fit in a single object on KV-SSDs520-1and/or520-2ofFIG. 5(assuming that KV-SSDs520-1and/or520-2ofFIG. 5have limits on the size of an individual object). Or the size of the data may be too large to fit into a single KV-SSD (for example, the largest KV-SSD may be 1 terabyte in size, but the data requires 2 terabytes to store). But assuming the data would fit on a single KV-SSD, that the KV-SSD is capable of internally managing object size (and divide large data into smaller chunks of data that would fit into objects whose size may be limited), and that there is no other reason to divide the data into portions, SPU510-1(and cache manager1115) may just send the entire object to KV-SSDs520-1and/or520-2ofFIG. 5without first dividing the data into portions.

It is also possible that SPU510-1(and cache manager1115) might store the same data in multiple places (perhaps for redundancy). The same key may be used to store the same data on more than one KV storage device. When such embodiments of the inventive concept are used, when processing read request705ofFIG. 7for the data, cache namespace1020-1might send a request to read the data (using the appropriate key) to any number of KV-SSDs520-1and/or520-2ofFIG. 5(that is, cache namespace1020-1might request the data from only one KV storage device, from two KV storage devices, and so on up to all available KV storage devices). KV storage devices that store the data may then return the requested data; KV storage devices that do not store the data may return messages indicating the data was not found. Cache namespace1020-1might then return the data from any of the KV storage devices (since any KV storage device that stores the data should store the same data), and may discard any other responses (both successful data retrievals and negative responses).

Returning to the control flow, eventually KV-SSDs520-1and/or520-2ofFIG. 5should place response730ofFIG. 7in completion queue1110-2. This result may be retrieved from completion queue1110-2by cache manager1115and result715ofFIG. 7may be placed in completion queue1105-2for later use by processor205ofFIG. 5. Result715ofFIG. 7may just be an unedited forwarding of result730ofFIG. 7, or it may be an edited forwarding of result730ofFIG. 7, or it may be an entirely new message, albeit perhaps returning the same general information—namely, that the data was successfully stored.

Although the above discussion suggests that all storage-related processing of the data is performed by SPU510-1within SPU510-1, some embodiments of the inventive concept may perform such processing elsewhere (although perhaps under instruction from SPU510-1and/or cache manager1115). For example, PU buffer1120may be a buffer which may store the data, and SPU510-1(and cache manager1115) may process the data while in PU buffer1120. Alternatively, PU buffer1120, while represented as separate from SPU510-1inFIGS. 11A-11C, may actually be implemented within SPU510-1, thus enabling SPU510-1to perform storage-related processing of the data as described.

Although not explicitly described above, at any point (once the data is within cache namespace1020-1and protected against loss due to power failure) cache namespace1020-1may place result715ofFIG. 7in completion queue1105-2, providing an early acknowledgment of write request710ofFIG. 7to processor205ofFIG. 5. Alternatively, cache namespace1020-1might not place result715ofFIG. 7in completion queue1105-2until after receiving result730ofFIG. 7from KV-SSDs520-1and/or520-2ofFIG. 5via completion queue1110-2. Embodiments of the inventive concept are intended to cover both such variations.

Note that in the above discussion, how KV-SSDs520-1and/or520-2ofFIG. 5are selected to store the data is not discussed. Cache namespace1020-1may use any desired methodology to select which KV-SSDs store the data. Possible methodologies that may be used include:Random selection from among available KV-SSDs.Round robin selection of KV-SSDs (that is, identifying the KV-SSDs in a particular sequence, and selecting the next KV-SSD from the sequence, restarting from the first KV-SSD after the last KV-SSD in the sequence has been used).Balancing the amount of data stored on each KV-SSD (in other words, selecting the KV-SSD with the smallest amount of stored data).Balancing the percentage of data stored on each KV-SSD (in other words, selecting the KV-SSD that has the smallest amount of stored data relative to its total capacity).Selecting a KV-SSD to satisfy Quality of Service (QoS) requirements of the application storing the data (QoS requirements may include minimum or maximum latency of the storage device, minimum or maximum bandwidth of the storage device, encryption offered by the storage device, and isolation from data of another application: U.S. patent application Ser. No. 15/227,955, filed Aug. 3, 2016, now U.S. Pat. No. 10,437,486, issued Oct. 8, 2019, which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/341,063, filed May 24, 2016, both of which are incorporated by reference herein for all purposes, describes other possible QoS requirements that may be applied).

In addition, multiple storage devices may be selected. As discussed above, cache namespace1020-1may divide the data into portions and store different portions on different storage devices. Cache namespace1020-1may also select multiple storage devices to store the data for redundancy purposes (redundancy may also be a QoS requirement of the application).

Once storage devices have been selected to store the data (or portions thereof), cache namespace1020-1may keep track of which storage devices have been selected. This information may be stored in persistent memory815, mapping920ofFIG. 9, or any other desired location. This information (which storage devices store the data) may also be stored with the key(s) used to store the data on the storage devices. But note that neither which storage devices, nor which keys are used to store the data, are absolutely necessary. As discussed above, the keys may be generated from other information (such as the file name or the LBA of the data), permitting their recovery. And while storing which storage devices store the data is helpful, it is also possible to simply attempt to retrieve the data from all storage devices. The storage devices that store the data (or portions thereof) may respond with what they store, while storage devices that do not store the data may respond negatively (since the key provided by cache namespace1020-1should not match up with a key storing data on those storage devices). Storing information about which storage devices store the data may simply avoid querying devices that do not store the data.

Note too that if the data is divided into portions, that information may be stored with the information about which storage devices store the data and/or the keys used as well. Storing information about how the data is divided may expedite reassembly of the complete data. But if the portions of the data include information about their order (for example, by including a header that identifies that a particular portion of data is portion i of n), then cache namespace1020-1may not need to store this information either.

FIG. 11Cshows a flow diagram for handling read request705ofFIG. 7from processor205ofFIG. 5. InFIG. 11C, the various components within cache namespace1020-1have been rearranged to show data flow more simply, but this rearrangement is simply for simpler understanding ofFIG. 11C. InFIG. 11C, both data and control is used by cache namespace1020-1. Control flow is depicted using solid lines, and data flow is depicted using dashed lines.

When read request705ofFIG. 7is accessed from submission queue1105-1, read request705ofFIG. 7may be delivered to cache manager1115. Cache manager1115may then generate appropriate KV commands (there may be one or more KV commands, depending on how the data was stored) to retrieve the object storing the requested data, and place these KV commands in submission queue1110-1. The appropriate KV commands may be generated inFIG. 11Csimilarly to the KV command discussed above with reference toFIG. 11B, except that the KV command may be to retrieve data rather than to store data. The appropriate key(s) may be generated (for example, by hashing the file name requested or the LBA of the data), with indices added if appropriate to how the objects were stored.

When KV-SSDs520-1and/or520-2ofFIG. 5return the requested data, results730ofFIG. 7may be placed in completion queue1110-2. SPU510-1, in coordination with cache manager1115, may then be notified and the data loaded into PU buffer1120. SPU510-1may then perform any storage-related processing on the data in PU buffer1120. For example, if the data was stored in multiple objects, SPU510-1may reassemble the original data my placing the portions in the correct order in PU buffer1120. If the data was compressed, encoded, and/or encrypted, SPU510-1may perform the appropriate decompression/decoding/decryption. If Error Correcting Codes were added to the data, SPU510-1may use the Error Correcting Codes to verify that the data was correctly returned and, if not, attempt to correct the errors (or notify processor205ofFIG. 5that the data was not successfully retrieved). As with SPU510-1inFIG. 11B, SPU510-1may perform any desired combination of operations appropriate to the data.

Once SPU510-1has completed any storage-related operations on the data, the data may be delivered to DPU515-1, which may then perform any additional functions on the data appropriate to DPU515-1(in coordination with cache manager1115). For example as discussed above, the data might involve a large data set with many entries, but processor205ofFIG. 5may only be interested in knowing how many entries in the data set meet a particular condition. DPU515-1may perform the appropriate query on the data and instead return the result of the query (rather than the entire data set).

After DPU515-1ofFIG. 1has finished processing the data, the data may be delivered to multiplexer1125. Multiplexer1125, in coordination with cache manager1115, may then direct the data to either persistent memory815or to completion queue1105-2for return to processor205ofFIG. 5. (As withFIG. 11B, multiplexer1125may direct the data to both persistent memory815and to completion queue1105-2: the choice is not an “either-or” choice.) Once result715ofFIG. 7is placed in completion queue1105-2, processor205ofFIG. 5may access result715ofFIG. 7and process it accordingly.

FIGS. 12A-12Bshow a flowchart of an example procedure for cache SSDs505-1and505-2ofFIG. 5to process write request710ofFIG. 7from compute server105ofFIG. 1, according to an embodiment of the inventive concept. InFIG. 12A, at block1205, cache SSD505-1and/or505-2ofFIG. 5may receive write request710ofFIG. 7from processor205ofFIG. 5. Cache SSDs505-1and505-2may receive write request710ofFIG. 7via submission queue1105-1ofFIG. 11Bover port805ofFIG. 8. At block1210, DPU515-1may apply an acceleration function to the data. Block1210is optional, as shown by dashed line1215. At block1220, the data may be stored in cache SSD505-1and/or505-2ofFIG. 5. Such storage may be within flash storage820ofFIG. 8, persistent memory815ofFIG. 11B, PU buffer1120ofFIG. 11B, or any other desired location (as long as the data is protected against lost due to power failure). At block1225, cache namespace1020-1ofFIG. 11Bmay send an early acknowledgment that the data was written by placing result715ofFIG. 7in completion queue1105-1ofFIG. 11B, which may be delivered to processor205ofFIG. 5via completion queue1105-2ofFIG. 11Bover port805ofFIG. 8. Blocks1220and1225are variously optional, as shown by dashed lines1230and1235.

At block1240(FIG. 12B), SPU510-1ofFIG. 11Bmay determine appropriate KV-SSDs520-1and/or520-2ofFIG. 5to store the data. KV-SSDs520-1and/or520-2may be intended to store the entirety of the data, or they may be intended to store only one portion (of some number of portions) of the data. As discussed above with reference toFIG. 11B, any desired methodology may be used to select the KV-SSDs to store the data (or portions thereof). At block1245, SPU510-1ofFIG. 11Bmay disassemble the data into portions. (SPU510-1ofFIG. 11may also perform other storage-related operations at this time, as described above with reference toFIG. 11B.) Of course, if the data is being stored in a single object within a single KV-SSD, then block1245may be omitted, as shown by dashed line1250. At block1255, SPU510-1may generate the appropriate KV commands to send to KV-SSDs520-1and/or520-2ofFIG. 5, and at block1260these KV commands may be sent to KV-SSDs520-1and/or520-2ofFIG. 5by being placed in submission queue1110-1ofFIG. 11B, which may be delivered to KV-SSDs520-1and/or520-2ofFIG. 5via port810ofFIG. 8. Cache namespace1020-1ofFIG. 11Bmay also store information about how the data is stored on KV-SSDs520-1and/or520-2ofFIG. 5: for example, by identifying which KV-SSDs store the data or portions of the data, what keys are used to store the data, and which portions of the data each KV-SSD stores. But as discussed above with reference toFIG. 11B, depending on how the data is stored on KV-SSDs520-1and/or520-2ofFIG. 5, none of this information may be necessary to be able to retrieve and reassemble the data from KV-SSDs520-1and/or520-2ofFIG. 5.

At block1265, cache manager1115ofFIG. 11Bmay access results730ofFIG. 7from completion queue1110-2ofFIG. 11B, which may be received from KV-SSDs520-1and/or520-2ofFIG. 5via port810ofFIG. 8. These results730ofFIG. 7may originate from the KV-SSDs520-1and/or520-2that were instructed to store some or all of the data. At block1270, cache manager1115ofFIG. 11Bmay place result715ofFIG. 7in completion queue1105-2ofFIG. 11B, to inform processor205ofFIG. 5over port805ofFIG. 8that the data has been successfully stored. Block1270is optional, as shown by dashed line1275; but at least one of blocks1225(FIG. 12A) and1270should be performed, or else processor205ofFIG. 5would not be notified that the data was successfully stored.

FIGS. 13A-13Bshow a flowchart of an example procedure for cache SSDs505-1and505-2ofFIG. 5to process read request705ofFIG. 7from compute server105ofFIG. 1, according to an embodiment of the inventive concept. InFIG. 13A, at block1305, cache SSDs505-1and/or505-2ofFIG. 5may receive read request705ofFIG. 7from processor205ofFIG. 5. Cache SSDs505-1and505-2may receive read request705ofFIG. 7via submission queue1105-1ofFIG. 11Cover port805ofFIG. 8. At block1310, cache SSDs505-1and/or505-2ofFIG. 5may check to see if the data requested in read request705ofFIG. 7is stored locally (perhaps in persistent memory815ofFIG. 11Cor flash storage825ofFIG. 8). If the data requested in read request705ofFIG. 7is stored locally, then at block1315cache SSDs505-1and/or505-2ofFIG. 5may read the data from local storage. At block1320, DPUs515-1and/or515-2ofFIG. 5may apply an acceleration function on the data. Block1320is optional, as shown by dashed line1325. Finally, at block1330, cache SSDs505-1and/or505-2ofFIG. 5may return the data to processor205ofFIG. 5by placing result715ofFIG. 7in completion queue1105-2ofFIG. 11C, which may be delivered to processor205ofFIG. 5via port805ofFIG. 8.

On the other hand, if the data requested in read request705ofFIG. 7is not stored on cache SSDs505-1and/or505-2, then at block1335(FIG. 13B), SPU510-1ofFIG. 11C(possibly working in conjunction with cache manager1115ofFIG. 11C) may generate KV requests to read the data from KV-SSDs520-1and/or520-2ofFIG. 5. At block1340, KV-SSDs520-1and/or520-2ofFIG. 5that store the data may be identified. Block1340may be omitted, as shown by dashed line1345, although in that case cache namespace1020-1ofFIG. 11Cmay need to send requests to every KV-SSD in storage server120ofFIG. 5to retrieve the data.

At block1350, SPU510-1ofFIG. 11C(and cache manager1115ofFIG. 11C) may send read request720ofFIG. 7to KV-SSDs520-1and/or520-2ofFIG. 5by placing read requests720ofFIG. 7in submission queue1110-1ofFIG. 11C, which may be delivered to KV-SSDs520-1and/or520-2ofFIG. 5over port810ofFIG. 8. At block1355, cache namespace1020-1ofFIG. 11Cmay receive results730ofFIG. 7from KV-SSDs520-1and/or520-2ofFIG. 5: results730ofFIG. 7may be received via completion queue1120-2ofFIG. 11Cover port810ofFIG. 8. At block1360, SPU510-1ofFIG. 11C(and cache manager1115ofFIG. 11C) may reassemble the data from portions received from KV-SSDs520-1and/or520-2ofFIG. 5. Obviously, if the data is received in its entirety from a KV-SSD, then there is no need to reassemble the data: block1360may therefore be omitted as shown by dashed line1365. Processing may then return to block1320ofFIG. 13Ato complete delivery of the requested data to processor205ofFIG. 5.

Note that it may occur that cache SSDs505-1and/or505-2ofFIG. 5have some of the data, but not necessarily all of the data, requested in read request705ofFIG. 7. For example, the data might span more than one “cache line” within cache SSDs505-1and/or505-2ofFIG. 5: if one “cache line” is evicted but another is not, the data may be partially stored in cache SSDs505-1and505-2ofFIG. 5. (Of course, as cache SSDs505-1and505-2ofFIG. 5may be SSDs themselves, the data stored thereon may not be organized into cache lines as that term is conventionally used, but the approach is similar.) In such situations, cache namespace1020-1ofFIG. 11Cmay be able to determine which data is stored on cache SSDs505-1and505-2ofFIG. 5and what data is not stored on cache SSDs505-1and505-2ofFIG. 5and send read requests720ofFIG. 7to retrieve only the missing data. For example, cache namespace1020-1may determine what portions of the data are stored on cache SSDs505-1and505-2ofFIG. 5, identify the portions of the data that are missing, identify which KV-SSDs store the missing portions, request those missing portions, and reassemble the data from both the data stored on cache SSDs505-1and505-2ofFIG. 5and the data received from KV-SSDs520-1and/or520-2ofFIG. 5.

InFIGS. 12A-13B, some embodiments of the inventive concept are shown. But a person skilled in the art will recognize that other embodiments of the inventive concept are also possible, by changing the order of the blocks, by omitting blocks, or by including links not shown in the drawings. All such variations of the flowcharts are considered to be embodiments of the inventive concept, whether expressly described or not.

Embodiments of the inventive concept offer technical advantages over the prior art. In conventional systems, between executing applications, managing the operating system and file system, and controlling devices such as storage devices, the burden on the local processor may be high. Embodiments of the inventive concept may shift the burden off the local processor without introducing new bottlenecks in other parts of the system (such as another processor or memory). In addition, embodiments of the inventive concept may permit data to be stored using a storage methodology without the local processor being aware of the actual storage methodology. Thus, for example, the local processor may send data read and write requests using a block-based approach even though the actual storage devices may use a Key-Value storage system.

The following discussion is intended to provide a brief, general description of a suitable machine or machines in which certain aspects of the inventive concept may be implemented. The machine or machines may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.

The machine or machines may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits (ASICs), embedded computers, smart cards, and the like. The machine or machines may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth®, optical, infrared, cable, laser, etc.

Embodiments of the present inventive concept may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.

Embodiments of the inventive concept may include a tangible, non-transitory machine-readable medium comprising instructions executable by one or more processors, the instructions comprising instructions to perform the elements of the inventive concepts as described herein.

The various operations of methods described above may be performed by any suitable means capable of performing the operations, such as various hardware and/or software component(s), circuits, and/or module(s). The software may comprise an ordered listing of executable instructions for implementing logical functions, and may be embodied in any “processor-readable medium” for use by or in connection with an instruction execution system, apparatus, or device, such as a single or multiple-core processor or processor-containing system.

Having described and illustrated the principles of the inventive concept with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles, and may be combined in any desired manner. And, although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the inventive concept” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the inventive concept to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.

The foregoing illustrative embodiments are not to be construed as limiting the inventive concept thereof. Although a few embodiments have been described, those skilled in the art will readily appreciate that many modifications are possible to those embodiments without materially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of this inventive concept as defined in the claims.

Embodiments of the inventive concept may extend to the following statements, without limitation:

Statement 1. An embodiment of the inventive concept includes a Solid State Drive (SSD), comprising:

a first port to receive first read requests and first write requests from a host;

a second port to send second read requests and second write requests to a second storage device;

flash storage for data; and

an SSD controller to process the first read requests to generate the second read requests and to process the first write requests to generate the second write requests,

wherein the SSD is used as a cache for data stored on the second storage device.

Statement 2. An embodiment of the inventive concept includes the SSD according to statement 1, wherein:

the first port includes a Peripheral Component Interconnect Express (PCIe) port; and

the second port includes an Ethernet port.

Statement 3. An embodiment of the inventive concept includes the SSD according to statement 1, wherein the second storage device includes a Key-Value SSD (KV-SSD).

Statement 4. An embodiment of the inventive concept includes the SSD according to statement 3, wherein the KV-SSD is remote from the SSD.

Statement 5. An embodiment of the inventive concept includes the SSD according to statement 3, wherein:

the first read requests and the first write requests from the host include PCIe read requests and PCIe write requests from the host; and

the SSD controller is operative to send key-value read requests and key-value write requests to the KV-SSD.

Statement 6. An embodiment of the inventive concept includes the SSD according to statement 1, further comprising a storage-related processing unit (SPU).

Statement 7. An embodiment of the inventive concept includes the SSD according to statement 6, wherein the SPU is operative to manage storage of data on the second storage device.

Statement 8. An embodiment of the inventive concept includes the SSD according to statement 6, wherein the SPU includes at least one of a general purpose processor, a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), a Graphic Processing Unit (GPU), and a General Purpose Graphics Processing Unit (GPGPU).

Statement 9. An embodiment of the inventive concept includes the SSD according to statement 1, further comprising a general data processing unit (DPU).

Statement 10. An embodiment of the inventive concept includes the SSD according to statement 9, wherein the DPU is operative to execute instructions of an application.

Statement 11. An embodiment of the inventive concept includes the SSD according to statement 10, wherein the application is off-loaded from the host.

Statement 12. An embodiment of the inventive concept includes the SSD according to statement 1, wherein the SSD is organized into at least one cache namespace.

Statement 13. An embodiment of the inventive concept includes the SSD according to statement 12, wherein the SSD includes at least one first queue and at least one second queue for the at least one cache namespace.

Statement 14. An embodiment of the inventive concept includes the SSD according to statement 13, wherein the SSD includes the at least one first queue and the at least one second queue for each namespace in the at least one cache namespace.

Statement 15. An embodiment of the inventive concept includes the SSD according to statement 13, wherein:

the at least one first queue includes at least one first submission queue and at least one first completion queue; andthe at least one second queue includes at least one second submission queue and at least one second completion queue.

Statement 16. An embodiment of the inventive concept includes the SSD according to statement 13, wherein:

the at least one first queue is associated with the first port; and

the at least one second queue is associated with the second port.

Statement 17. An embodiment of the inventive concept includes the SSD according to statement 16, wherein the SSD controller is operative to receive the first read requests and the first write requests in the at least one first queue associated with the first port and to send the second read requests and the second write requests using the at least one second queue associated with the second port.

Statement 18. An embodiment of the inventive concept includes the SSD according to statement 13, wherein the at least one cache namespace further includes:

a cache manager to manage requests received via the at least one first queue and to issue requests via the at least one second queue; and

a persistent memory to store data based on the requests.

Statement 19. An embodiment of the inventive concept includes the SSD according to statement 18, wherein the at least one cache namespace further includes a processing unit (PU) buffer for data assembly and disassembly.

Statement 20. An embodiment of the inventive concept includes the SSD according to statement 1, wherein the SSD is operative to respond to the first read requests based at least in part on the data in the flash storage.

Statement 21. An embodiment of the inventive concept includes the SSD according to statement 1, wherein the SSD is operative to respond to the first write requests based at least in part on the data in the flash storage.

Statement 22. An embodiment of the inventive concept includes the SSD according to statement 1, wherein the SSD controller is operative to send the second read requests and the second write requests to a plurality of second storage devices.

Statement 23. An embodiment of the inventive concept includes the SSD according to statement 22, wherein the SSD controller manages erasure coding of the second read requests and the second write requests on the plurality of second storage device.

Statement 24. An embodiment of the inventive concept includes a system, comprising:

a processor executing an operating system;

a memory storing data for the operating system;

a SSD, including:a first port to receive first read requests and first write requests from the processor;a second port to send second read requests and second write requests to a second storage device;flash storage for data; andan SSD controller to process the first read requests to generate the second read requests and to process the first write requests to generate the second write requests, and the second storage device,

wherein the SSD is used as a cache for data stored on the second storage device.

Statement 25. An embodiment of the inventive concept includes the system according to statement 24, wherein the second storage device includes a Key-Value SSD (KV-SSD).

Statement 26. An embodiment of the inventive concept includes the system according to statement 25, wherein the KV-SSD is remote from the SSD.

Statement 27. An embodiment of the inventive concept includes the system according to statement 25, wherein:

the first read requests and the first write requests from the host include PCIe read requests and PCIe write requests from the host; and

the SSD controller is operative to send key-value read requests and key-value write requests to the KV-SSD.

Statement 28. An embodiment of the inventive concept includes the system according to statement 25, wherein the KV-SSD includes an SPU to manage storage of data on the KV-SSD.

Statement 29. An embodiment of the inventive concept includes the system according to statement 24, wherein the SSD further includes a storage-related processing unit (SPU).

Statement 30. An embodiment of the inventive concept includes the system according to statement 29, wherein the SPU is operative to manage storage of data on the second storage device.

Statement 31. An embodiment of the inventive concept includes the system according to statement 30, wherein the SPU is operative to perform an acceleration function on the data on the second storage device.

Statement 32. An embodiment of the inventive concept includes the system according to statement 31, wherein the acceleration function is at least one of encryption, compression, decryption, or decompression.

Statement 33. An embodiment of the inventive concept includes the system according to statement 29, wherein the SPU includes at least one of a general purpose processor, a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), a Graphic Processing Unit (GPU), and a General Purpose Graphics Processing Unit (GPGPU).

Statement 34. An embodiment of the inventive concept includes the system according to statement 24, wherein the SSD controller is operative to send the second read requests and the second write requests to a plurality of second storage devices.

Statement 35. An embodiment of the inventive concept includes the system according to statement 24, further comprising a general data processing unit (DPU).

Statement 36. An embodiment of the inventive concept includes a method comprising: receiving a first write request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD;

sending a second write request for the data from the SSD to a second storage device over a second port of the SSD; and

receiving a write result from the second storage device at the SSD over the second port of the SSD; and

sending the write result from the SSD to the host over the first port of the SSD.

Statement 37. An embodiment of the inventive concept includes the method according to statement 36, wherein

receiving a first write request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD includes receiving the first write request for the data from the host at the SSD via a first queue over the first port of the SSD; and

sending the write result from the SSD to the host over the first port of the SSD includes sending the write result from the SSD to the host via the first queue over the first port of the SSD.

Statement 38. An embodiment of the inventive concept includes the method according to statement 37, wherein the first queue includes queue pair including a first submission queue and a first completion queue.

Statement 39. An embodiment of the inventive concept includes the method according to statement 36, wherein:sending a second write request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second write request for the data from the SSD to the second storage device via a second queue over the second port of the SSD; andreceiving a write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the second storage device at the SSD via the second queue over the second port of the SSD.

Statement 40. An embodiment of the inventive concept includes the method according to statement 39, wherein the second queue includes queue pair including a second submission queue and a second completion queue.

Statement 41. An embodiment of the inventive concept includes the method according to statement 36, wherein sending a second write request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD.

Statement 42. An embodiment of the inventive concept includes the method according to statement 41, wherein sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD includes:

disassembling the data into at least two portions of the data; and

sending a portion of the data from the SSD to one of the plurality of second storage devices over the second port of the SSD.

Statement 43. An embodiment of the inventive concept includes the method according to statement 42, wherein sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD further includes identifying the one of the plurality of second storage devices using a SPU before sending the portion of the data from the SSD to one of the plurality of second storage devices over the second port of the SSD.

Statement 44. An embodiment of the inventive concept includes the method according to statement 42, wherein disassembling the data into at least two portions of the data includes disassembling the data into at least two portions of the data using a storage processing unit (SPU).

Statement 45. An embodiment of the inventive concept includes the method according to statement 41, wherein receiving the write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the plurality of second storage devices at the SSD over the second port of the SSD.

Statement 46. An embodiment of the inventive concept includes the method according to statement 36, further comprising applying an acceleration function to the data before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD.

Statement 47. An embodiment of the inventive concept includes the method according to statement 46, wherein applying an acceleration function to the data before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD includes applying the acceleration function to the data using a general Data Processing Unit (DPU) before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD.

Statement 48. An embodiment of the inventive concept includes the method according to statement 36, further comprising storing the data in a flash storage of the SSD.

Statement 49. An embodiment of the inventive concept includes the method according to statement 48, further comprising sending the write result from the SSD to the host over the first port of the SSD before receiving the write result from the second storage device at the SSD over the second port of the SSD.

Statement 50. An embodiment of the inventive concept includes the method according to statement 36, wherein:

sending a second write request for the data from the SSD to a second storage device over a second port of the SSD sending a Key-Value (KV) write request for the data from the SSD to a Key-Value SSD (KV-SSD) over the second port of the SSD; and receiving a write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the KV-SSD at the SSD over the second port of the SSD.

Statement 51. An embodiment of the inventive concept includes the method according to statement 50, further comprising generating the KV write request from the first write request.

Statement 52. An embodiment of the inventive concept includes a method, comprising: receiving a first read request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD;

determining whether the data is stored in a flash storage of the SSD; based at least in part on the data not being stored in the flash storage of the SSD:sending a second read request for the data from the SSD to a second storage device over a second port of the SSD; andreceiving the data from the second storage device at the SSD over the second port of the SSD; and

sending the data from the SSD to the host over the first port of the SSD.

Statement 53. An embodiment of the inventive concept includes the method according to statement 52, wherein

receiving a first read request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD includes receiving the first read request for the data from the host at the SSD via a first queue over the first port of the SSD; and

sending the data from the SSD to the host over the first port of the SSD includes sending the data from the SSD to the host via the first queue over the first port of the SSD.

Statement 54. An embodiment of the inventive concept includes the method according to statement 53, wherein the first queue includes queue pair including a first submission queue and a first completion queue.

Statement 55. An embodiment of the inventive concept includes the method according to statement 52, wherein:

sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second read request for the data from the SSD to the second storage device via a second queue over the second port of the SSD; and

receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the second storage device at the SSD via the second queue over the second port of the SSD.

Statement 56. An embodiment of the inventive concept includes the method according to statement 55, wherein the second queue includes queue pair including a second submission queue and a second completion queue.

Statement 57. An embodiment of the inventive concept includes the method according to statement 52, wherein sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second read request for the data from the SSD to a plurality of second storage devices over the second port of the SSD.

Statement 58. An embodiment of the inventive concept includes the method according to statement 57, wherein receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the plurality of second storage devices at the SSD over the second port of the SSD.

Statement 59. An embodiment of the inventive concept includes the method according to statement 58, wherein receiving the data from the plurality of second storage devices at the SSD over the second port of the SSD includes:

receiving at least two portions of the data from the plurality of second storage devices at the SSD over the second port of the SSD; and

reassembling the data from the at least two portions of the data.

Statement 60. An embodiment of the inventive concept includes the method according to statement 59, wherein reassembling the data from the at least two portions of the data includes reassembling the data from the at least two portions of the data using a storage processing unit (SPU).

Statement 61. An embodiment of the inventive concept includes the method according to statement 57, further comprising identifying the plurality of second storage devices using a SPU before sending the second read request for the data from the SSD to the plurality of second storage devices over the second port of the SSD.

Statement 62. An embodiment of the inventive concept includes the method according to statement 52, further comprising applying an acceleration function to the data before sending the data from the SSD to the host over the first port of the SSD.

Statement 63. An embodiment of the inventive concept includes the method according to statement 62, wherein applying an acceleration function to the data before sending the data from the SSD to the host over the first port of the SSD includes applying the acceleration function to the data using a general Data Processing Unit (DPU) before sending the data from the SSD to the host over the first port of the SSD.

Statement 64. An embodiment of the inventive concept includes the method according to statement 52, further comprising, based at least in part on the data being stored in the flash storage of the SSD, reading the data from the flash storage of the SSD.

Statement 65. An embodiment of the inventive concept includes the method according to statement 52, wherein:

sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending a Key-Value (KV) read request for the data from the SSD to a Key-Value SSD (KV-SSD) over the second port of the SSD; and

receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the KV-SSD at the SSD over the second port of the SSD.

Statement 66. An embodiment of the inventive concept includes the method according to statement 65, further comprising generating the KV read request from the first read request.

Statement 67. An embodiment of the inventive concept includes an article, comprising a non-transitory storage medium, the non-transitory storage medium having stored thereon instructions that, when executed by a machine, result in:

receiving a first write request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD;

sending a second write request for the data from the SSD to a second storage device over a second port of the SSD; and

receiving a write result from the second storage device at the SSD over the second port of the SSD; and

sending the write result from the SSD to the host over the first port of the SSD.

Statement 68. An embodiment of the inventive concept includes the article according to statement 67, wherein

receiving a first write request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD includes receiving the first write request for the data from the host at the SSD via a first queue over the first port of the SSD; and

sending the write result from the SSD to the host over the first port of the SSD includes sending the write result from the SSD to the host via the first queue over the first port of the SSD.

Statement 69. An embodiment of the inventive concept includes the article according to statement 68, wherein the first queue includes queue pair including a first submission queue and a first completion queue.

Statement 70. An embodiment of the inventive concept includes the article according to statement 67, wherein:

sending a second write request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second write request for the data from the SSD to the second storage device via a second queue over the second port of the SSD; and

receiving a write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the second storage device at the SSD via the second queue over the second port of the SSD.

Statement 71. An embodiment of the inventive concept includes the article according to statement 70, wherein the second queue includes queue pair including a second submission queue and a second completion queue.

Statement 72. An embodiment of the inventive concept includes the article according to statement 67, wherein sending a second write request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD.

Statement 73. An embodiment of the inventive concept includes the article according to statement 72, wherein sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD includes:

disassembling the data into at least two portions of the data; and

sending a portion of the data from the SSD to one of the plurality of second storage devices over the second port of the SSD.

Statement 74. An embodiment of the inventive concept includes the article according to statement 73, wherein sending the second write request for the data from the SSD to a plurality of second storage devices over the second port of the SSD further includes identifying the one of the plurality of second storage devices using a SPU before sending the portion of the data from the SSD to one of the plurality of second storage devices over the second port of the SSD.

Statement 75. An embodiment of the inventive concept includes the article according to statement 73, wherein disassembling the data into at least two portions of the data includes disassembling the data into at least two portions of the data using a storage processing unit (SPU).

Statement 76. An embodiment of the inventive concept includes the article according to statement 72, wherein receiving the write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the plurality of second storage devices at the SSD over the second port of the SSD.

Statement 77. An embodiment of the inventive concept includes the article according to statement 67, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in applying an acceleration function to the data before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD.

Statement 78. An embodiment of the inventive concept includes the article according to statement 77, wherein applying an acceleration function to the data before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD includes applying the acceleration function to the data using a general Data Processing Unit (DPU) before sending the second write request for the data from the SSD to the second storage device over the second port of the SSD.

Statement 79. An embodiment of the inventive concept includes the article according to statement 67, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in storing the data in a flash storage of the SSD.

Statement 80. An embodiment of the inventive concept includes the article according to statement 79, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in sending the write result from the SSD to the host over the first port of the SSD before receiving the write result from the second storage device at the SSD over the second port of the SSD.

Statement 81. An embodiment of the inventive concept includes the article according to statement 67, wherein:

sending a second write request for the data from the SSD to a second storage device over a second port of the SSD sending a Key-Value (KV) write request for the data from the SSD to a Key-Value SSD (KV-SSD) over the second port of the SSD; and

receiving a write result from the second storage device at the SSD over the second port of the SSD includes receiving the write result from the KV-SSD at the SSD over the second port of the SSD; and

Statement 82. An embodiment of the inventive concept includes the article according to statement 81, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in generating the KV write request from the first write request.

Statement 83. An embodiment of the inventive concept includes an article, comprising a non-transitory storage medium, the non-transitory storage medium having stored thereon instructions that, when executed by a machine, result in:

receiving a first read request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD;

determining whether the data is stored in a flash storage of the SSD;

based at least in part on the data not being stored in the flash storage of the SSD:sending a second read request for the data from the SSD to a second storage device over a second port of the SSD; andreceiving the data from the second storage device at the SSD over the second port of the SSD; andsending the data from the SSD to the host over the first port of the SSD.

Statement 84. An embodiment of the inventive concept includes the article according to statement 83, wherein

receiving a first read request for a data from a host at a Solid State Drive (SSD) over a first port of the SSD includes receiving the first read request for the data from the host at the SSD via a first queue over the first port of the SSD; and

sending the data from the SSD to the host over the first port of the SSD includes sending the data from the SSD to the host via the first queue over the first port of the SSD.

Statement 85. An embodiment of the inventive concept includes the article according to statement 84, wherein the first queue includes queue pair including a first submission queue and a first completion queue.

Statement 86. An embodiment of the inventive concept includes the article according to statement 83, wherein:

sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second read request for the data from the SSD to the second storage device via a second queue over the second port of the SSD; and

receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the second storage device at the SSD via the second queue over the second port of the SSD.

Statement 87. An embodiment of the inventive concept includes the article according to statement 86, wherein the second queue includes queue pair including a second submission queue and a second completion queue.

Statement 88. An embodiment of the inventive concept includes the article according to statement 83, wherein sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending the second read request for the data from the SSD to a plurality of second storage devices over the second port of the SSD.

Statement 89. An embodiment of the inventive concept includes the article according to statement 88, wherein receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the plurality of second storage devices at the SSD over the second port of the SSD.

Statement 90. An embodiment of the inventive concept includes the article according to statement 89, wherein receiving the data from the plurality of second storage devices at the SSD over the second port of the SSD includes:

receiving at least two portions of the data from the plurality of second storage devices at the SSD over the second port of the SSD; and

reassembling the data from the at least two portions of the data.

Statement 91. An embodiment of the inventive concept includes the article according to statement 90, wherein reassembling the data from the at least two portions of the data includes reassembling the data from the at least two portions of the data using a storage processing unit (SPU).

Statement 92. An embodiment of the inventive concept includes the article according to statement 88, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in identifying the plurality of second storage devices using a SPU before sending the second read request for the data from the SSD to the plurality of second storage devices over the second port of the SSD.

Statement 93. An embodiment of the inventive concept includes the article according to statement 83, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in applying an acceleration function to the data before sending the data from the SSD to the host over the first port of the SSD.

Statement 94. An embodiment of the inventive concept includes the article according to statement 93, wherein applying an acceleration function to the data before sending the data from the SSD to the host over the first port of the SSD includes applying the acceleration function to the data using a general Data Processing Unit (DPU) before sending the data from the SSD to the host over the first port of the SSD.

Statement 95. An embodiment of the inventive concept includes the article according to statement 83, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in, based at least in part on the data being stored in the flash storage of the SSD, reading the data from the flash storage of the SSD.

Statement 96. An embodiment of the inventive concept includes the article according to statement 83, wherein:

sending a second read request for the data from the SSD to a second storage device over a second port of the SSD includes sending a Key-Value (KV) read request for the data from the SSD to a Key-Value SSD (KV-SSD) over the second port of the SSD; and

receiving the data from the second storage device at the SSD over the second port of the SSD includes receiving the data from the KV-SSD at the SSD over the second port of the SSD.

Statement 97. An embodiment of the inventive concept includes the article according to statement 96, the non-transitory storage medium having stored thereon further instructions that, when executed by the machine, result in generating the KV read request from the first read request.