Storage device and method for self-monitoring of storage device characteristics

Abstract

A storage device and a method for self-monitoring storage device characteristics are provided. The storage device (220) includes: an application container containing applications, each running in one or more namespaces; flash memory for storing data; a host interface for managing communication between the storage device and a host; a flash translation layer for translating a first address received from the host into a second address in the flash memory; a flash interface for 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 multiple data packets from applications running on the storage device and provides the flash interface based on namespaces associated with the multiple data packets. The in-storage monitoring engine determines the dynamic characteristics of the storage device at runtime based on matching profiling commands received from the host in a performance table.

Description

Technical Field

[0001] The inventive concept generally relates to solid-state drives (SSDs), and more specifically, to determining SSD characteristics from within an SSD. Background Technology

[0002] Storage devices (specifically, solid-state drives (SSDs)) exhibit characteristics that change continuously over time. Due to the underlying software (i.e., firmware) and / or hardware within the SSD, it can have unpredictable latency and / or bandwidth. For example, NAND flash memory can have prolonged read / write latency due to read / write errors. Increased access latency (read / program / erase) due to cell wearing also affects latency and / or bandwidth. The virtual abstraction of SSD resources (i.e., different approaches such as polymorphic SSDs, open channel SSDs, and lightNVM (a subsystem supporting open channel SSDs)) makes it difficult to predict SSD performance characteristics. Finally, different cell densities (such as single-cell (SLC), multi-cell (MLC), three-cell (TLC), and four-cell (QLC)) can have different characteristics.

[0003] Thus, dynamic latency and bandwidth monitoring / profiling are useful in data centers for reducing unpredictable latency, which can potentially contribute to long-tail latency. Achieving such performance enhancements is very challenging because measurements are often complex. For example, approximating a curve by randomly selecting measurement points not only requires numerous measurements but also makes it very difficult to guarantee a certain level of performance.

[0004] That said, the device possesses its own best knowledge. That is, the device's architecture provides many clues about what might contribute to saturated bandwidth. For example, the number of NAND channels, the number of controllers, the command queue depth, and the number of queues can be clues for estimating the number of requests or for measuring the duration of reliable performance data. However, devices outside the SSD do not have meaningful access to this information.

[0005] There is still a need for a method for SSDs to provide profiling information to external devices. Summary of the Invention

[0006] According to an embodiment of the inventive concept, a storage device (200) is provided, the storage device comprising: an application container containing one or more applications, wherein each of the one or more applications runs in one or more namespaces; flash memory (415) for storing data; a host interface (420) for managing communication between the storage device (220) and a host (110, 115, 120, 125, 130); a flash translation layer (430) for translating a first address received from the host into a second address in the flash memory (415); a flash interface (440) for accessing data from the second address in the flash memory (415); and A polymorphic device kernel is implemented within the storage device (220) including an in-storage monitoring engine (425), wherein the polymorphic device kernel is configured to receive multiple data packets to an application running on the storage device and to provide a flash interface based on namespaces associated with the multiple data packets, wherein the in-storage monitoring engine determines the dynamic characteristics of the storage device at runtime based at least in part on matching profiling commands received from the host in a performance table, and wherein the dynamic characteristics are extracted from a set including latency, bandwidth, save, write amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device (220).

[0007] According to an embodiment of the inventive concept, a method is provided, the method comprising: storing one or more applications in an application container of a storage device, wherein each of the one or more applications runs in one or more namespaces; receiving a plurality of data packets from a host via a host interface; running a polymorphic storage device kernel implemented on the storage device to route the plurality of data packets to the applications in the application container via a flash interface based on namespaces associated with the plurality of data packets; and running an in-storage monitoring engine to determine dynamic characteristics of the storage device at runtime based at least in part on matching profiling commands received from the host in a performance table, wherein the dynamic characteristics are extracted from a set including latency, bandwidth, save, write amplification factor (WAF), transactions per second (TPS), and queuing latency of the storage device. Attached Figure Description

[0008] Figure 1 This illustrates a data center with various hosts communicating with clients.

[0009] Figure 2 Examples of embodiments according to the inventive concept are shown. Figure 1 Details of the host machine.

[0010] Figure 3 Show Figure 1 Additional details about the host.

[0011] Figure 4 An embodiment based on the inventive concept is shown. Figure 2 Details of solid-state drives (SSDs).

[0012] Figure 5 Another embodiment according to the inventive concept is shown. Figure 2 Details of the SSD.

[0013] Figure 6 It can be shown that Figure 2 Various characteristics measured within the SSD.

[0014] Figures 7A to 7B Measurements according to embodiments of the inventive concept are shown. Figure 6 Different ways of exhibiting characteristics.

[0015] Figure 8 Showing the use of Figure 4 The architecture of the in-storage monitoring engine.

[0016] Figures 9A to 9B An embodiment of the invention is shown for use. Figure 4 The in-storage monitoring engine determines Figures 4 to 5 A flowchart illustrating the characteristics of an SSD.

[0017] Figure 10 An embodiment of the invention is shown for use. Figure 4 The flowchart illustrates an example process by which the in-storage monitoring engine receives profiling commands and the optional data used when executing those commands.

[0018] Figure 11 Showing the methods used to determine Figure 2 A flowchart illustrating the different characteristics of an SSD.

[0019] Figure 12 The firmware stack of an example polymorphic SSD is shown according to an embodiment of the inventive concept. Detailed Implementation

[0020] Referring now 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 provide a thorough understanding of the inventive concept. However, it should be understood that those skilled in the art can practice the inventive concept without these specific details. In other instances, well-known methods, processes, components, circuits, and networks are not described in detail to avoid unnecessarily obscuring aspects of the embodiments.

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

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

[0023] Storage device characteristics are more complex than ever before: heterogeneous performance, time-varying performance, and varying access latency / bandwidth due to different uses. Despite numerous efforts to model this diversity, such modeling has not yet been successful. Instead, continuous profiling / monitoring methods have historically proven more reliable and capable of performance prediction or long-tail latency analysis and prevention.

[0024] Conventional storage device analytics suffers from two fundamental problems. First, important events or information may be hidden within the storage device itself. Second, performance characterization without prior information makes prediction a real challenge.

[0025] Embodiments of the inventive concept 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 can generate appropriate profiling procedures within the storage device. Novel vendor commands can be used to send desired information on a virtual storage device implemented within the physical storage device. The host can send a single command to profil / monitor device performance. Simultaneously, the storage device can generate profiling vectors based on this command. This approach not only reduces unnecessary data transfer between the host and the storage device but also improves efficiency by transmitting only the results rather than data used to measure performance.

[0026] Furthermore, the storage device can detect changes in its characteristics (such as changes in error correction code (ECC), read / write retry settings, and single-level cell (SLC) / multi-level cell (MLC) modes). The in-storage monitoring engine can compare new performance data with data in a performance table that stores information about the past performance of the in-storage monitoring engine and updates performance reports as needed.

[0027] The in-storage monitoring engine can parse profiling commands and generate profiling vectors. The host can send new vendor commands to initiate monitoring / profiling.

[0028] Depending on the host's requirements, the in-storage monitoring engine can measure latency / bandwidth at different tiers. For example, see the following reference. Figures 7A to 7B The monitoring discussed may include any latency / bandwidth caused by the Flash Translation Layer (FTL), or monitoring may bypass the FTL. Because monitoring can avoid latency caused by the Address Translation Layer (ATL), Garbage Collection (GC), and Wear Leveling (WL), bypassing the FTL can eliminate unpredictable performance issues from the storage device. Such a measurement layer can be explicitly specified in a command or obtained from a virtual memory table (which contains storage configurations including ATL, GC, and WL information).

