KR102798787B1 - Storage device and method for storage device characteristics self monitoring - Google Patents

Abstract

A storage device includes an application container including applications, each of the applications executing in one or more namespaces; a flash memory storing data; a host interface managing communication between the storage device and a host machine; a flash translation layer translating a first address received from the host machine into a second address in the flash memory; a flash interface accessing data from the second address in the flash memory; and a polymorphic device kernel including an in-storage monitoring engine. The polymorphic device kernel receives a plurality of packets from an application executing on the storage device and provides the flash interface based on a namespace associated with the plurality of packets. The in-storage monitoring engine determines dynamic characteristics of the storage device at run-time based at least in part on matching of profiling commands received from the host machine in a performance table.

Description

{STORAGE DEVICE AND METHOD FOR STORAGE DEVICE CHARACTERISTICS SELF MONITORING}

Embodiments of the present disclosure relate generally to solid state drives (SSDs), and more specifically to determining SSD characteristics from within an SSD.

Storage devices, particularly Solid State Drives (SSDs), exhibit characteristics that continually change over time. SSDs may have unpredictable latency and/or bandwidth due to underlying software (e.g., firmware) and/or hardware within the SSD. For example, NAND flash memory may exhibit longer read/write latencies due to read/write errors. Extended access latencies (read/program/erase) due to cell wear can also impact latency and/or bandwidth. Virtual abstraction of SSD resources, i.e., various approaches such as polymorphic SSD, open-channel SSD, and lightNVM (a subsystem that supports open-channel SSD), make it difficult to predict SSD performance characteristics. Finally, different cell densities, such as Single Level Cell (SLC), Multi-Level Cell (MLC), Three Level Cell (TLC), and Quadruple Level Cell (QLC), may have different characteristics.

Therefore, dynamic latency and bandwidth monitoring/profiling is useful in data centers to reduce unexpected latency that can potentially affect long-tail latency. Achieving such improved performance is very difficult because measurements are often complex. For example, approximating a fitting curve by randomly selecting measurement points not only requires a lot of measurements, but also makes it very difficult to guarantee some guaranteed performance.

In other words, the device has the best knowledge itself. That is, it provides many hints about how the device's architectural configuration contributes to the saturation bandwidth. For example, the number of NAND channels, the number of controllers, the command queue depth, and the number of queues can be hints for predicting the number of requests or the delay of measurements to obtain reliable performance data. However, devices outside the SSD do not have meaningful access to this information.

There needs to be a way for the SSD to provide profiling information to devices external to the SSD.

An object of the present disclosure is to provide a storage device and method for self-monitoring of storage device characteristics capable of determining characteristics of the storage device within the storage device.

According to one embodiment of the present disclosure, a storage device comprises: an application container including one or more applications, each of the one or more applications executing in one or more namespaces; a flash memory storing data; a host interface managing communication between the storage device and a host machine; a flash translation layer translating a first address received from the host machine into a second address of the flash memory; a flash interface accessing the data from the second address of the flash memory; And a polymorphic device kernel implemented within the storage device including an in-storage monitoring engine, wherein the polymorphic device kernel receives a plurality of packets from the application running on the storage device, and provides the flash interface based on the namespace associated with the plurality of packets, and the in-storage monitoring engine determines a dynamic characteristic of the storage device at run-time based on at least a portion of a matching of profiling commands received from the host machine in a performance table, the dynamic characteristic being derived from a set including latency, bandwidth, retention, write amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device.

According to one embodiment of the present disclosure, a method comprises storing one or more applications within an application container of a storage device, each of the one or more applications executing in one or more namespaces; receiving a plurality of packets from a host machine via a host interface; executing a polymorphic storage device kernel implemented on the storage device to route the plurality of packets to applications within the application container via a flash interface based on namespaces associated with the plurality of packets; and executing an in-storage monitoring engine to determine a dynamic characteristic of the storage device at run-time based at least in part on matching of profiling commands received from the host machine within a performance table, the dynamic characteristic being derived from a set comprising latency, bandwidth, retention, write amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device.

The features, aspects, and advantages of the embodiments of the present disclosure will be more fully understood by reference to the detailed description below, the appended claims, and the accompanying drawings. Of course, the actual scope of the present invention is defined by the appended claims.

According to embodiments of the present disclosure, it is possible to determine characteristics of a storage device within the storage device.

Additionally, according to embodiments of the present disclosure, a storage device can provide profiling information, such as characteristics of the storage device, to an external device.

Figure 1 illustrates a data center having various host machines communicating with client machines.
FIG. 2 illustrates details of the host machine of FIG. 1 according to an embodiment of the present disclosure.
Figure 3 illustrates additional details of the host machine of Figure 1.
FIG. 4 illustrates details of a solid state drive (SSD) of FIG. 2 according to an embodiment of the present disclosure.
FIG. 5 illustrates details of the SSD of FIG. 2 according to an embodiment of the present disclosure.
Figure 6 illustrates various characteristics that can be measured within the SSD of Figure 2.
FIGS. 7A and 7B illustrate different methods of measuring the characteristics of FIG. 6 according to embodiments of the present disclosure.
Figure 8 illustrates the structure of the in-storage monitoring engine of Figure 4.
FIGS. 9A and 9B illustrate a flowchart of a procedure for using the in-storage monitoring engine of FIG. 4 to determine the characteristics of FIGS. 4 and 5 according to an embodiment of the present disclosure.
FIG. 10 illustrates a flowchart of a procedure for receiving a profiling command and optional data used when performing a profiling command using the in-storage monitoring engine of FIG. 4 according to an embodiment of the present disclosure.
Figure 11 illustrates a flow chart of a procedure for determining different characteristics of the SSD of Figure 2.
FIG. 12 illustrates a firmware stack of a polymorphic SSD according to an embodiment of the present disclosure.

Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth so that the present disclosure may be fully understood. It should be understood that one skilled in the art may practice the present disclosure 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 appreciated that while 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 may be referred to as a second module, and similarly, a second module may be referred to as a first module without departing from the scope of the present invention.

The terminology used herein to describe the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. As used in this description and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural referents as well, unless the context clearly dictates otherwise. The term "and/or," as used herein, will be understood to refer to and encompass any and all possible combinations of one or more of the associated listed items. It will be understood that the terms "comprises" and/or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Components and features in the drawings are not necessarily drawn to scale.

Storage device characteristics are more complex than ever: heterogeneous performance, time-varying performance, and different utilization of storage devices, resulting in varying access latency/bandwidth. Many efforts have been made to model this diversity, but these models have not been successful. Instead, continuous profiling/monitoring approaches have historically proven more reliable and capable of predicting performance or analyzing and preventing long-tail latency.

There are two fundamental problems with traditional storage device analysis. First, important events or information may be hidden inside the storage device. Second, performance characteristic analysis without prior information makes prediction difficult.

Embodiments of the present disclosure may include a novel storage device feature: a self-monitoring/profiling engine (referred to herein as an in-storage monitoring engine). The in-storage monitoring engine may generate appropriate profiling procedures within the storage device. The new vendor commands may be used to send desired information to a virtual storage device implemented in the physical storage device. The host machine may profile/monitor the device performance by sending a single command. Meanwhile, the storage device may generate profiling vectors based on the command. This approach not only reduces unnecessary data transfer between the host machine and the storage device, but also improves efficiency by providing only results, not data, for measuring performance.

Additionally, the storage device can detect changes in characteristics such as Error Correcting Code (ECC), read/write retries, and single-level cell (SLC)/multi-level cell (MLC) mode changes. The in-storage monitoring engine can compare new performance data with data in the performance table. The performance table stores information about the past performance of the in-storage monitoring engine and can update the performance report if necessary.