[0029] The following is for reference Figure 8 Let's further discuss the implementation of our proposed profiling / monitoring engine. As shown, once the decoder detects a profiling / monitoring command, it sends the command to the command queue of the in-memory monitoring engine. Because performance characterization can take relatively long times (from microseconds to minutes), there may be multiple pending commands in the queue, and a command can be preempted based on the priority given to each command.

[0030] A virtual storage table can store virtual storage IDs (virtual storage IDs distinguish different virtual storage devices on a specific physical storage device). A virtual storage table can be a copy of a table maintained by the main controller of the physical storage device or a shared register. A performance table can store the history of previous performance characteristics associated with a virtual storage ID.

[0031] The profiler register may contain operation vectors used to characterize memory performance. The profiler register may be self-generated or user-programmable. For example, in most cases, latency characteristics exhibit a linear function related to the request size (i.e., 4KB read, 8KB read, etc.). Therefore, performance characterization can be performed in different ways. A host or user application may send a query to the device without specifying an exact measurement point. In this case, the profiler register can generate measurement / profile points. Alternatively, the host or application may specify measurement points in the command.

[0032] Profile registers can play a significant role in reporting other performance characteristics, such as bandwidth prediction. Unlike latency, which tends to scale linearly with request size, bandwidth typically exhibits a logarithmic curve with a saturation point. Therefore, bandwidth is more complex to measure than latency. Profile registers can maintain a small but effective set of measurement points using priority information provided by the vendor or information acquired through machine learning techniques. All such details can be hidden within the storage device, allowing for easy abstraction of virtual storage devices with associated performance metrics.

[0033] New vendor commands can be provided to allow a host or application to request profiling information. Such vendor commands may include new OP (or Op) codes, inputs (such as arrays of operation types and request sizes), and outputs.

[0034] Figure 1 This illustrates a data center with various hosts communicating with clients. Figure 1 In the diagram, data center 105 is shown as including hosts 110, 115, 120, 125, and 130. See below for further details. Figures 2 to 3 Further details regarding hosts 110, 115, 120, 125, and 130 are shown. Data center 105 may also include network 135, which allows hosts 110, 115, 120, 125, and 130 to communicate with each other and with client 140. Network 135 can be any type of network, including local area network (LAN) or wide area network (WAN). Network 135 can use wired technologies (such as Ethernet), wireless technologies (such as any or equivalent or alternative technologies of IEEE 802.11a / b / g / n / ac), or a combination of both. Additionally, although... Figure 1 It is suggested that hosts 110, 115, 120, 125, and 130 be located in a single geographical area, but in other embodiments of the inventive concept, hosts 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)).

[0035] Although Figure 1While hosts 110, 115, 120, 125, and 130 are shown as identical and all being tower computers, embodiments of the inventive concept can support any desired format for hosts 110, 115, 120, 125, and 130, and these formats can all be different. For example, some hosts 110, 115, 120, 125, and 130 can be tower computers of various models and manufactures, while others 110, 115, 120, 125, and 130 can be rack servers of various models and manufactures. Different hosts 110, 115, 120, 125, and 130 can have different capabilities in terms of processor power, available memory, and available storage, and all hosts 110, 115, 120, 125, and 130 can have varying formats. For example, some hosts 110, 115, 120, 125, and 130 may use Dynamic Random Access Memory (DRAM) as a component, 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 Magnetoresistive Random Access Memory (MRAM)). Similarly, some hosts 110, 115, 120, 125, and 130 may use conventional hard disk drives for storage, while others may use flash memory (various types of NVRAM) or MRAM. Other possibilities, whether or not they are enumerated herein, are also within the scope of the inventive concept.

[0036] As stated above, hosts 110, 115, 120, 125, and 130 are essentially equivalent and interchangeable. Therefore, any reference to host 110 in the remainder of this document is intended to include any and all of hosts 110, 115, 120, 125, and 130 without limitation.

[0037] Although Figure 1 Client 140 is shown as a conventional mini-tower computer system with a monitor, keyboard, and mouse; however, client 140 can take any desired form (including laptops, tablets, smartphones, and any other desired technical format). Additionally, although Figure 1 A single client 140 is shown, but embodiments of the inventive concept can support any number of clients 140 simultaneously.

[0038] Figure 2 Examples of embodiments according to the inventive concept are shown. Figure 1 Details of the host 110. Figure 2In the diagram, host 110 is shown as including processor 205 (also referred to as a central processing unit (CPU)), memory 210, network connector 215, and solid-state drive (SSD) 220. Processor 205 can be any type of processor: for example, Intel Xeon, Celeron, Itanium or Atom processors, AMD Opteron processors, ARM processors, etc. As mentioned above, memory 210 can be any type of memory, such as flash memory, SRAM, PRAM, etc., but typically DRAM. Network connector 215 can be used to connect host 110 to... Figure 1 The network 135 can use any type of connector: for example, an Ethernet interface or a wireless interface. The SSD 220 can be any type of SSD suitable for operation as described in the inventive concept. Although host 110 is shown as including SSD 220, embodiments of the inventive concept can support the use of any storage device whose latency, bandwidth, and other operating characteristics are generally statically defined.

[0039] Figure 3 Show Figure 1 Additional details for host 110. See also... Figure 3 Typically, the host or machine 110 includes one or more processors 205, which may include a memory controller 315 and a clock 320. The processors 205 can be used to coordinate the operation of components of the host or machine 110. The processors 205 may also be connected to memory 210, which, for example, may include random access memory (RAM), read-only memory (ROM), or other state-saving media. The processors 205 may also be connected to storage device 220 and to network connector 215, which may be, for example, an Ethernet connector or a wireless connector. The processors 205 may also be connected to bus 340, and among other components, a user interface 345 and input / output interface ports that can be managed using the input / output engine 350 may be attached to bus 340.

[0040] Figure 4 An embodiment based on the inventive concept is shown. Figure 2 Details of the SSD 220. Figure 4 In this context, SSD 220 may include circuitry 405 that can be used to send and receive information (such as operations or data) to and from host 110. SSD 220 may also include an SSD controller 410 and storage memory 415, which may be flash memory. The SSD controller 410 controls the operation of SSD 220. Storage memory 415 can store data composed of... Figure 1 The data used by the various computers of host 110 and client 140.

[0041] Among other components, the SSD controller 410 may include a host interface 420, an in-storage monitoring engine 425, a flash translation layer (FTL) 430, an error correction code (ECC) 435, and a flash interface 440. The host interface 420 manages the SSD 220 and... Figure 1 Communication between host 110 and host 110. See below for reference. Figures 6 to 8 The in-storage monitoring engine 425, described further, can perform monitoring of the SSD 220 to analyze its characteristics. The FTL 430 can perform (as described by...) Figure 1 The host 110 uses a translation between logical block addresses (LBAs) and physical block addresses (PBAs) within the flash memory 415. The ECC 435 can use error-correcting codes to provide protection against data corruption and / or errors due to wear and tear on the storage memory 415. The flash interface 440 manages access to (reading and writing) data from the flash memory 415.

[0042] exist Figure 4 In this context, SSD 220 can refer to an SSD using a single interface. This means that regardless of how the SSD 220 operates, it operates identically for all applications. For example, the SSD 220 can provide regular file storage, object storage, or key-value storage; but regardless of which, Figure 4 The SSD 220 in this example is limited to this single interface. (This does not mean that the SSD 220 cannot support multiple virtual storage devices, but rather that it can...) Figure 4 (All virtual storage devices within the SSD 220 shown use the same interface.) However, in other embodiments of the inventive concept, the SSD 220 may support multiple different interfaces. In such embodiments of the inventive concept, the SSD 220 may be a polymorphic SSD.

[0043] Figure 5 Such an embodiment according to the inventive concept is shown. Figure 2 Details of the SSD 220.