The in-storage monitoring engine can parse profiling commands and generate profiling vectors. The host machine can send a new vendor command to start monitoring/profiling.

Depending on the host requirements, the in-storage monitoring engine may measure latency/bandwidth at different layers. For example, as discussed below with reference to FIGS. 7A and 7B , the monitoring may include latency/bandwidth caused by any Flash Translation Layer (FTL), or the monitoring may bypass the FTL. Bypassing the FTL may eliminate unexpected performance from the storage device, since the monitoring may avoid delays caused by the Address Translation Layer (ATL), Garbage Collection (GC), and Wear Leveling (WL). These measurement layers may be explicitly specified in the command or retrieved from the virtual storage table (which includes the storage configuration including ATL, GC, and WL information).

An implementation of the proposed profiling/monitoring engine is further discussed below with reference to Fig. 8. As illustrated, when the decoder detects a profiling/monitoring command, it sends the command to a command queue of the in-storage monitoring engine. Since performance characterization may take a relatively long time (from microseconds to minutes), there may be multiple commands pending in the queue, and one command may be preempted based on the priority assigned to each command.

The virtual storage table can store virtual storage IDs (which can distinguish different virtual storage devices on a particular physical storage device). The virtual storage table can be a copy of a table maintained by the main controller of the physical storage device or can be a shared register. The performance table can store previous performance-characterization history associated with the virtual storage IDs.

The profiling code register may contain an operation vector for characterizing the storage performance. The profiling code register may be self-generated or user programmable. For example, the latency characteristic is in most cases a linear function with respect to the request size (i.e., 4KB read, 8KB read, etc.). Therefore, the performance characterization may be performed in different ways. The host machine or user application may query the device without specifying the exact measurement points. In this case, the profiling code register may generate the measurement/profiling points. Alternatively, the host machine or application may specify the measurement points in the command.

The profiling code register can play an important role in reporting other performance characteristics, such as bandwidth prediction. Unlike latency, which scales linearly with request size, bandwidth typically follows a logarithmic curve with a saturation point. Therefore, bandwidth is more complex to measure than latency. The profiling code register can maintain a small or efficient set of measurement points, based on vendor-provided priority information or information obtained using machine learning techniques. All these details are hidden inside the storage device, making it easy to extract the virtual storage device with relevant performance metrics.

New vendor commands may be provided to allow a host machine or application to request profiling information. These vendor commands may include inputs such as new OP codes, action types, and request size arrays, and outputs.

FIG. 1 illustrates a data center having various host machines communicating with client machines. In FIG. 1, the data center (105) is illustrated as including host machines (110, 115, 120, 125, and 130). Further details regarding the host machines (110, 115, 120, 125, and 130) are illustrated with reference to FIGS. 2 and 3. The data center (105) may also include a network (135) that allows the host machines (110, 115, 120, 125, and 130) to communicate with each other and with the client machines (140). The network (135) may be any of a variety of networks, including a Local Area Network (LAN) or a Wide Area Network (WAN). The network (135) may use a wired technology such as Ethernet, a wireless technology such as IEEE 802.11 a/b/g/n/ac or an equivalent or alternative technology, or a combination of the two. Additionally, while FIG. 1 suggests that the host machines (110, 115, 120, 125, and 130) are located within a single geographic area, in other embodiments of the present disclosure, the host machines (110, 115, 120, 125, and 130) may be geographically dispersed and interconnected using a global network such as the Internet (or an overlay network such as a Virtual Private Network (VPN)).

Although FIG. 1 illustrates that the host machines (110, 115, 120, 125, and 130) are all identical, tower computers, embodiments of the present disclosure may support any desired formats for other host machines (110, 115, 120, 125, and 130). For example, some of the host machines (110, 115, 120, 125, and 130) may be tower computers of various models and makes, and other host machines (110, 115, 120, 125, and 130) may be rack-mounted servers of various models and makes. The different host machines (110, 115, 120, 125, and 130) may have different capabilities in terms of processor power, available memory, and available storage, and may all have different formats. For example, some of the host machines (110, 115, 120, 125, and 130) may use Dynamic Access Memory (DRAM), while others may use Persistent Random Access Memory (PRAM), Static Random Access Memory (SRAM), Ferroelectric Random Access Memory (FRAM), or Non-Volatile Random Access Memory (NVRAM), such as Magnetosistive Random Access Memory (MRAM). Similarly, some host machines (110, 115, 120, 125, and 130) may use conventional hard disk drives for storage, while others may use flash memory (various NVRAMs) or MRAM. Other possibilities, whether listed herein or not, are within the scope of the present disclosure.

As noted above, the host machines (110, 115, 120, 125 and 130) are all essentially identical and interchangeable. Accordingly, any reference to the host machine (110) in the remainder of this application is intended to include any and all of the host machines (110, 115, 120, 125 and 130) without limitation.

FIG. 1 illustrates a client machine (140) as a conventional mini-tower computer system having a monitor, keyboard and mouse, wherein the client machine (140) may have any desired form factor including a laptop computer, a tablet computer, a smart phone and any other desired technology format. Additionally, while FIG. 1 illustrates a single client machine (140), embodiments of the present disclosure may support any number of client machines (140) simultaneously.

FIG. 2 illustrates details of the host machine (110) of FIG. 1 according to an embodiment of the present disclosure. In FIG. 2, the host machine (110) is illustrated as including a processor (205) (also referred to as a central processing unit (CPU)), memory (210), a network connector (215), and a solid state drive (SSD) (220). The processor (205) may be any of a variety of processors: for example, an Intel Xeon, Celeron, Itanium or Atom processor, an AMD Opteron processor, an ARM processor, etc. As noted above, the memory (210) may be any of a variety of memory, such as flash memory, SRAM, PRAM, etc., but is typically DRAM. The network connector (215) may be any of a variety of connectors that can connect the host machine (110) to the network (135) of FIG. 1: for example, an Ethernet interface or a wireless interface. The SSD (220) may be any of a variety of SSDs adapted to operate as described in the present disclosure. While the host machine (110) is illustrated as including an SSD (220), embodiments of the present disclosure may support the use of any storage device whose latency, bandwidth, and other operational characteristics are generally statically defined.

FIG. 3 illustrates additional details of the host machine (110) of FIG. 1. Referring to FIG. 3, generally, the host machine or machines (110) include one or more processors (205), which may include a memory controller (305) and a clock (310) that may be used to coordinate operations of components of the host machine or machines (110). The processors (205) may also be coupled to memory (210), which may include Random Access Memory (RAM), Read Only Memory (ROM), or other stateful media. The processor (205) may also be coupled to a storage device (220) and a network connector (315), which may be, for example, an Ethernet connector or a wireless connector. The processor (205) may also be connected to a bus (320) that may be attached to a user interface (325) and input/output interface ports that may be managed using, among other components, an input/output engine (330).

FIG. 4 illustrates details of an SSD (220) of FIG. 2 according to an embodiment of the present disclosure. In FIG. 4, the SSD (220) may include circuitry (405) for transmitting and receiving information (such as operations or data) to a host machine (110). The SSD (220) includes an SSD controller (410) and a storage memory (415), which may be a flash memory. The SSD controller (410) may control operations of the SSD (220). The storage memory (415) may store data used by various computers, including the host machine (110) and the client machine (140) of FIG. 1.

The SSD controller (410) may include, among other components, a host interface (420), an in-storage monitoring engine (425), a Flash Translation Layer (FTL) (430), an Error Correcting Code (ECC) (435), and a flash interface (440). The host interface (420) may manage communication between the SSD (220) and the host machine (110) of FIG. 1. The in-storage monitoring engine (425), which is further described below with reference to FIGS. 6 to 8, may monitor the SSD (220) to profile the characteristics of the SSD (220). The FTL (430) may perform translation between a logical block address (LBA) (used by the host machine (110) of FIG. 1) and a physical block address (PBA) within the flash memory (415). ECC (435) may use error correction code to provide protection against data corruption and/or errors due to wear of storage memory (415). Flash interface (440) may manage access (read and write) of data from flash memory (415).

In FIG. 4, SSD (220) can represent an SSD that uses a single interface. That is, SSD (220) can operate but can operate identically across all applications. For example, SSD (220) can provide a conventional file store, an object store, or a key-value store: however, whatever it may be, SSD (220) of FIG. 4 is limited to a single interface. (This does not mean that SSD (220) cannot have multiple virtual storage devices, but as shown in FIG. 4, all virtual storage devices use the same interface.) However, in other embodiments of the present disclosure, SSD (220) can support multiple different interfaces. In such embodiments of the present disclosure, SSD (220) can be a polymorphic SSD.

FIG. 5 illustrates details of the SSD (220) of FIG. 2 according to an embodiment of the present disclosure.

In embodiments of the present disclosure where the SSD (220) is replaced with another storage device technology, such as a hard disk drive, instead of using flash memory, the storage memory (415) may use another technology, such as magnetic bits stored on a disk. Corresponding changes may also be made in other parts of the storage device. For example, the FTL (430) may be replaced with a translation layer (430) that has similar functionality to the FTL (430) but may be implemented differently, and the flash interface (440) may be replaced with some other storage interface (440) for accessing data from the storage memory (415). However, in the remainder of this disclosure, in the context of using the SSD (220) as the storage device, the storage memory (415) will be referred to as flash memory (415).

In FIG. 5, the SSD (220) is illustrated as a polymorphic SSD. Polymorphic SSDs are further described in U.S. Patent Application No. 15/133,085, filed April 19, 2016, which claims priority from U.S. Provisional Patent Application No. 62/238,659, filed October 7, 2015 and U.S. Provisional Patent Application No. 62/352,509, filed June 20, 2016, all of which are incorporated herein by reference. The SSD (220) still includes circuitry (405) for transmitting and receiving information (e.g., operations or data) to the host machine (110). The SSD (220) may also include the SSD controller (410) of FIG. 4 (not shown in FIG. 5), which may include some or all of FIG. 5.

The SSD (220) may include applications (505, 510, 515, and 520). These applications may be executed on processors (525, 530, 535, and 540) within the SSD (220) (which may be referred to as in-storage computing). Memory (545) may support the processors (525, 530, 535, and 540). Memory (545) may be any desired form of memory as described above, but is typically DRAM. Although FIG. 5 is illustrated as including four processors (525, 530, 535, and 540) and four applications (505, 510, 515, and 520), embodiments of the present disclosure can support any number of processors and any number of applications, and can include different numbers of processors and applications. For example, SSD (220) can include eight processors executing sixteen applications.

Each application (505, 510, 515, or 520) may operate using a different interface. For example, application (505) may use a conventional file store, whereas application (510) may use an object store, and application (515) may use a key-value store. To support these different interfaces, SSD (220) may include a different polymorphic interface layer (PIL) (550, 555, 560, and 565) for each application. The PILs (550, 555, 560, and 565) may provide an interface between the applications and the polymorphic device kernel (570) using the interface desired by the applications. The polymorphic device kernel (570) can issue instructions to the applications (505, 510, 515, and 520) or to appropriate processors (525, 530, 535, and 540) depending on the particular interface used by the applications (505, 510, 515, and 520) or to flash memory (415) depending on the instruction in question.

While FIG. 5 illustrates applications (505, 510, 515, and 520) executing on processors (525, 530, 535, and 540), in accordance with other embodiments of the present disclosure, applications (505, 510, 515, and 520) may execute on a processor, such as processor (205) of FIG. 2, within the host machines (110) of FIG. 1. (Assuming no translation from the various interfaces occurs in the host machine (110) of FIG. 1) The applications (505, 510, 515, and 520) need simply communicate with the appropriate PIL (550, 555, 560, and 565) within the SSD (220).

Since different interfaces may access data within the SSD (220) in different ways, the hardware abstraction layer (575) can abstract how the physical hardware may implement the different interfaces. For example, comparing and contrasting a traditional file store with a key-value store, when applications use a traditional file store, the applications may issue block read and write instructions. For such traditional file store operations, the hardware abstraction layer (575) may operate very similarly to the FTL (430) of FIG. 4, which translates LBAs within the applications (505, 510, 515, and 520) into PBAs in the flash memory (415). However, applications using key-value stores issue get and put commands associated with the keys. The keys themselves are not LBAs, but rather unique identifiers associated with the corresponding values. The object that stores the key-value pairs can exist anywhere within the flash memory (415). For applications that use a key-value store, the hardware abstraction layer (575) can convert the key to a PBA in flash memory (415).

The problem can arise because the characteristics of SSDs can vary. For example, are the latency and bandwidth of SSDs not constant across all environments? The answer is no for two reasons. One reason is the behavior of applications in in-storage computing, and the other reason is the use of polymorphic SSDs such as SSD (220) of Fig. 5.

If the SSD (220) operates strictly as a storage device using a single interface, one can expect that the characteristics of the SSD (220) will not change. However, when applications are run in-storage computing, some of the computing power of the SSD (220) is provided to managing the applications, even when the applications use the same interface on the SSD (220). If the SSD (220) is "distracted" by managing the applications, the SSD (220) may spend less time processing data requests. The fewer data requests that are processed in a given interval, the more time is required to process data requests, which may increase latency. Similarly, if the SSD (220) is "distracted" by managing the applications, bandwidth may be reduced.

When the SSD (220) is a polymorphic SSD, the situation can become more complicated. The time required to translate the original language of an application into commands to read data from and/or write data to the flash memory (415) can vary, which can affect the latency and bandwidth of the SSD (220). That is, the time required to translate a data request into a command that can be processed by the SSD (220) can vary depending on the number of running applications and the interfaces they use, resulting in characteristics that can change over time during the operation of the SSD (220). Embodiments of the present disclosure provide a technical solution to the problem of determining the current characteristics of the SSD (220), and can perform more accurately than existing solutions.

FIG. 6 illustrates some of the various characteristics that may be measured within the SSD (220) of FIG. 2. For example, these characteristics may include one or more of latency (605), bandwidth (610), retention (615), write amplification factor (WAF) (620), transactions per second (TPS) (625), and queuing latency (630). Latency (605) may represent the amount of time required to complete a data request. As can be expected, larger data requests may increase the amount of time required for the SSD (220) of FIG. 2 to complete the data request. Latency may depend on the amount of time required to convert a command and/or how worn out cells change over time, as described above with reference to FIG. 5. Bandwidth (610) may represent the maximum amount of data that the SSD (220) of FIG. 2 can transmit or receive in a given unit of time. And, retention (610) can indicate how long data is retained in the SSD (220) of FIG. 2. WAF (620) can indicate the amount of data that the SSD controller should write in relation to the amount of data that the flash controller of the host should write. TPS (625) can indicate a unit of time, for example, transactions received per second. Queuing latency (630) can indicate the time that a task waits in a queue until the task can be executed.