[0044] In embodiments where the SSD 220 of the inventive concept is replaced by another storage device technology (e.g., a hard disk drive) instead of flash memory, the storage memory 415 may use another technology (such as magnetic bits stored on the disk). Corresponding changes may be made to other parts of the storage device. For example, the FTL 430 may be replaced by a translation layer 430 having similar functionality to the FTL 430 but implemented differently, and the flash interface 440 may be replaced by some other storage interface 440 to access data from the storage memory 415. However, in the remainder of this document, in the context of using the SSD 220 as the storage device, the storage memory 415 will be referred to as flash memory 415.

[0045] exist Figure 5 In this embodiment, SSD 220 is shown as a polymorphic SSD. The polymorphic SSD is further described in U.S. Patent Application No. 15 / 133,085, filed April 19, 2016, which claims priority to 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. SSD 220 also includes circuitry 405 for sending and receiving information (such as operations or data) to and from host 110. SSD 220 may also include... Figure 4 SSD controller 410 ( Figure 5 (Not shown in the image), the SSD controller 410 may include Figure 5 Some or all of the components shown.

[0046] SSD 220 may include applications 505, 510, 515, and 520. These applications can run on processors 525, 530, 535, and 540 within the SSD 220 (this may be referred to as in-memory computing). Memory 545 may support processors 525 through 540. As discussed above, memory 545 can be any desired form of memory, but is typically DRAM. Although Figure 5 The SSD 220 is shown as including four processors 525 to 540 and four applications 505 to 520, but embodiments of the inventive concept can support any number of processors and any number of applications, and different numbers of processors and applications can exist. For example, the SSD 220 may include eight processors running 16 applications.

[0047] Each application 505 through 520 may operate using a different interface. For example, application 505 may use regular file storage, while application 510 may use object storage, and application 515 may use key-value storage. To support these different interfaces, SSD 220 may include different polymorphic interface layers (PILs) 550, 555, 560, and 565 for each application. PILs 550 through 565 provide an interface between the application using any interface desired by the application and the polymorphic device kernel 570. The polymorphic device kernel 570 may then issue instructions to processors 525 through 540 suitable for applications 505 through 520, or to flash memory 415, according to the specific interface used by applications 505 through 520.

[0048] Although Figure 5 The illustration shows applications 505 to 520 running on processors 525 to 540 on SSD 220, but in other embodiments of the inventive concept, applications 505 to 520 can be... Figure 1 The processor within host 110 (such as, Figure 2 It runs on a processor 205. (Assuming it is on a processor 205) Figure 1 (No conversion from various interfaces occurs on host 110) Applications 505 to 520 only need to communicate with the appropriate PIL 550 to 565 within SSD 220.

[0049] Because each different interface can access data within the SSD 220 in different ways, the Hardware Abstraction Layer 575 abstracts how the physical hardware can implement these different interfaces. For example, it compares and contrasts regular file storage with key-value storage. When an application uses regular file storage, it can issue block read and block write commands. For such regular file storage operations, the Hardware Abstraction Layer 575 can be very similar to... Figure 4 It functions similarly to the FTL 430, translating LBAs within applications 505 to 520 into PBAs in flash memory 415. However, applications using key-value storage issue fetch and place commands associated with keys. The key itself is not an LBA, but rather a unique identifier associated with the corresponding value. Objects storing key-value pairs can reside anywhere within flash memory 415. For applications using key-value storage, hardware abstraction layer 575 can translate keys into PBAs in flash memory 415.

[0050] A question might arise: why are the characteristics of SSDs variable? For example, aren't the latency or bandwidth of an SSD constant in all situations? The answer is no, for two reasons. One reason is the operation of applications performing in-storage computations, and the other is the polymorphism of SSDs (such as...). Figure 5 The use of SSD 220.

[0051] When the SSD 220 operates strictly as a storage device using a single interface, its characteristics are not expected to change. However, when applications run in-storage computing, even if all applications use the same interface on the SSD 220, a portion of the SSD 220's computing power is directed towards management applications. With the SSD 220 "distracted" by management applications, it can spend less time processing data requests. Processing fewer data requests in a given interval increases the time required to process those requests, leading to increased latency. Similarly, when the SSD 220 is "distracted" by management applications, its bandwidth can be reduced.

[0052] When SSD 220 is a polymorphic SSD, things can become even more complex. The time required to translate the application's native language into commands for reading data from and / or writing data to flash memory 415 can vary, thus affecting the latency and bandwidth of SSD 220. In other words, the time required to translate a data request into commands that can be processed by SSD 220 can vary depending on the number of applications running and what interfaces they use, causing characteristics to change over time during the operation of SSD 220. Embodiments of the invention provide a technical solution to the problem of determining the current characteristics of SSD 220, and do so more accurately than conventional solutions.

[0053] Figure 6 It can be shown that Figure 2 Some of the various characteristics measured within the SSD 220. 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 can represent the amount of time required to complete a data request. As can be expected, the larger the data request, the... Figure 2 The longer the SSD 220 takes to complete the request, the longer the latency will depend. Latency can also depend on factors such as those mentioned above. Figure 5 The amount of time required for the aforementioned conversion command, and / or depends on how the unit becomes attenuated over time. Bandwidth 610 can represent the time required to... Figure 2 The maximum amount of data that an SSD 220 can send or receive in a given unit of time. 610 can represent data in... Figure 2 How long does data remain in the SSD 220? WAF 620 represents the amount of data the SSD controller must write, in relation to the amount of data the host flash controller must write. TPS 625 represents the number of transactions received per unit of time (e.g., seconds). Queuing latency 630 represents the time a job waits in the queue until it can be executed.

[0054] Figures 7A to 7B Measurements according to embodiments of the inventive concept are shown. Figure 6 The different ways of characteristics 605, 610, and / or 615. In Figure 7A In this context, features 605, 610, and / or 615 can be measured as measurement 705. Measurement 705 measures the features resulting from the polymorphic device kernel 570, the virtual flash interface 710 (the interface between the management application and the flash interface 440), and the flash interface 440, and measurement 705 takes into account all the results of application 505. For example, application 505 can use... Figure 2 The virtual storage device within the SSD 220, and internally manages the flash translation layer. Thus, in Figure 7A In the measurement 705, the result may include the application's internal FTL result, which may include latency due to address translation layer, garbage collection and wear leveling.

[0055] Optionally, in Figure 7B Measurement 715 can be performed without considering the results of the application. Measurement 715 only considers the polymorphic device core 570, the virtual flash interface 710, and the flash interface 440.

[0056] Figure 7A and Figure 7B Both figures illustrate measurements 705 and 715, including request sizes 720 and 725. Different request sizes can be used to measure characteristics to fully determine them. For example, as described above, Figure 6 The delay of a 605 error is typically a linear function of the request size. In the case of two request sizes... Figure 6 The delay of 605 can be interpolated / extrapolated with acceptable accuracy for a range of requested sizes. On the other hand, Figure 6 The bandwidth 610 is typically not a linear function, but rather resembles a logarithmic curve. To generate a function that approximates the relationship between bandwidth and request size, significantly more than two data points may be needed; therefore, more than two request sizes 720 and 725 will be required. Thus, it can be seen that the number of request sizes 720 and 725 used to measure the characteristic can vary depending on the characteristic being measured. Request sizes 720 and 725 can be determined by… Figure 4 The storage monitoring engine 425 generates, or they can be generated in the storage monitoring engine 425. Figure 1 When host 110 requests to measure characteristics by Figure 1 Host 110 is provided.

[0057] Figure 8 Showing the use of Figure 4 The architecture of the in-storage monitoring engine. Figure 8 In this context, Op queue 805 can receive commands. These commands may include commands targeting... Figure 2The SSD 220 receives both profiling commands and other commands: for example, read commands and / or write commands. The decoder 810 determines what command has been received. If the received command is decoded as a profiling command, the profiling command can be passed to the command queue 815 within the in-storage monitoring engine 425. Executing a profiling command can take a relatively long time: for example, from microseconds to minutes. As a result, the in-storage monitoring engine 425 may have multiple pending commands.

[0058] Assuming that the in-memory monitoring engine 425 can only execute so many profiling commands at a time, it is possible that the in-memory monitoring engine 425 may be required to execute more profiling commands than it can process in parallel. To address this issue, each profiling command can also have an associated priority, which can be set when the profiling command is first presented. Figure 1 Application 145 or Figure 1 The host 110 is specified. If the in-storage monitoring engine 425 is required to process more profiling commands than it can handle, the in-storage monitoring engine 425 may determine the lowest priority profiling command and may reject it, notifying the requester that the profiling command cannot be executed. Alternatively, instead of considering all profiling commands, the in-storage monitoring engine 425 may organize profiling commands based on the virtual storage device associated with the profiling command, and may eliminate the lowest priority profiling command associated with the virtual storage device associated with the newly received profiling command.

[0059] Using information from commands in command queue 815, a vector can be accessed from parsing register 820. Parsing register 820 can be used to store information about how to execute at least one of a plurality of parsing commands. For example, a vector from parsing register 820 may contain information about... Figure 6 Delay 605 analysis Figure 2 The specific code required for the SSD 220. As mentioned above, Figure 1 Host 110 can be specified Figures 7A to 7B The request size is 720 and 725, or Figure 1 The host 110 allows the in-storage monitoring engine 425 to determine Figures 7A to 7B The request size is 720 and 725. If the command does not specify... Figures 7A to 7B If the request size is 720 and 725, then Figures 7A to 7B The request sizes 720 and 725 can be determined based on the vector in the parsing code register 820. According to an embodiment of the inventive concept, Figures 7A to 7B The request sizes of 720 and 725 can be self-generated, pre-set by the vendor, or user-analyzable.

[0060] Virtual storage table 825 can store data for use with Figure 2Identifiers for various virtual storage devices on the SSD 220. Virtual storage table 825 stores and... Figure 4 Information similar to that stored in the SSD controller 410, and may be a copy of that information or may be related to it. Figure 4 The SSD controller 410 shares this information.

[0061] Performance table 830 can store information about past profiling commands for virtual memory identifiers. If a profiling command is requested for a virtual memory device that has already been executed, and Figure 2 If the characteristics of the SSD 220 have not changed significantly since the profiling command was executed, the storage monitoring engine 425 can access the storage characteristics from the performance table 830 and return that information to... Figure 1 Host 110.

[0062] If because Figure 2 The characteristics of SSD 220 have changed since the last profiling command was executed (i.e., the characteristics are dynamic characteristics of storage device 220 at runtime), or because... Figure 2 Since the SSD 220 has not been previously profiled for virtual storage devices, and performance table 830 does not store the characteristics of virtual storage devices, the storage monitoring engine 425 can use the profiling station 835 to profil the virtual storage device. Event triggers 840 and / or timer interrupts can be used to manage when various profiling commands start or end. The results of the profiling station 835 can be stored in performance table 830 for future use.

[0063] Analysis station 835 can store in Figure 2 The profiling station 835 contains profiling commands waiting to be executed on the SSD 220, and can be used to manage multiple profiling commands concerning at least one of a plurality of virtual storage devices within the storage device 220. Applications and / or hosts can "occupy" slots in the profiling station 835 until all slots are filled. The profiling station 835 may include an Op and a control; the Op may store Op codes for executing profiling commands, and the control may store information about whether and how pre-emption control is applied to various profiling commands. For example, with profiling... Figure 2 Compared to the latency of the SSD 220, analysis Figure 2 The bandwidth of the SSD 220 may take a relatively long time. Therefore, it is used for profiling. Figure 2The SSD 220's delayed profiling commands can be executed with preemption control. Finally, the status field provides information about the status of the profiling command. For example, the status can use bit fields to indicate whether the profiling command is active, paused, or completed. The status can also use bit fields to indicate parameters of the profiling command, such as the profiling command's priority, the profiling command's preemption status, etc.

[0064] Additionally, the in-memory monitoring engine 425 can periodically repeat earlier profiling commands to determine if the measured characteristics have changed. If the measured characteristics have changed, the in-memory monitoring engine 425 can report the change back to... Figure 1 Application 145 or the host 110 that initially requested the profiling command.

[0065] Figures 9A to 9B An embodiment of the invention is shown for use. Figure 4 The in-storage monitoring engine determines Figures 4 to 5 SSD 220 Figure 6 Flowcharts of example processes for features 605, 610, and / or 615. Figure 9A In the middle, in box 905, Figure 4 The storage-in-monitoring engine 425 can be built Figure 8 Virtual storage table 825, to reflect Figure 2 The available virtual storage device is within the SSD 220. In box 910, Figure 2 The SSD 220 is available from Figure 1 Application 145 or from Figure 1 Host 110 receives the analysis command. This analysis command can specify... Figure 6 Which characteristics in features 605, 610, and / or 615 will be measured, and what type of command will be used can be specified. For example, Figure 1 Application 145 or Figure 1 The host 110 can only handle data writing or data reading. Figure 6 Delay 605 or Figure 6 The bandwidth of 610 is of interest. Alternatively, the profiling command can specify measurements to be taken when garbage collection or wear leveling is performed. Figure 2 The features of the SSD220. Effectively, Figure 2 Any command that can be executed on the SSD 220 can be measured. Finally, the profiling command can be specified during profiling. Figure 2 Any request size used in the SSD 220. As mentioned above, the profiling command does not need to specify any request size; in such cases, Figure 4 The in-storage monitoring engine 425 can determine what request size to use for profiling. Figure 2 The SSD 220.

[0066] In box 915, Figure 2 After the SSD 220 received the profiling command, Figure 2 The SSD 220 can decode profiling commands, converting them into a format that can be used by... Figure 4 The internal profiling commands are processed by the storage monitoring engine 425. This conversion can be implemented for two reasons. First, the received profiling commands can be... Figure 2 SSD 220 (and Figure 4 The storage monitoring engine 425 expects profiling commands to appear and is formatted differently. Secondly, different interfaces for different virtual storage devices can provide commands to request configurations using different formats (and possibly from the internal format of the profiling commands). As a result, translating the received profiling commands into internal profiling commands can be used to... Figure 4 The in-storage monitoring engine 425 presents the profiling commands in the expected format. Box 915 may also contain any additional data required to complete the profiling commands. For example, if Figure 1 Application 145 or Figure 1 Host 110 was not specified. Figures 7A to 7B If the request size is 720 or 725, then the request size can be accessed from the parser register and added to the parser command.

[0067] In box 920 ( Figure 9B ), Figure 4 The in-storage monitoring engine 425 can check whether the results of the profiling command are available. Figure 8 The performance table 830 can be found. If the results of the profiling command are available... Figure 8 If it is found in performance table 830, then in box 925, Figure 4 The storage monitoring engine 425 can be accessed from... Figure 8 The performance table in 830 shows the access results, and in box 930, Figure 4 The storage monitoring engine 425 can return the results of profiling commands to the requester.

[0068] On the other hand, if Figure 8 Performance table 830 does not store the results of the profiling command, or if the results of the profiling command are outdated, then in box 935, Figure 4 The storage monitoring engine 425 can execute profiling commands. Then, in box 940, Figure 4 The in-storage monitoring engine 425 can store the results. Figure 8 The performance table is in 830, and in box 930, Figure 4 The storage monitoring engine 425 can return the results of profiling commands to the requester.

[0069] Although Figures 9A to 9B suggestion Figure 8The virtual storage table 825 is constructed only once, but embodiments of the inventive concept may include modifications as needed. Figure 8 Virtual storage table 825. For example, during operation, new virtual storage devices can be added. Figure 2 The SSD 220. Therefore, when a new virtual storage device is added, Figure 8 Virtual storage table 825 can be updated.

[0070] Figure 10 An embodiment of the invention is shown for use. Figure 4 A flowchart illustrating an example process by which the in-storage monitoring engine 425 receives profiling commands and optional data used when executing those commands. Figure 10 In the middle, in box 1005, Figure 4 The storage monitoring engine 425 can be accessed from... Figure 1 Application 145 receives profiling commands. Optionally, in box 1010, Figure 4 The storage monitoring engine 425 can be accessed from... Figure 1 Host 110 receives the profiling command. Regardless of the method, in box 1015, Figure 4 The in-storage monitoring engine 425 can receive additional data used when executing profiling commands, such as... Figures 7A to 7B The request sizes are 720 and 725, or the priority of the parsing command. As shown by dashed line 1020, box 1015 can be omitted.

[0071] Figure 11 Showing the methods used to determine Figure 2 SSD 220 Figure 6 Flowcharts of example processes for different characteristics 605, 610, and / or 615. Figure 11 In the middle, in box 1105, Figure 4 The in-storage monitoring engine 425 can determine Figure 2 SSD 220 Figure 6 The delay is 605. Optionally, in box 1110, Figure 4 The in-storage monitoring engine 425 can determine Figure 2 SSD 220 Figure 6 The bandwidth is 610. Finally, in box 1115, Figure 4 The in-storage monitoring engine 425 can determine Figure 2 SSD 220 Figure 6 615.

[0072] exist Figures 9A to 11Some embodiments of the inventive concept are shown in the figure. However, those skilled in the art will recognize that other embodiments of the inventive concept are also possible by changing the order of the boxes, by omitting boxes, or by including links not shown in the figure. All such variations of the flowchart, whether explicitly described or not, are considered embodiments of the inventive concept.

[0073] Figure 12 The firmware stack of an example polymorphic SSD according to an embodiment of the inventive concept is shown. Here, the polymorphic SSD may be referred to as a polymorphic storage device (PSD).

[0074] The PSD firmware stack 1200 includes 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 (Apps) 1211a, 1211b, and 1211c. In this example, application 1211c represents the current tenant running on the PSD to distinguish itself from other applications 1211a and 1211b. In the following text, applications 1211a, 1211b, and 1211c may be collectively referred to as application 1211.

[0075] The firmware of this polymorphic storage device, which defines the behavior of the storage device, can be reconfigured via firmware updates. Through firmware updates, this polymorphic storage device can be transformed into a device of a different type from its original configuration. For example, this polymorphic storage device was originally configured as a general-purpose storage device. Through firmware updates, this polymorphic storage device can be transformed into a specialized device, such as an in-storage computing device, a near-storage computing device, a key-value store, a Hadoop Distributed File System (HDFS) device, an object storage device, and a smart solid-state drive (SSD) with intelligent computing capabilities. Applications running on such specialized devices or smart SSDs can have various application-specific characteristics, including but not limited to tagging characteristics (e.g., image tagging), compression characteristics (e.g., snappy, gzip, RLE), database characteristics (e.g., space compaction, predicate evaluation), pattern matching characteristics (e.g., string matching, virus scanning, regular expressions), machine learning characteristics (e.g., training and inference), and transformation characteristics (e.g., video transcoding, image sampling, document format conversion (e.g., PDF to Postscript)).

[0076] The flash controller layer 1235 includes a Virtual Flash Layer (VFL) 1230 and a Flash Interface Layer (FIL) 1240. The flash controller layer 1235 provides hardware support to enhance the 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 scalable hardware to provide an efficient interface to the flash memory. The flash controller layer 1235 can be updated via firmware updates to support the features of application 1211.

[0077] Packets (e.g., data, messages, and commands) received from the host are first sent to the PSD kernel 1255. The PSD kernel 1255's Context (CTX) manager 1256 and Message (MSG) router 1257 are responsible for routing the packets received from the host. The CTX manager 1256 is aware of one or more currently running tenant applications on the PSD and their characteristics. The CTX manager 1256 may include a table for tracking the application IDs of both currently running applications and configurations, as well as other existing applications and configurations. The CTX manager 1256 is also responsible for controlling the execution and activity (i.e., context control) of one or more currently running tenant applications, such as starting / stopping, resuming, and suspending. The PSD kernel 1255 can decapsulate and process the routed packets accordingly. For example, if a command to "create" application 1211 is received, the CTX manager 1256 can create an application context for application 1211 using data provided by the host. The data provided by the host may include a configuration profile or logic, the binary code of an application 1211 executable on the PSD, and metadata including the PSD library to allow the application 1211 to communicate with the PSD kernel 1255.

[0078] If a message received from the host relates to a registered application 1211 on the PSD, then if the context of the registered application 1211 is active, the PSD kernel 1255 can route the message and corresponding data and / or commands to the registered application 1211. If the context of the registered application 1211 is not active, the PSD kernel 1255 returns an error message to the host. If an unregistered or unrecognized message is received from the host, the PSD kernel 1255 can send other error messages to the host.

[0079] CTX manager 1256 is responsible for controlling application container 1210. CTX manager 1256 can create application contexts for application 1211 and distribute and manage the hardware resources of the PSD. CTX manager 1256 can be implemented in a fully virtualized manner (similar to a virtual machine (VM)) or in a para-virtualized manner. In one embodiment, application 1211 can run as ordinary firmware on a general-purpose storage device without implementing the PSD kernel 1255. In another embodiment, application 1211 can run as a new application specifically designed for the PSD, aware of the characteristics provided by the PSD.

[0080] Some applications in application 1211 may require specific wear leveling (WL) and / or garbage collection (GC) logic. This logic can be critical to the performance of the PSD. The PSD kernel 1255 provides a PSD library 1258, which includes application-specific WL / GC interfaces and general APIs that interface with the PSD kernel 1255. In the latter case, application 1211 can register those provided libraries instead of implementing its own WL / GC logic. In the former case, the PSD kernel 1255 provides full privileges to application 1211 in one or more layers of the PSD firmware stack 1200 without doing anything related to WL / GC.

[0081] Application 1211 can communicate with the underlying PSD kernel 1255 via PSD interface layer 1252. PSD interface layer 1252 provides communication APIs and data packets (e.g., messages, commands, and data) that pass through PSD interface layer 1252 to PSD.

[0082] Application 1211 can coexist on a single PSD as one or more application contexts. Application container 1210 can store the application context of application 1211, which can be active or idle. Application 1211 may include application logic, host protocol and message processor layers, application-specific address translation (ATL) logic, wear leveling (WL) logic, garbage collection (GC) logic, etc. In some embodiments, WL logic and GC logic are optional. For example, a key-value store application may have key-value structures and algorithms for the core logic. The host protocol and message processor layers may be as simple as wrappers for the functionality of the core logic. In one example, flash translation layer 430 may be specifically designed for application 145 running on hosts 110, 115, 120, 125, 130. For example, in the case of a key-value store application, application-specific ATL may be incorporated into an integrated FTL.

[0083] While additional logic is not mandatory on modern SSDs from a hardware perspective, the following factors can accelerate PSD execution. Examples of factors that can accelerate PSD execution include, but are not limited to: multiple Translation Lookaside Buffers (TLBs, also known as page table caches or address-bypass caches) or larger, caches with application container IDs, memory with more memory banks and / or more registers per dual in-line memory module (DIMM) to reduce conflicts, more flexible support for direct memory access (DMA), a higher number of unfinished DMAs, support for virtualization from embedded processors, application context-aware flash controllers, fine-grained power control with polymorphism awareness, hardware-assisted message routing, etc. In another example, PSDs may include Field Programmable Gate Arrays (FPGAs) to provide accelerated application-specific functionality. Applications (such as machine learning kernels, scientific computing in big data processing (such as neural networks, matrix manipulation, Fast Fourier Transform (FFT), pattern matching, etc.)) can be accelerated by running code on an FPGA instead of on a CPU in a general-purpose device. For applications such as machine learning kernels, tensor accelerators (such as tensor processor units (TPUs)) can be used to speed up matrix multiplication operations. For better space utilization and security, dedicated hardware (such as compressors and encryption engines) can also be used.

[0084] Application 1211, running on the PSD, supports various namespaces. In this example, application 1211a supports namespace NS 1, application 1211b supports namespaces NS 2 and NS 3, and application 1211c supports namespaces NS 1 and NS 4. Application 1211 can run in multiple namespaces, and some namespaces can be shared among multiple applications 1211.

[0085] According to one embodiment, the PSD kernel 1255 can receive host commands associated with a specific namespace via the PSD interface and can provide a flash interface based on namespaces associated with multiple data packets. A namespace is a logically managed unit and provides isolation from other namespaces in terms of interface, address space, data format, performance, and security. Namespaces can be created statistically or dynamically based on the capabilities of the PSD. The PSD kernel 1255 can configure the memory blocks of the PSD's non-volatile memory to associate them with namespaces and manage the mapping information between namespaces and allocated memory blocks.

[0086] If no namespace is specified, the operation is treated as a global namespace from the device to the PSD. A namespace can be associated with more than one application running in an application container, and an application can be associated with more than one namespace. In this example, multiple applications 1211 (e.g., NoSQL applications) run in the same namespace. Simultaneously, application 1211 can operate in two or more namespaces. In the case of a NoSQL application, one namespace can be assigned for the block interface, and another namespace can be assigned for the key-value interface. In this case, metadata can be stored in the key-value namespace, and data can be stored in the block namespace.

[0087] According to one embodiment, the storage device includes: an application container containing one or more applications, wherein each of the one or more applications runs in one or more namespaces; a polymorphic storage device (PSD) kernel implemented within the storage device and configured to: provide a host-side interface to a host and receive multiple data packets, including data, messages, and commands, from the host via the host-side interface, and route the multiple data packets to applications in the application container based on namespaces associated with the multiple data packets; and non-volatile memory. The PSD kernel is also configured to: provide a key-value interface and a block interface to the non-volatile memory based on namespaces associated with the multiple data packets. The non-volatile memory stores multiple block data accessible via the block interface and multiple key-value data accessible via the key-value interface.

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

[0089] One or more machines may include embedded controllers (such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, etc.). One or more machines may be connected to one or more remote machines via one or more connections (such as through a network interface, modem, or other communication link). Machines may be interconnected via physical and / or logical networks (such as intranets, the Internet, local area networks, wide area networks, etc.). Those skilled in the art will understand that network communications may utilize 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, etc. Optics, infrared, cables, lasers, etc.

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

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

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

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

[0094] Embodiments of the inventive concept can be extended to the following statements without limitation:

[0095] Statement 1: Embodiments of the inventive concept include a storage device (220), said storage device (220) comprising:

[0096] Storage memory (415) is used to store data;

[0097] A host interface (420) is used to manage communication between the storage device (220) and the host (110, 115, 120, 125, 130);

[0098] A translation layer (430) is used to translate a first address received from the host into a second address in the storage memory (415);

[0099] Storage interface (440) for accessing data from a second address in storage memory (415); and

[0100] An in-storage monitoring engine (425) is used to determine the characteristics (605, 610, 615) of the storage device (220), which are extracted from a set including the latency (605), bandwidth (610), and storage (615) of the storage device (220).

[0101] Statement 2. Embodiments of the inventive concept include the storage device (220) according to Statement 1, wherein:

[0102] The storage device (220) includes a solid-state drive (SSD) (220);

[0103] The storage memory (415) includes: flash memory (415) for storing data;

[0104] The translation layer (430) includes: a flash translation layer (FTL) (430) for translating a first address received from the host into a second address in flash memory (415);

[0105] The storage interface (440) includes a flash memory interface (440) for accessing data from a second address in the flash memory (415).

[0106] Statement 3. Embodiments of the inventive concept include the storage device (220) as described in Statement 1, and further include: a storage device controller (410) including a host interface (420), a storage interface (440) and an in-storage monitoring engine (425).

[0107] Statement 4. Embodiments of the inventive concept include the storage device (220) as described in Statement 1, and further include: a polymorphic device kernel, including an in-memory monitoring engine (425).

[0108] Statement 5. Embodiments of the inventive concept include the storage device (220) according to Statement 1, wherein the in-storage monitoring engine (425) operates to measure the characteristics (605, 610, 615) of the storage device (220) without the characteristics (605, 610, 615) being affected by the conversion layer (430).

[0109] Statement 6. An embodiment of the inventive concept includes a storage device (220) according to Statement 1, wherein an in-storage monitoring engine (425) operates to measure characteristics (605, 610, 615) of the storage device (220), including characteristics (605, 610, 615) affected by the conversion layer (430).

[0110] Statement 7. Embodiments of the inventive concept include the storage device (220) according to Statement 6, wherein the conversion layer (430) is dedicated to applications (145) on the host (110, 115, 120, 125, 130).

[0111] Statement 8. Embodiments of the inventive concept include a storage device (220) according to Statement 1, wherein an in-storage monitoring engine (425) is capable of measuring the characteristics (605, 610, 615) of the storage device (220) for specific types of profiling commands.

[0112] Statement 9. Embodiments of the inventive concept include the storage device (220) according to Statement 8, wherein a particular type of profiling command is specified by an application (145) on a host (110, 115, 120, 125, 130).

[0113] Statement 10. An embodiment of the inventive concept includes a storage device (220) according to Statement 1, wherein an in-storage monitoring engine (425) operates to measure characteristics (605, 610, 615) of the storage device (220) using a set of specific request sizes (720, 725).

[0114] Statement 11. Embodiments of the inventive concept include the storage device (220) as described in Statement 10, wherein a set of specific request sizes (720, 725) is specified by an application (145) on a host (110, 115, 120, 125, 130).

[0115] Statement 12. An embodiment of the inventive concept includes a storage device (220) according to Statement 1, wherein an in-storage monitoring engine (425) operates to periodically measure the characteristics (605, 610, 615) of the storage device (220).

[0116] Statement 13. An embodiment of the inventive concept includes a storage device (220) according to Statement 12, wherein an in-storage monitoring engine (425) operates to report changes in the characteristics (605, 610, 615) of the storage device (220) to a host (110, 115, 120, 125, 130).

[0117] Statement 14. Embodiments of the inventive concept include the storage device (220) according to Statement 1, wherein the in-storage monitoring engine (425) comprises:

[0118] A virtual storage table (825) for storing information about multiple virtual storage devices within the storage device (220); and

[0119] The profiling station (835) is used to manage multiple profiling commands for at least one of the plurality of virtual storage devices within the storage device (220).

[0120] Statement 15. An embodiment of the inventive concept includes a storage device (220) according to Statement 14, wherein at least one of the plurality of profiling commands includes a specific type of profiling command to execute the specific type of profiling command on at least one of the plurality of virtual storage devices within the storage device (220).

[0121] Statement 16. An embodiment of the inventive concept includes the storage device (220) according to Statement 14, wherein at least one of the plurality of profiling commands includes at least one request size (720, 725) to be used when executing the profiling command.

[0122] Statement 17. An embodiment of the inventive concept includes the storage device (220) according to Statement 14, wherein the in-storage monitoring engine (425) further includes: a parsing code register (820) for storing information about how to execute at least one of the plurality of parsing commands.

[0123] Statement 18. Embodiments of the inventive concept include the storage device (220) described in Statement 17, wherein the parsing code register (820) is user-configurable.

[0124] Statement 19. An embodiment of the inventive concept includes the storage device (220) as described in Statement 14, wherein the in-storage monitoring engine (425) further includes: a performance table (830) for storing information about previous profiling commands.

[0125] Statement 20: An embodiment of the inventive concept includes the storage device (220) according to Statement 19, wherein at least one of the plurality of profiling commands can satisfy information in the performance table (830).

[0126] Statement 21: An embodiment of the inventive concept includes the storage device (220) according to Statement 14, wherein at least one of the plurality of profiling commands may include a priority.

[0127] Statement 22: An embodiment of the inventive concept includes a method comprising:

[0128] The storage device (220) receives a profiling command (910) from the requester, the profiling command specifying the characteristics (605, 610, 615) of the storage device (220) to be determined;

[0129] The profiling command (935) is executed within the storage device (220) to produce results; and

[0130] The result (930) is returned from the storage device (220) to the requester.

[0131] Statement 23. Embodiments of the inventive concept include the method according to Statement 22, wherein:

[0132] The step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (910) from the requester in the solid-state drive (SSD) (220);

[0133] The step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the SSD (220) to produce results; and

[0134] The result (930) is returned from SSD (220) to the requester.

[0135] Statement 24. An embodiment of the inventive concept includes the method according to statement 22, wherein the step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (1005) from the application (145) in the storage device (220).

[0136] Statement 25. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (1010) from the host (110, 115, 120, 125, 130) in the storage device (220).

[0137] Statement 26. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of receiving the profiling command (910) from the requester by the storage device (220) includes: receiving the profiling command (910, 1020) from the requester by the storage device (220) without receiving any request size (720, 725) from the requester for executing the profiling command.

[0138] Statement 27. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce a result includes: executing the profiling command (935) against a virtual storage device within the storage device (220) to produce a result.

[0139] Statement 28. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce a result includes one of the following: determining the latency (605) of the storage device (220) as a result (1105), determining the bandwidth (610) of the storage device (220) as a result (1110), and determining the storage (615) of the storage device (220) as a result (1115).

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

[0141] The step of the storage device (220) receiving the profiling command (910) from the requester includes: receiving the profiling command (910, 1020) from the requester without receiving any request size (720, 725) for executing the profiling command from the requester; and

[0142] The step of determining the latency (605) of the storage device (220) as the result (1105) includes: determining the latency (605) of the storage device (220) as the result (1105) using the internally generated request size (720, 725).

[0143] Statement 30: Embodiments of the inventive concept include the method according to Statement 28, wherein:

[0144] The step of the storage device (220) receiving the profiling command (910) from the requester includes: the storage device (220) receiving the profiling command and multiple request sizes (720, 725) (910, 1015) from the requester; and

[0145] The step of determining the latency (605) of the storage device (220) as the result (1105) includes: determining the latency (605) of the storage device (220) as the result (1105) using the request size (720, 725).

[0146] Statement 31: Embodiments of the inventive concept include the method according to Statement 28, wherein:

[0147] The step of the storage device (220) receiving the profiling command (910) from the requester includes: receiving the profiling command (910, 1020) from the requester without receiving any request size (720, 725) for executing the profiling command from the requester; and

[0148] The step of determining the bandwidth (610) of the storage device (220) as a result (1105) includes: determining the bandwidth (610) of the storage device (220) as a result (1110) using an internally generated request size (720, 725).

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

[0150] The step of the storage device (220) receiving the profiling command (910) from the requester includes the storage device (220) receiving the profiling command and multiple request sizes (720, 725) (910, 1015) from the requester; and

[0151] The step of determining the bandwidth (610) of the storage device (220) as the result (1110) includes: determining the bandwidth (610) of the storage device (220) as the result (1110) using the request size (720, 725).

[0152] Statement 33. Embodiments of the inventive concept include the method according to statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes storing the results in a performance table (830) (940).

[0153] Statement 34. Embodiments of the inventive concept include the method described according to Statement 22, and further include:

[0154] The storage device (220) receives a second analysis command (910) from the second requester;

[0155] Check the performance table (830) to see if the results in the performance table (830) satisfy the second profiling command (920); and

[0156] If the result satisfies the second profiling command, the result in the performance table (830) is returned from the storage device (220) to the requester (925, 930).

[0157] Statement 35. Embodiments of the inventive concept include the method described according to Statement 22, further comprising: constructing a virtual storage table (825) (905), the virtual storage table (825) storing information about at least one virtual storage device within the storage device (220).

[0158] Statement 36. Embodiments of the inventive concept include the method according to Statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes:

[0159] The parsing command received from the requester is converted into an internal parsing command (915); and

[0160] Execute the internal profiling command (935) to produce results.

[0161] Statement 37. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the storage device (220) to measure the characteristics (605, 610, 615) of the storage device (220) without the characteristics (605, 610, 615) being affected by the conversion layer (430).

[0162] Statement 38. An embodiment of the inventive concept includes the method according to Statement 22, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the storage device (220) to measure characteristics (605, 610, 615) of the storage device (220), the characteristics (605, 610, 615) including characteristics (605, 610, 615) affected by the conversion layer (430).

[0163] Statement 39. Embodiments of the inventive concept include a product comprising a tangible storage medium having non-transitory instructions stored thereon, which, when executed by a machine (220), cause:

[0164] The storage device (220) receives a profiling command (910) from the requester, the profiling command specifying the characteristics (605, 610, 615) of the storage device (220) to be determined;

[0165] The profiling command (935) is executed within the storage device (220) to produce results; and

[0166] The result (930) is returned from the storage device (220) to the requester.

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

[0168] The step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (910) from the requester in the solid-state drive (SSD) (220);

[0169] The step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the SSD (220) to produce results; and

[0170] The step of returning a result (930) from the storage device (220) to the requester includes: returning a result (930) from the SSD (220) to the requester.

[0171] Statement 41. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (1005) from the application (145) in the storage device (220).

[0172] Statement 42. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of receiving the profiling command (910) from the requester in the storage device (220) includes: receiving the profiling command (1010) from the host (110, 115, 120, 125, 130) in the storage device (220).

[0173] Statement 43. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of receiving the profiling command (910) from the requester by the storage device (220) includes: receiving the profiling command (910, 1020) from the requester by the storage device (220) without receiving any request size (720, 725) from the requester for executing the profiling command.

[0174] Statement 44. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) for a virtual storage device within the storage device (220) to produce results.

[0175] Statement 45. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce a result includes one of the following: determining the latency (605) of the storage device (220) as a result (1105), determining the bandwidth (610) of the storage device (220) as a result (1110), and determining the storage (615) of the storage device (220) as a result (1115).

[0176] Statement 46. Embodiments of the inventive concept include the product described in Statement 45, wherein:

[0177] The step of the storage device (220) receiving the profiling command (910) from the requester includes: receiving the profiling command (910, 1020) from the requester without receiving any request size (720, 725) for executing the profiling command from the requester; and

[0178] The step of determining the latency (605) of the storage device (220) as the result (1105) includes: determining the latency (605) of the storage device (220) as the result (1105) using the internally generated request size (720, 725).

[0179] Statement 47. Embodiments of the inventive concept include the product described in Statement 45, wherein:

[0180] The step of the storage device (220) receiving the profiling command (910) from the requester includes: the storage device (220) receiving the profiling command and multiple request sizes (720, 725) (910, 1015) from the requester; and

[0181] The step of determining the latency (605) of the storage device (220) as the result (1105) includes: determining the latency (605) of the storage device (220) as the result (1105) using the request size (720, 725).

[0182] Statement 48. Embodiments of the inventive concept include the product described in Statement 45, wherein:

[0183] The step of the storage device (220) receiving the profiling command (910) from the requester includes: receiving the profiling command (910, 1020) from the requester without receiving any request size (720, 725) for executing the profiling command from the requester; and

[0184] The step of determining the bandwidth (610) of the storage device (220) as the result (1110) includes: determining the bandwidth (610) of the storage device (220) as the result (1110) using the internally generated request sizes (720, 725).

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

[0186] The step of the storage device (220) receiving the profiling command (910) from the requester includes: the storage device (220) receiving the profiling command and multiple request sizes (720, 725) (910, 1015) from the requester; and

[0187] The step of determining the bandwidth (610) of the storage device (220) as the result (1110) includes: determining the bandwidth (610) of the storage device (220) as the result (1110) using the request size (720, 725).

[0188] Statement 50. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes storing the results in a performance table (830) (940).

[0189] Statement 51: Embodiments of the inventive concept include the product according to Statement 39, wherein a tangible storage medium has additional non-transitory instructions stored thereon, which, when executed by a machine (220), cause:

[0190] The storage device (220) receives a second analysis command (910) from the second requester;

[0191] Check the performance table (830) to see if the results in the performance table (830) satisfy the second profiling command (920); and

[0192] If the result satisfies the second profiling command, the result in the performance table (830) is returned from the storage device (220) to the requester (925, 930).

[0193] Statement 52. Embodiments of the inventive concept include the product according to Statement 39, a tangible storage medium having additional non-transitory instructions stored thereon, which, when executed by a machine (220), cause: a virtual storage table (825) (905) to be constructed, the virtual storage table (825) storing information about at least one virtual storage device within the storage device (220).

[0194] Statement 53, embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes:

[0195] The parsing command received from the requester is converted into an internal parsing command (915); and

[0196] Execute the internal profiling command (935) to produce results.

[0197] Statement 54. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the storage device (220) to measure the characteristics (605, 610, 615) of the storage device (220) without the characteristics (605, 610, 615) being affected by the conversion layer (430).

[0198] Statement 55. Embodiments of the inventive concept include the product according to Statement 39, wherein the step of executing the profiling command (935) within the storage device (220) to produce results includes: executing the profiling command (935) within the storage device (220) to measure characteristics (605, 610, 615) of the storage device (220), the characteristics (605, 610, 615) including characteristics (605, 610, 615) affected by the conversion layer (430).

[0199] Therefore, given the extensive variety of substitutions for the embodiments described herein, this detailed description and the appended materials are intended to be illustrative only and should not be considered as limiting the scope of the inventive concept. Thus, the inventive concept claims protection for all such modifications that fall within the scope and spirit of the claims and their equivalents.

Claims

1. A storage device, comprising: An application container contains one or more applications, wherein each of the one or more applications runs in one or more namespaces; Flash memory is used to store data; A host interface is used to manage communication between the storage device and the host. A flash translation layer is used to translate a first address received from the host into a second address in the flash memory; Flash memory interface, used to access data from a second address in flash memory; A polymorphic device kernel is configured to: receive multiple data packets for an application running on the storage device, and route the multiple data packets to the application in the application container via a flash interface based on the namespace associated with the multiple data packets; and The in-storage monitoring engine determines the dynamic characteristics of the storage device at runtime, at least in part, based on the matching of profiling commands received from the host with performance tables. The polymorphic device kernel is further configured to provide a flash interface, including a key-value interface and a block interface, to the flash memory based on the namespace associated with the plurality of data packets, and One namespace is allocated for block interfaces, and the other namespace is allocated for key-value interfaces.

2. The storage device according to claim 1, wherein, The application runs in two or more namespaces.

3. The storage device according to claim 1, wherein, The namespace is shared by two or more applications.

4. The storage device according to claim 1, wherein, The storage device is capable of performing at least one of tag features, compression features, database features, pattern matching features, machine learning features, and transformation features.

5. The storage device according to claim 1, wherein, The in-storage monitoring engine executes profiling commands received from the requester on the storage device to determine the dynamic characteristics of the storage device at runtime. Return the result from the storage device to the requester; The storage device receives a second analysis command from the second requester; Determine whether the performance table includes results that satisfy the second profiling command; and Based at least in part on the performance table including the results of satisfying the second profiling command, the results of satisfying the second configuration command in the performance table are returned from the storage device to the second requester without executing the second profiling command.

6. The storage device according to claim 1, further comprising: Storage device controller, including host interface and flash memory interface.

7. The storage device according to claim 1, wherein, The flash translation layer is specifically designed for applications running on the host machine.

8. The storage device according to claim 1, wherein, The in-storage monitoring engine measures the dynamic characteristics of the storage device for specific types of profiling commands.

9. The storage device according to any one of claims 1 to 8, wherein, The in-storage monitoring engine includes: A virtual storage table is used to store information about multiple virtual storage devices within the storage device; and A profiling station is used to manage multiple profiling commands concerning at least one of the plurality of virtual storage devices within the storage device.

10. The storage device according to claim 9, wherein, The in-storage monitoring engine also includes a profiling code register for storing information about how to execute at least one of the plurality of profiling commands.

11. The storage device according to claim 9, wherein, The performance table stores information about previous profiling commands. The dynamic characteristics are extracted from a set including the storage device’s latency, bandwidth, storage, write amplification factor, transactions per second, and queuing latency.

12. A method for self-monitoring of storage device characteristics, comprising: One or more applications are stored in an application container on a storage device, wherein each of the one or more applications runs in one or more namespaces; Receive multiple data packets for the one or more applications from the host via the host interface; A polymorphic storage device kernel running on the storage device routes the plurality of data packets to applications in the application container via a flash interface based on namespaces associated with the plurality of data packets; and The in-storage monitoring engine is run to determine the dynamic characteristics of the storage device at runtime, based at least in part on the matching of profiling commands received from the host with performance tables. The polymorphic device kernel is configured to provide a flash interface, including a key-value interface and a block interface, to the flash memory based on the namespace associated with the plurality of data packets, and One namespace is allocated for block interfaces, and the other namespace is allocated for key-value interfaces.

13. The method according to claim 12, wherein, The application runs in two or more namespaces.

14. The method according to claim 12, wherein, The namespace is shared by two or more applications.

15. The method according to claim 12, wherein, The storage device is capable of performing at least one of tag features, compression features, database features, pattern matching features, machine learning features, and transformation features.

16. The method of claim 12, wherein: The storage device receives a first analysis command from the requester; The first profiling command is executed within the storage device to produce results; The result is returned from the storage device to the requester; The storage device receives a second analysis command from the second requester; Determine whether the performance table includes results that satisfy the second profiling command; and Based at least in part on the performance table including the results of satisfying the second profiling command, the results of satisfying the second profiling command in the performance table are returned from the storage device to the second requester without executing the second profiling command.

17. The method according to claim 12, wherein, The in-storage monitoring engine measures the dynamic characteristics of the storage device for specific types of profiling commands.

18. The method according to any one of claims 12 to 17, wherein, The in-storage monitoring engine includes: A virtual storage table is used to store information about multiple virtual storage devices within the storage device; and A profiling station is used to manage multiple profiling commands concerning at least one of the plurality of virtual storage devices within the storage device.

19. The method according to claim 18, wherein, The in-storage monitoring engine also includes a profiling code register for storing information about how to execute at least one of the plurality of profiling commands.

20. The method according to claim 18, wherein, The performance table stores information about previous profiling commands. The dynamic characteristics are extracted from a set including the storage device’s latency, bandwidth, storage, write amplification factor, transactions per second, and queuing latency.

Images