FIGS. 7A and 7B illustrate different methods of measuring the characteristics (605, 610, and/or 615) of FIG. 6 according to embodiments of the present disclosure. In FIG. 7A , the characteristics (605, 610, and/or 615) can be measured as measurements (705) that take into account all results of the application (505) as well as the characteristics due to the polymorphic device kernel (570), the virtual flash interface (710) (which manages the interface between the application and the flash interface (440), and the flash interface (440). For example, the application (505) may use a virtual storage device within the SSD (220) of FIG. 2 and manage a flash translation layer internally. As such, in FIG. 7A , the measurements (705) may include results of the application's internal FTL, which may include delays due to ATL, GC, and WL.

Alternatively, in FIG. 7b, the measurement (715) can be taken without considering the results of the application. The measurement (715) can only consider the polymorphic device kernel (570), the virtual flash interface (710), and the flash interface (440).

Figures 7a and 7b illustrate measurements (705 and 715) that include request sizes (720 and 725). A characteristic may be measured using different request sizes to fully determine the characteristic. For example, as described above, the latency (605) of Figure 6 is often a linear function of the request size. For a two-request size, the latency (605) of Figure 6 may be interpolated/extrapolated with acceptable accuracy over a range of request sizes. On the other hand, the bandwidth (610) of Figure 6 is typically not a linear function but rather a logarithmic curve. Since more than two data points may be needed to generate a function that approximates the relationship between bandwidth and request size, more than two request sizes (720, 725) are needed. Thus, it can be seen that the number of request sizes (720, 725) used to measure a characteristic may vary depending on the characteristic being measured. The request sizes (720, 725) may be generated by the in-storage monitoring engine (425) of FIG. 4 or may be provided by the host machine (110) of FIG. 1 when the host machine (110) of FIG. 1 requests a characteristic measurement.

FIG. 8 illustrates the structure of the in-storage monitoring engine of FIG. 4. In FIG. 8, an op queue (805) can receive commands. These commands can include both profiling commands and other commands for the SSD (220) of FIG. 2: for example, read and/or write commands. A decoder (810) can determine which command has been received. Once the received command is decoded as a profiling command, the profiling command can be passed to a command queue (815) within the in-storage monitoring engine (425). Executing a profiling command can take a relatively long time, for example, microseconds to minutes: as a result, the in-storage monitoring engine (425) can have a large number of pending commands.

Assuming that the in-storage monitoring engine (425) can perform a very large number of profiling commands at one time, the in-storage monitoring engine (425) may be requested to perform more profiling commands than it can process in parallel. To address this issue, each profiling command may also have an associated *?* priority, which may be specified by the application (145) of FIG. 1 or the host machine (110) of FIG. 1 when the profiling command is first presented. If the in-storage monitoring engine (425) is requested to process more profiling commands than it can process, the in-storage monitoring engine (425) may determine the lowest priority profiling command and reject it, notifying the requester that the profiling command cannot be performed. Alternatively, instead of considering all profiling commands, the in-storage monitoring engine (425) can construct profiling commands based on their virtual storage devices and remove the lowest priority profiling command associated with the virtual storage device associated with the newly received profiling command.

Using information from a command in the command queue (805), a vector can be accessed from the profiling code register (820). For example, the vector from the profiling code register (820) may include specific code necessary to profile the SSD (220) of FIG. 2 for the latency (605) of FIG. 6. As described above, the host machine (110) of FIG. 1 may specify the request sizes (720, 725) of FIGS. 7A and 7B, or the host machine (110) of FIG. 1 may cause the in-storage monitoring engine (425) to determine the request sizes (720, 725) of FIGS. 7A and 7B. If the command does not specify the request sizes (720, 725) of FIGS. 7A and 7B, the request sizes (720, 725) of FIGS. 7A and 7B may be determined from a vector in the profiling code register (820). The values of the request sizes (720, 725) of FIGS. 7A and 7B may be body generated, vendor preset, or user configurable, according to embodiments of the present disclosure.

The virtual storage table (825) can store identifiers for various different virtual storage devices in the SSD (220) of FIG. 2. The virtual storage table (825) can store information similar to that stored in the SSD controller (410) of FIG. 4, and can copy information or share information of the SSD controller (410) of FIG. 4.

The performance table (830) can store information about past profiling commands for virtual storage identifiers. If a profiling command for a virtual storage device that has already been performed is requested and the characteristics of the SSD (220) of FIG. 2 have not changed significantly because the profiling command has been performed, the in-storage monitoring engine (425) can access the stored characteristics from the performance table (830) and return the information to the host machine (110) of FIG. 1.

If the performance table (830) does not store the characteristics of the virtual storage device, either because the characteristics of the SSD (220) of FIG. 2 have not changed since the last time the profiling command was performed, or because the SSD (22) of FIG. 2 has not been previously profiled for the virtual storage device, the in-storage monitoring engine (425) may profile the virtual storage device using the profiling station (835). Event triggers (840) and/or timer interrupts may be used to manage when to start or end various profiling commands. The results of the profiling station (835) may be stored in the performance table (830) for later use.

The profiling station (835) can store profiling commands waiting to be executed on the SSD (220) of FIG. 2. The application and/or host machine can "take" slots on the profiling station (835) until all slots are filled. The profiling station (835) can include ops that can store op codes to execute profiling commands and controls that can store information on whether and how to apply preemption control to various profiling commands. For example, the profiling bandwidth of the SSD (220) of FIG. 2 may take a relatively long time compared to the profiling latency of the SSD (220) of FIG. 2. Therefore, the profiling command to profile the latency of the SSD (220) of FIG. 2 may be executed with preemption control. Finally, the status field can provide information on the status of the profiling command. For example, the status can use a bit field to indicate whether the profiling command is active, paused, or completed. The status can use bit fields to indicate parameters of the profiling command, such as priority, preemption status, etc.

Additionally, the in-storage monitoring engine (425) may periodically repeat the initial profiling command to determine if the measured characteristic has changed. If the measured characteristic has changed, the in-storage monitoring engine (425) may report the change back to the application (145) of FIG. 1 or the host machine (110) of FIG. 1 that originally requested the profiling command.

FIGS. 9A and 9B illustrate a flowchart of an exemplary procedure for using the in-storage monitoring engine (425) of FIG. 4 to determine characteristics (605, 610, and/or 615) of FIG. 6 of the SSD (220) of FIGS. 4 and 5 according to embodiments of the present disclosure. In FIG. 9A , at block (905), the in-storage monitoring engine (425) of FIG. 4 may build a virtual storage table (825) of FIG. 8 to reflect available virtual storage devices within the SSD (220) of FIG. 2 . At block (910), the SSD (220) of FIG. 2 may receive a profiling command from the application (145) of FIG. 1 or from the host machine (110) of FIG. 1 . The profiling command can specify which characteristics (605, 610, and/or 615) of FIG. 6 are to be measured and can specify which type of commands are to be used. For example, the application (145) of FIG. 1 or the host machine (110) of FIG. 1 may only be interested in the latency (605) of FIG. 6 or the bandwidth (610) of FIG. 6 for data writes or data reads. Alternatively, the profiling command can specify that the characteristics of the SSD (220) of FIG. 2 be measured when performing a GC or a WL. Effectively, any command that the SSD (220) of FIG. 2 can execute can be measured. Consequently, the profiling command can specify arbitrary request sizes to use when profiling the SSD (220) of FIG. 2. As described above, if the in-storage monitoring engine (425) of FIG. 4 can determine what request size is used to profile the SSD (220) of FIG. 2, the profiling command does not specify any request size.

At block (915), after the SSD (220) of FIG. 2 receives the profiling command, the SSD (220) of FIG. 2 may decode the profiling command to convert the profiling command into an internal profiling command that can be processed by the in-storage monitoring engine (425) of FIG. 4. This conversion may be implemented for two reasons. First, the received profiling command may be formatted differently than the SSD (220) of FIG. 2 (and the in-storage monitoring engine (425) of FIG. 4) expects the profiling command to appear. Second, different interfaces for different virtual storage devices may provide commands to request profiling that use different formats (and the internal format of the profiling command). As a result, the conversion of the received profiling command into an internal profiling command resides in the in-storage monitoring engine (425) of FIG. 4 having a profiling command in the expected format. Block (915) may include adding any additional data necessary to complete the profiling command. For example, if the application of FIG. 1 or the host machine (110) of FIG. 1 does not specify the request sizes (720, 725) of FIGS. 7A and 7B, the request sizes may be accessed from the profiling code register and added to the profiling command.

At block (920) (FIG. 9b), the in-storage monitoring engine (425) of FIG. 4 can check whether the result of the profiling command can be found in the performance table (830) of FIG. 8. If found, at block (925), the in-storage monitoring engine (425) of FIG. 4 can access the result from the performance table (830) of FIG. 8, and at block (930), the in-storage monitoring engine (425) of FIG. 4 can return the result of the profiling command to the requester.

Meanwhile, if the performance table (830) of FIG. 8 does not store the result of the profiling command, or the result of the profiling command is old, at block (935), the in-storage monitoring engine (425) of FIG. 4 can perform the profiling command. Then, at block (940), the in-storage monitoring engine (425) of FIG. 4 can store the result in the performance table (830) of FIG. 8, and at block (930), the in-storage monitoring engine (425) of FIG. 4 can return the result of the profiling command to the requester.

On the other hand, while FIGS. 9A and 9B suggest that the virtual storage table (825) of FIG. 8 is built once, embodiments of the present disclosure may include modifying the virtual storage table (825) of FIG. 8 when necessary. For example, a new virtual storage device may be added to the SSD (220) of FIG. 2 during operation. Accordingly, the virtual storage table (825) of FIG. 8 may be updated when a new virtual storage device is added.

FIG. 10 illustrates a flowchart of an exemplary procedure for receiving a profiling command and optional data for use in performing a profiling command using the in-storage monitoring engine (425) of FIG. 4 according to an embodiment of the present disclosure. In FIG. 10 , at block (1005), the in-storage monitoring engine (425) of FIG. 4 may receive a profiling command from the application (145) of FIG. 1 . Alternatively, at block (1010), the in-storage monitoring engine (425) of FIG. 4 may receive a profiling command from the host machine (110) of FIG. 1 . Either way, at block (1015), the in-storage monitoring engine (425) of FIG. 4 may receive additional data for use in performing the profiling command, such as the request sizes (720, 725) of FIGS. 7A and 7B , or the priority of the profiling command. Block (1015) may be omitted as shown by the dotted lines (1020).

FIG. 11 illustrates a flowchart of an exemplary procedure for determining different characteristics (605, 610 and/or 615) of an SSD (220) of FIG. 2. In FIG. 11, at block (1105), the in-storage monitoring engine (425) of FIG. 4 can determine the latency (605) of FIG. 6 of the SSD (220) of FIG. 2. Alternatively, at block (1110), the in-storage monitoring engine (425) of FIG. 4 can determine the bandwidth (610) of FIG. 6 of the SSD (220) of FIG. 2. Finally, at block (1115), the in-storage monitoring engine (425) of FIG. 4 can determine the retention (615) of FIG. 6 of the SSD (220) of FIG. 2.

In FIGS. 9A through 11, some embodiments of the present disclosure are illustrated. However, those skilled in the art will recognize that other embodiments of the present disclosure are possible by changing the order of blocks, omitting blocks, or including links not illustrated in the drawings. All such variations of the flowcharts, whether explicitly described or not, are considered embodiments of the present disclosure.

FIG. 12 illustrates a firmware stack of an exemplary polymorphic SSD according to an embodiment of the present disclosure. Here, the polymorphic SSD may be referred to as a polymorphic storage device (PSD).

The PSD firmware stack (1200) may include a flash controller layer (1235), a PSD kernel (1255), a PSD interface layer (1252), and an application container (1210). The application container (1210) may include one or more applications (1211a, 1211b, and 1211c). In this example, the application (1211c) may be a current tenant running on the PSD to distinguish it from other applications (1211a, 1211b). Hereinafter, the applications (1211a, 1211b, and 1211c) may be collectively referred to as 1211.

The firmware of the polymorphic storage device, which defines the operation of the storage device, can be reconfigured through a firmware update. Through a firmware update, the polymorphic storage device can be transformed from its original configuration into a device of a different form. For example, the polymorphic storage device is originally configured as a general-purpose storage device. Through a firmware update, the general-purpose storage device can be transformed into a special-purpose storage device, such as an in-storage computing device, a near-storage computing device, a key-value store device, a Hadoop distributed file system (HDFS) device, an object store device, and a smart SSD having intelligent computing capabilities. Applications running on such special purpose devices or smart SSDs may have various application specific functions including, but not limited to, tagging functions (e.g., image tagging), compression functions (e.g., snappy, gzip, RLE), database functions (e.g., space compaction, predicate evaluation), machine learning functions (e.g., training and inference), and transformation functions (e.g., video transcoding, image sampling, document format conversion (e.g., PDF to PostScript)).

The flash controller layer (1235) includes a virtual flash layer (VFL) (1230) and a flash interface layer (FIL) (1240). The flash controller layer (1235) can provide hardware support to provide increased efficiency of the PSD. Depending on the application (1211) running on the PSD, the flash controller layer (1235) can optimize the use of reconfigurable and expandable hardware to provide an efficient interface to the flash memory. The flash controller layer (1235) can be updated by firmware updates to support the functions of the applications (1211).

Packets (e.g., data, messages, and commands) received from the host machine are first transmitted to the PSD kernel (1255). The context (CTX) manager (1256) and the message router (1257) of the PSD kernel (1255) are responsible for routing the packets received from the host machine. The CTX manager (1256) knows the current tenant application(s) of the PSD and their characteristics. The CTX manager (1256) may include an application ID table for tracking the currently running application and other existing applications and configurations. The CTX manager (1256) also controls the execution and liveness of the current tenant application(s), such as start/stop, resume, and suspend (i.e., context control). The PSD kernel (1255) may decapsulate the routed packets and process the routed packets. For example, when a command to "create" an application (1211) is received, the CTX manager (1256) may create an application context for the application (1211) using host-provided data. The host-provided data may include binary code of the application (1211) executable on the PSD, as well as metadata including a PSD library that allows the application (1211) to communicate with the PSD kernel (1255), as well as configuration profiles or logics.

If a message received from the host machine relates to an application (1211) registered in the PSD, the PSD kernel (1255) may route the message and corresponding data and/or commands to the registered application (1211) if the context of the registered application (1211) is activated. If the context of the registered application (1211) is not activated, the PSD kernel (1255) returns an error message to the host machine. The PSD kernel (1255) may send another error message to the host machine if an unregistered or unrecognized message is received from the host machine.

The CTX manager (1256) is responsible for controlling the application container (1210). The CTX manager (1256) can create an application context of the application (1211) and distribute and manage hardware resources of the PSD. The CTX manager (1256) can be implemented in a fully virtualized manner or a paravirtualized manner similar to a virtual machine (VM). In one embodiment, the application (1211) can be executed as a general firmware on a general storage device without implementing the PSD kernel (1255). In another embodiment, the application (1211) can be executed as a new application specifically designed for the PSD by recognizing the functions provided by the PSD.

Some applications (1211) may require application specific WL and/or GC logics. These logics may be critical to the performance of the PSD. The PSD kernel (1255) provides a PSD library (1258) containing application specific WL/GC interfaces and a generic API to interface with the PSD kernel (1255). In the latter case, the application (1211) may register the provided library instead of implementing its own WL/GC logics. In the former case, the PSD kernel (1255) does not do anything related to WL/GC by providing full privilege to the application (1211) in the layer(s) of the PSD firmware stack (1200).

The application (1211) can communicate with the underlying PSD kernel (1255) via the PSD interface layer (1252). The PSD interface layer (1252) can provide communication APIs and packets (e.g., messages, commands, and data) that are passed to the PSD via the PSD interface layer (1252).

Applications (1211) can coexist in a single PSD in the form of application context(s). An application container (1210) can hold an application context of an application (1211) that can be active or inactive. An application (1211) can include application logics, a host protocol and message processor layer, application specific ATL, WL logic, GC logic, etc. In some embodiments, the WL and GC logics are optional. For example, a key-value store application can have a key-value structure and algorithm for the core logics. The host protocol and message processor layer (1213) can be as simple as a functional wrapper around the core logics. For a key-value store application, the application specific ATL (1214) can be merged into the unified FTL.

Additional logic is not necessarily required from a hardware perspective in modern SSDs, but the following factors can accelerate the execution of the PSD: Examples of factors that can accelerate the execution of the PSD include, but are not limited to, multiple translation lookaside buffers (TLBs) or larger TLBs, caches with application container IDs, memory with more banks and/or more registers per dual in-line memory module (DIMM) to reduce contentions, more flexible support for direct memory access (DMA) and a greater number of superior DMAs, virtualization support for embedded processors, application context-aware flash controllers, fine-grained power control with polymorphism awareness, and hardware-assisted message routing. In another example, the PSD can include a field-programmable gate array (FPGA) to provide accelerated application-specific functions. Applications such as scientific computing, matrix manipulation, fast Fourier transforms (FFTs), pattern matching, and so on in big data processing such as machine learning kernels and neural networks can be accelerated by FPGAs instead of executing code on the CPU of a general-purpose device. In applications such as machine learning kernels, tensor accelerators such as the Tensor Processor Unit (TPU) can accelerate matrix multiplication operations. Specialized hardware such as compressors and encryption engines can also be used for better space utilization and security.

An application (1211) running on a PSD can support various namespaces. In this example, application (1211a) supports namespace (NS1), application (1211b) supports namespaces (NS2, NS3), and application (1211d) supports namespaces (NS1, NS4). An application (1211) can run on multiple namespaces, but some namespaces can be shared between multiple applications (1211).

According to one embodiment, the PSD kernel (1255) can receive host commands related to a specific namespace through the PSD interface. A namespace is a logical management unit and provides separation of interfaces, address spaces, data formats, performance, and security from other namespaces. A namespace can be created statistically or dynamically depending on the PSD capability. The PSD kernel (1255) can configure memory blocks of the non-volatile memory of the PSD to associate the memory blocks with a namespace and manage mapping information between the namespace and the allocated memory blocks.

If no namespace is specified, the operation is processed in the global namespace of the device in the PSD. A namespace can be associated with two or more applications running in the application container, and an application can be associated with two or more namespaces. In this example, multiple applications (1211) (e.g., NoSQL applications) run in the same namespace. Meanwhile, an application (1211) can work with two or more namespaces. For NoSQL applications, one namespace can be assigned to a block interface and another namespace can be assigned to a key-value interface. In this case, metadata can be stored in the key-value namespace, and data can be stored in the block namespace.

According to one embodiment, a storage device can include an application container including one or more applications, wherein each of the one or more applications executes in one or more namespaces, the one or more namespaces being implemented within the storage device and configured to provide a host-side interface to a host machine and to receive a plurality of packets including data, messages and commands from the host machine via the host-side interface, and to route the plurality of packets to applications within the application container based on namespaces associated with the plurality of packets; and a non-volatile memory. The PSD kernel is further configured to provide a key-value interface and a block interface to the non-volatile memory based on the namespaces associated with the plurality of packets. The non-volatile memory stores a plurality of block data accessible via the block interface, and stores a plurality of key-value data accessible via the key-value interface.

The following discussion is intended to provide a brief general description of suitable machine or machines in which aspects of the present disclosure may be implemented. The machine or machines may be controlled, at least in part, by input from conventional input devices such as a keyboard, mouse, and the like, as well as instructions received from other machines, interaction with a virtual reality (VR) environment, biofeedback, or other input signals. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, phones, tablets, and the like, as well as transportation devices such as personal or public transportation (e.g., automobiles, trains, taxis, and the like).

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, etc. The machine or machines may utilize one or more connections to one or more remote machines, such as via a network interface, modem, or other communications coupling. The machines may be interconnected by physical and/or logical networks, such as an intranet, the Internet, a LAN, a WAN, etc. Those skilled in the art will appreciate that network communications may utilize 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 disclosure may be described by reference to or in conjunction with related data, including functions, procedures, data structures, application programs, which, when accessed by a machine, perform tasks or result in a machine defining an abstract data form or low-level hardware context. For example, the related data may be stored in volatile storage devices and related storage media, such as RAM, ROM, and/or hard drives, floppy disks, optical storage, tape, flash memory, memory sticks, digital video disks, biological storage, and the like. The related data may be transmitted over a transmission environment, including a physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, and the like, and may be used in a compressed or encrypted format. The related data may be used in a distributed environment and may be stored locally and/or remotely for machine access.

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

While the principles of the present disclosure have been described and illustrated with reference to exemplary embodiments, it will be appreciated that the illustrated embodiments may be varied in arrangement and detail and combined in any desired manner without departing from such principles. And while the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, although expressions such as “according to an embodiment of the present disclosure” and the like may be used herein, these phrases are intended to refer generally to the possibility of embodiments and are not intended to limit the present disclosure to a particular embodiment configuration. As used herein, these terms may refer to the same or different embodiments that may be combined with other embodiments.

The above-described exemplary embodiments should not be construed as limiting the present disclosure. Although several embodiments have been described, those skilled in the art will readily appreciate that many modifications can be made to these embodiments without substantially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the claims.

Embodiments of the present disclosure can be extended without limitation to the following statements:

Statement 1. A storage device of an embodiment of the present disclosure comprises: a storage memory for storing data; a host interface for managing communication between the storage device and a host machine; a translation layer for converting a first address received from the host machine into a second address of the storage memory; a storage interface for accessing the data from the second address in the storage memory; and an in-storage monitoring engine for determining a characteristic of the storage device, wherein the characteristic is derived from a set including a latency, a bandwidth, and a retention of the storage device.

Statement 2. An embodiment of the present disclosure comprises: the storage device according to statement 1 comprises a solid state drive (SSD); the storage memory comprises a flash memory storing the data; the translation layer comprises a flash translation layer (FTL) for translating the first address received from the host machine into the second address of the flash memory; and the storage interface comprises a flash interface for accessing the data from the second address of the flash memory.

Statement 3. The storage device according to statement 1 of the embodiment of the present disclosure additionally includes a storage device controller including the host interface, the storage interface and the in-storage monitoring engine.

Statement 4. The storage device according to statement 1 of the embodiment of the present disclosure further comprises a polymorphic device kernel including the in-storage monitoring engine.

Statement 5. The in-storage monitoring engine of the storage device according to statement 1 of the embodiment of the present disclosure operates to measure the characteristic of the storage device without the characteristic being affected by the conversion layer.

Statement 6. The in-storage monitoring engine of the storage device according to statement 1 of the embodiment of the present disclosure operates to measure the characteristic of the storage device including the characteristic affected by the conversion layer.

Statement 7. The conversion layer of the storage device according to statement 6 of the present disclosure is specific to the application on the host machine.

Statement 8. The in-storage monitoring engine of the storage device according to statement 1 of the embodiment of the present disclosure can measure the characteristic of the storage device for a specific type of profiling command.

Statement 9. The specific form of profiling command of the storage device according to statement 8 of the present disclosure is specified by the application on the host machine.

Statement 10. The in-storage monitoring engine of the storage device according to statement 1 of the present disclosure operates to measure the characteristic of the storage device using a specific set of request sizes.

Statement 11. The request sizes of the specific set of storage devices according to statement 10 of the present disclosure are specified by the application on the host machine.

Statement 12. The in-storage monitoring engine of the storage device according to statement 1 of the embodiment of the present disclosure operates to periodically measure the characteristic of the storage device.

Statement 13. The in-storage monitoring engine of the storage device according to statement 12 of the embodiment of the present disclosure operates to report a change in the characteristic of the storage device to the host machine.

Statement 14. The in-storage monitoring engine of the storage device according to statement 1 of the embodiment of the present disclosure comprises: a virtual storage table storing information about a plurality of virtual storage devices within the storage device; and a profiling station for managing a plurality of profiling commands for at least one of the plurality of virtual storage devices within the storage device.

Statement 15. At least one of the plurality of profiling commands of the storage device according to statement 14 of the present disclosure comprises a specific form of a profiling command to perform on at least one of the plurality of virtual storage devices within the storage device.

Statement 16. At least one of the plurality of profiling commands of the storage device according to statement 14 of the present disclosure comprises at least one request size used when performing the profiling command.

Statement 17. The in-storage monitoring engine of the storage device according to statement 14 of the present disclosure additionally includes a profiling code register that stores information regarding how to execute at least one of the plurality of profiling commands.

Statement 18. The profiling code register of the storage device according to statement 17 of the present disclosure is user configurable.

Statement 19. The in-storage monitoring engine of the storage device according to statement 14 of the present disclosure additionally includes a performance table to store information about previous profiling commands.

Statement 20. At least one of the plurality of profiling commands of the storage device according to statement 19 of the embodiment of the present disclosure may satisfy information in the performance table.

Statement 21. At least one of the plurality of profiling commands of the storage device according to statement 14 of the present disclosure may include a priority.

Statement 22. A method of an embodiment of the present disclosure comprises receiving a profiling command from a requester in a storage device, the profiling command specifying a characteristic of the storage device to be determined; performing the profiling command internally in the storage device to generate a result; and returning the result to the requester from the storage device.

Statement 23. In the method according to statement 22 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command from the requester in a solid state drive (SSD), performing the profiling command internally in the storage device comprises performing the profiling command internally in the SSD to generate the result, and returning the result to the requester from the storage device comprises returning the result to the requester from the SSD.

Statement 24. Receiving the profiling command from the requester in the storage device according to statement 22 of the embodiment of the present disclosure comprises receiving the profiling command from an application in the storage device.

Statement 25. Receiving the profiling command from the requester in the storage device according to statement 22 of the embodiment of the present disclosure comprises receiving the profiling command from a host machine in the storage device.

Statement 26. The method according to statement 22 of the present disclosure, wherein receiving the profiling command from the requester at the storage device comprises receiving the profiling command from the requester at the storage device without receiving any request sizes from the requester for use in performing the profiling command.

Statement 27. Executing the profiling command internally in the storage device to generate the result of the method according to statement 22 of the present disclosure comprises performing the profiling command in a virtual storage device within the storage device to generate the result.

Statement 28. The method according to statement 22 of the present disclosure, wherein performing the profiling command internally in the storage device to generate the result comprises one of determining latency of the storage device as the result, determining bandwidth of the storage device as the result, and determining retention of the storage device as the result.

Statement 29. The method according to statement 28 of the present disclosure, wherein receiving the profiling command from the requester at the storage device comprises receiving the profiling command from the requester at the storage device without receiving any request sizes from the requester for use in executing the profiling command, and determining the latency of the storage device as a result comprises determining the latency of the storage device as a result using internally generated request sizes.

Statement 30. In the method according to statement 28 of the present disclosure, receiving the profiling command from the requester at the storage device comprises receiving the profiling command and a plurality of request sizes from the requester at the storage device, and determining the latency of the storage device as the result comprises determining the latency of the storage device as the result using the request sizes.

Statement 31. The method according to statement 28 of the present disclosure, wherein receiving the profiling information from the requester at the storage device comprises receiving the profiling command at the storage device from the requester without receiving any request sizes from the requester for use in executing the profiling command, and wherein determining the bandwidth of the storage device as a result comprises determining the bandwidth of the storage device as a result using internally generated request sizes.

Statement 32. The method according to statement 28 of the present disclosure, wherein receiving the profiling information from the requester in the storage device comprises receiving the profiling command and a plurality of request sizes from the requester in the storage device, and determining the bandwidth of the storage device as the result comprises determining the bandwidth of the storage device as the result using the request sizes.

Statement 33. Executing the profiling command internally in the storage device to generate the result of the method according to statement 22 of the present disclosure includes storing the result in a performance table.

Statement 34. A method according to statement 22 of the present disclosure further comprises receiving a second profiling command from a second requester at the storage device, examining the performance table to determine whether the result in the performance table satisfies the second profiling command, and if the result satisfies the second profiling command, returning the result in the performance table from the storage device to the requester.

Statement 35. The method according to statement 22 of the present disclosure further comprises constructing a virtual storage table storing information about at least one virtual storage device in the storage device.

Statement 36. The method according to statement 22 of the present disclosure, wherein performing the profiling command internally in the storage table to generate the result comprises converting the profiling command received from the requester into an internal profiling command, and performing the internal profiling command to generate the result.

Statement 37. The method according to statement 22 of the present disclosure, wherein performing the profiling command internally in the storage table to generate the result comprises performing the profiling command internally in the storage device to measure the characteristic of the storage device without the characteristic being affected by the conversion layer.

Statement 38. The method according to statement 22 of the present disclosure, wherein performing the profiling command internally in the storage table to generate the result comprises performing the profiling command internally in the storage device to measure the characteristic of the storage device including the characteristic affected by the transformation layer.

Statement 39. An article of the present disclosure comprises a tangible storage medium having non-transitory instructions stored thereon, wherein when executed by a machine, the instructions comprise: receiving a profiling command from a requester at the storage device, the profiling command specifying a determined characteristic of the storage device; performing the profiling command internally at the storage device to produce a result; and returning a result from the storage device to the requester.

Statement 40. In the article according to statement 39 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command from the requester in a solid state drive (SSD), performing the profiling command internally in the storage device to generate the result comprises performing the profiling command internally in the SSD to generate the result, and returning the result to the requester from the storage device comprises returning the result to the requester from the SSD.

Statement 41. Receiving the profiling command from the requester in the storage device of the article according to statement 39 of the present disclosure comprises receiving the profiling command from the requester in the storage device without receiving any request sizes from the requester for use in performing the profiling command.

Statement 42. Receiving the profiling command from the requester in the storage device of the article according to statement 39 of the present disclosure comprises receiving the profiling command from a host machine in the storage device.

Statement 43. Receiving the profiling command from the requester in the storage device of the article according to statement 39 of the present disclosure comprises receiving the profiling command from the requester in the storage device without receiving any request sizes from the requester for use in performing the profiling command.

Statement 44. Executing the profiling command internally in the storage device to produce the result of the article according to statement 39 of the present disclosure comprises performing the profiling command in a virtual storage device within the storage device to produce the result.

Statement 45. Executing the profiling command internally in the storage device to produce the result of the article according to statement 39 of the present disclosure comprises one of determining latency of the storage device as the result, determining bandwidth of the storage device as the result, and determining retention of the storage device as the result.

Statement 46. In the article according to statement 45 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command from the requester in the storage device without receiving any request sizes from the requester for use in executing the profiling command, and determining the latency of the storage device as a result comprises determining the latency of the storage device as a result using internally generated request sizes.

Statement 47. In the article according to statement 45 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command and a plurality of request sizes from the requester in the storage device, and determining the latency of the storage device comprises determining the latency of the storage device as a result using the request sizes.

Statement 48. In the article according to statement 45 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command from the requester in the storage device without receiving any request sizes from the requester for use in executing the profiling command, and determining the bandwidth of the storage device as a result comprises determining the bandwidth of the storage device as a result using internally generated request sizes.

Statement 49. In the article according to statement 45 of the present disclosure, receiving the profiling command from the requester in the storage device comprises receiving the profiling command and a plurality of request sizes from the requester in the storage device, and determining the bandwidth of the storage device as a result comprises determining the bandwidth of the storage device as a result using the request sizes.

Statement 50. Executing the profiling command internally in the storage device to generate the result of the article according to statement 39 of the present disclosure comprises storing the result in a performance table.

Statement 51. The article of claim 39 of the present disclosure further comprising non-transitory instructions stored on the storage medium of the type, wherein when executed by the machine, the instructions comprise receiving a second profiling command from a second requester at the storage device, examining the performance table to determine whether the result in the performance table satisfies the second profiling command, and if the result satisfies the second profiling command, returning the result in the performance table from the storage device to the requester.

Statement 52. The article of claim 39 of the present disclosure further comprising non-transitory instructions stored in the storage medium of the type, wherein when executed by the machine, the instructions comprise constructing a virtual storage table storing information about at least one virtual storage device within the storage device.

Statement 53. Executing the profiling command internally in the storage device to generate the result of the article according to statement 39 of the present disclosure comprises converting the profiling command received from the requester into an internal profiling command, and executing the internal profiling command to generate the result.

Statement 54. Performing said profiling command internally in said storage device to produce said result of said article according to statement 39 of the present disclosure comprises performing said profiling command internally in said storage device to measure said characteristic of said storage device without said characteristic being affected by a conversion layer.

Statement 55. Performing said profiling command internally in said storage device to produce said result of said article according to statement 39 of the present disclosure comprises performing said profiling command internally in said storage device to measure said characteristic of said storage device, including said characteristic affected by a transformation layer.

Consequently, in view of the various permutations of the embodiments described herein, the detailed description and accompanying materials are intended to be exemplary only and should not be considered limiting the scope of the present disclosure. Therefore, what is claimed as the present disclosure is all such modifications that may come within the scope and spirit of the following claims and their equivalents.

105: Data Center 110, 115, 120, 125, 130: Host Machines
135: Network 140: Client Machine
205: Processor 210: Memory
215: Network connector 220: SSD, storage device
320: Bus 345: User Interface
350: I/O Engine 410: SSD Controller
405: Circuit for sending and receiving information to the host machine.
415: Storage Memory 420: Host Interface
425: In-Storage Monitoring Engine 430: Flash Conversion Layer
435: Error correction code 440: Flash interface
505, 510, 515, 520, 1211a, 1211b, 1211c: Applications
525, 530, 535, 540: Processor 545: Memory
550, 555, 560, 565: Polymorphic interface hierarchy
570: Polymorphic Interface Kernel 575: Hardware Application Layer
605: Latency 610: Bandwidth
615: Hold 620: Light Amplification Factor (WAF)
625: Transactions per second (TPS) 630: Queuing latency
710: Virtual Flash Interface 720, 725: Request Size
705, 715: measurement 805: op queue
810: Decoder 815: Command Queue
820: Code register 825: Virtual storage table
830: Performance Table 835: Profiling Station
840: Event Trigger
1200: Polymorphic Storage Device (PSD) Firmware Stack
1210: Application Container 1252: PSD Interface Layer
1255: PSD Kernel 1256: Context Manager
1257: Message Router 1258: PSD Libraries
1230: Virtual Flash Layer 1235: Flash Controller Layer
1240: Flash Interface Layer

Claims (20)

An application container comprising one or more applications, each of said one or more applications running in one or more namespaces;
Flash memory that stores data;
A host interface that manages communication between the storage device and the host machine;
A flash translation layer that converts a first address received from the host machine into a second address of the flash memory;
a flash interface for accessing the data from the second address of the flash memory; and
Comprising a polymorphic device kernel implemented within said storage device including an in-storage monitoring engine,
The polymorphic device kernel receives a plurality of packets from the application running on the storage device, and provides the flash interface based on the namespace associated with the plurality of packets,
The in-storage monitoring engine determines dynamic characteristics of the storage device at run-time based on at least a portion of the matching of profiling commands received from the host machine within the performance table,
The above dynamic characteristics are derived from a set including latency, bandwidth, retention, light amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device. In the first aspect, the application is a storage device running in two or more namespaces. In the first paragraph, the namespace is a storage device shared by two applications. In the first paragraph, the storage device is a storage device capable of performing one of a tagging function, a compression function, a database function, a pattern matching function, a machine learning function, and a conversion function. In the first paragraph, the in-storage monitoring engine
Executing the profiling command from the requester on the storage device to determine the dynamic characteristics of the storage device at run-time;
Returning the result from the storage device to the requester,
Receive a second profiling command from a second requester in the above storage device,
Determine whether the above performance table includes the result satisfying the second profiling command,
A storage device that returns the result in the performance table from the storage device to the second requester without performing the second profiling command, based on at least a portion of the performance table including the result satisfying the second profiling command. In the first aspect, the storage device further comprises a storage device controller including the host interface and the flash interface. In the first aspect, the flash conversion layer is a storage device specific to an application running on the host machine. In the first aspect, the in-storage monitoring engine is a storage device that measures the dynamic characteristics of the storage device for a specific type of profiling command. In the first paragraph, the in-storage monitoring engine
A virtual storage table storing information about a plurality of virtual storage devices within the storage device; and
A storage device comprising a profiling station for managing a plurality of profiling commands in at least one of the plurality of virtual storage devices within the storage device. In claim 9, the in-storage monitoring engine further comprises a storage device including a profiling code register that stores information regarding how to execute at least one of the plurality of profiling commands. In the 9th paragraph, the performance table is a storage device that stores information about previous profiling commands. Storing one or more applications within an application container of a storage device, wherein each of the one or more applications runs in one or more namespaces;
Receive multiple packets from a host machine through the host interface;
Executing a polymorphic storage device kernel implemented on the storage device to route the plurality of packets to an application within the application container through a flash interface based on a namespace associated with the plurality of packets;
Comprising executing an in-storage monitoring engine to determine dynamic characteristics of the storage device at run-time based on at least a portion of the matching of profiling commands received from the host machine within the performance table;
The above dynamic characteristics are derived from a set including latency, bandwidth, retention, light amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device. In the 12th paragraph, the application is a method executed in two or more namespaces. In the 12th paragraph, the namespace is shared by two applications. A method in accordance with claim 12, wherein the storage device can perform one of a tagging function, a compression function, a database function, a pattern matching function, a machine learning function, and a transformation function. In the 12th paragraph, the method
Receive a first profiling command from a requester in the above storage device,
To generate a result, the first profiling command is performed internally in the storage device,
Return the result from the SSD to the requester,
Receive a second profiling command from a second requester in the above storage device,
Determine whether the above performance table includes the result satisfying the second profiling command,
A method comprising returning the result in the performance table from the storage device to the second requester without performing the second profiling command, based on at least a portion of the performance table including the result satisfying the second profiling command. In the 12th paragraph, the in-storage monitoring engine is a method for measuring the dynamic characteristics of the storage device for a specific type of profiling command. In the 12th paragraph, the in-storage monitoring engine
A virtual storage table storing information about a plurality of virtual storage devices within the storage device; and
A method comprising a profiling station for managing a plurality of profiling commands on at least one of the plurality of virtual storage devices within the storage table. In claim 18, the method further comprises a profiling code register that stores information regarding how to execute at least one of the plurality of profiling commands. In the 18th paragraph, the performance table is a method for storing information about previous profiling commands.