Programmable telemetry and alerts for storage devices

Abstract

A streaming data interface, or "telemetry tap", in conjunction with a host-defined telemetry program is used to adjust the type and amount of telemetry data sent to a host device. The amount of telemetry data provided to the host is based on the request. The controller will receive and execute valid host-generated programs defining which telemetry operations should occur and be forwarded to the host via a streaming telemetry mechanism. The controller will use a user / host programmable mechanism that will cooperate with an internal driver logging mechanism. The controller will monitor programmable mechanisms defined by the host and send a requested amount of telemetry data to the host once the programmable mechanisms have executed.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of the entire content of U.S. Non - Provisional Application No. 18 / 366,381, entitled "Programmable Telemetry and Alerts for Storage Devices", filed on August 7, 2023, with the United States Patent and Trademark Office, and is hereby incorporated by reference in its entirety for all purposes. Background Art Technical Field

[0003] Embodiments of the present disclosure generally relate to improving device telemetry for data collection.

[0004] Description of Related Technologies

[0005] Current storage device telemetry data collection is either too coarse or too cumbersome for customers to use for online data collection. This results in either no telemetry collection, which makes it difficult to debug and / or predict drive failures, or too much data, where customers cannot reduce the collected data to actionable information.

[0006] SMART data collection is the most common form of online storage device log collection, but its drawbacks are also well - documented. Other methods involve extracting internal proprietary format drive logs as a post - mortem debugging activity to determine the cause of storage device failures. When applied to online drive health monitoring, these other methods can be classified as "too little" and "too late".

[0007] Storage devices such as hard disk drives (HDDs) and solid - state drives (SSDs) provide limited options for exposing telemetry to the host system. The data is either presented in the traditional SMART log format, which is often inaccurate / incomplete, or as a proprietary binary file, which is often too large to extract continuously. Due to lightweight operation, the host and the drive preferably use SMART to extract drive log telemetry, but SMART is useless in many cases. Vendor - specific internal log extraction is a heavy operation that affects device and host performance. If a user wants to use a vendor - specific internal log extraction mechanism, other operations must be suspended. Once the operations are suspended, the user will obtain a large amount of data that may or may not be useful. Using vendor - specific internal log extraction has an impact on the user workload, and there is no middle ground for the amount of data received.

[0008] Accordingly, there is a need in the art to improve device data collection through telemetry of a streaming data telemetry interface such as a data tap. Summary of the Invention

[0009] A streaming data interface or "telemetry tap" in combination with a host-defined telemetry program is used to regulate the type and amount of telemetry data sent to the host device. The amount of telemetry data provided to the host is based on a request. The controller will receive and execute valid host-generated programs that define which telemetry operations should occur and forward them to the host via the streaming telemetry mechanism. The controller will use a user / host programmable mechanism that will cooperate with the internal drive logging mechanism. The controller will monitor the host-defined programmable mechanisms and, once these programmable mechanisms have been executed, send the requested amount of telemetry data to the host.

[0010] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: collect telemetry data of the data storage device; determine an amount of telemetry data to be provided to a host device, wherein the amount of data is generally less than all of the collected telemetry data, and wherein the amount of data is predetermined telemetry data; and provide the predetermined telemetry data to the host device.

[0011] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive an indication from a host device for providing telemetry data to the host device in-band or out-of-band; collect telemetry data of the data storage device; and stream at least some of the collected telemetry data to the host device.

[0012] In another embodiment, a data storage device includes: means for storing data; and a controller coupled to the means for storing data, wherein the controller is configured to: collect telemetry data of the data storage device; and send less than all of the telemetry data to a host device, wherein the sending is based on a host device command for sending less than all of the telemetry data, wherein the sending of less data is a function of logical execution by the controller, and wherein the logical execution is predetermined based on telemetry instructions provided by the host device. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To understand the above-described features of the present disclosure in detail, the present disclosure briefly summarized above may be described in more detail by referring to the embodiments, some of which are illustrated in the drawings. However, it should be noted that the drawings only illustrate typical embodiments of the present disclosure and should not be considered as limiting the scope of the present disclosure, as the present disclosure may permit other equivalent embodiments.

[0014] Figure 1is a schematic block diagram showing a storage system in which a data storage device can be used as a storage device of a host device according to some embodiments.

[0015] Figure 2 is a schematic diagram of a magnetic recording device according to one embodiment.

[0016] Figure 3 is a block diagram showing a system with telemetry according to one embodiment.

[0017] Figure 4 is a block diagram showing a storage system with a telemetry tap function according to one embodiment.

[0018] Figure 5 is a block diagram showing a storage system for listening to telemetry data taps on an SSD according to some embodiments.

[0019] Figure 6 is a block diagram showing a storage system for refined telemetry data taps on an SSD according to some embodiments.

[0020] Figure 7 is a block diagram showing a storage system for transporting telemetry data taps on an SSD according to some embodiments.

[0021] Figure 8 is a flowchart showing a method for utilizing telemetry data taps according to some embodiments.

[0022] For ease of understanding, wherever possible, the same reference numerals are used to denote the same elements common to the drawings. It is contemplated that elements disclosed in one embodiment may be beneficially utilized in other embodiments without specific recitation. Detailed Description

[0023] Hereinafter, embodiments of the present disclosure are referred to. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the following features and elements, whether or not they relate to different embodiments, is contemplated for implementing and practicing the present disclosure. Moreover, although embodiments of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the present disclosure. Thus, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited therein. Similarly, references to "the present disclosure" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered an element or limitation of the appended claims unless expressly recited therein.

[0024] A streaming data interface or "telemetry tap" combined with a host-defined telemetry program is used to regulate the type and amount of telemetry data sent to the host device. The amount of telemetry data provided to the host is based on requests. The controller will receive and execute valid host-generated programs that define which telemetry operations should occur and forward them to the host via the streaming telemetry mechanism. The controller will use a user / host programmable mechanism that will cooperate with the internal drive logging mechanism. The controller will monitor the host-defined programmable mechanisms and, once these programmable mechanisms have been executed, send the requested amount of telemetry data to the host.

[0025] Apparatus for programmable data telemetry creates a mechanism that can address the lack or overflow of collected drive log data, thereby customizing data collection to only the meaningful information for managing a storage device group.

[0026] Figure 1 FIG. is a schematic block diagram of a storage system 100 having a data storage device 106 that can be used as a host device 104 according to certain embodiments. For example, the host device 104 can utilize non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes host dynamic random access memory (DRAM) 138. In some examples, the storage system 100 can include multiple storage devices that can operate as a storage array, such as the data storage device 106. For example, the storage system 100 can include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID) that together serve as a mass storage device for the host device 104.

[0027] The host device 104 can store data to and / or retrieve data from one or more storage devices such as the data storage device 106. As Figure 1 shown, the host device 104 can communicate with the data storage device 106 via an interface 114. The host device 104 can include any of a wide range of devices, including: computer servers, network-attached storage (NAS) units, desktop computers, notebooks (i.e., laptop) computers, tablets, set-top boxes, telephone handsets (such as so-called "smart" phones, so-called "smart" tablets), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending or receiving data from a data storage device.

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

[0029] The data storage device 106 includes a controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, write buffer 116, and optional DRAM 118. In some examples, the data storage device 106 may include additional components, which are not shown for clarity in Figure 1 Additional components are shown. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed circuit board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some example standard form factors include, but are not limited to, 3.5-inch data storage devices (e.g., HDD or SSD), 2.5-inch data storage devices, 1.8-inch data storage devices, Peripheral Component Interconnect (PCI), Extended PCI (PCI-X), Express PCI (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe mini card, mini PCI, etc.). In some examples, the data storage device 106 may be directly coupled (e.g., directly soldered or inserted into a connector) to the motherboard of the host device 104.

[0030] Interface 114 may include one or both of a data bus for exchanging data with host device 104 and a control bus for exchanging commands with host device 104. Interface 114 may operate according to any suitable protocol. For example, interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface eXtensions (CCIX), Open Channel Solid State Drive (OCSSD), etc. Interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to controller 108, providing an electrical connection between host device 104 and controller 108, enabling data to be exchanged between host device 104 and controller 108. In some examples, the electrical connection of interface 114 may also allow data storage device 106 to receive power from host device 104. For example, as Figure 1 shown, power supply 111 may receive power from host device 104 via interface 114.

[0031] NVM 110 may include multiple memory devices or memory cells. NVM 110 may be configured to store and / or retrieve data. For example, the memory cells of NVM 110 may receive data and a message indicating that the memory cell stores the data from controller 108. Similarly, the memory cell may receive a message from controller 108 indicating that the memory cell retrieves data. In some examples, each memory cell in the memory cells may be referred to as a die. In some examples, NVM 110 may include multiple dice (i.e., multiple memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).

[0032] In some examples, each memory cell may include any type of non-volatile memory device such as: flash memory device, phase change memory (PCM) device, resistive random access memory (ReRAM) device, magnetoresistive random access memory (MRAM) device, ferroelectric random access memory (F-RAM), holographic memory device, and any other type of non-volatile memory device.

[0033] The NVM 110 may include multiple flash memory devices or memory cells. The NVM flash memory devices may include NAND or NOR-based flash memory devices and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In the NVM flash memory devices, the flash memory devices may be partitioned into multiple dies, where each of the multiple dies includes multiple physical blocks or logical blocks, and the multiple physical blocks or logical blocks may be further partitioned into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of the NVM cells may be electrically connected using word lines to define the pages within the multiple pages. The corresponding cells within each of the multiple pages may be electrically connected to corresponding bit lines. Additionally, the NVM flash memory devices may be 2D or 3D devices and may be single-level cells (SLCs), multi-level cells (MLCs), triple-level cells (TLCs), or quad-level cells (QLCs). The controller 108 may write data to and read data from the NVM flash memory devices at the page level and erase data from the NVM flash memory devices at the block level.

[0034] The power supply 111 may supply power to one or more components of the data storage device 106. When operating in the standard mode, the power supply 111 may use the power provided by an external device such as the host device 104 to supply power to one or more components. For example, the power supply 111 may use the power received from the host device 104 via the interface 114 to supply power to one or more components. In some examples, the power supply 111 may include one or more power storage components configured to supply power to one or more components when operating in the off mode, such as in the case of stopping receiving power from an external device. In this way, the power supply 111 may be used as an on-vehicle backup power source. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of electric power that may be stored by the one or more power storage components may be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of electric power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0035] The controller 108 may use the volatile memory 112 to store information. The volatile memory 112 may include one or more volatile memory devices. In some examples, the controller 108 may use the volatile memory 112 as a cache. For example, the controller 108 may store the information in the cache in the volatile memory 112 before the information in the cache is written to the NVM 110. As Figure 1As shown, the volatile memory 112 may consume power received from the power supply 111. Examples of the volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)). Similarly, the optional DRAM 118 may be used to store mapped data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, etc. in the optional DRAM 118. In some examples, the data storage device 106 does not include the optional DRAM 118, such that the data storage device 106 is DRAM-less. In other examples, the data storage device 106 includes the optional DRAM 118.

[0036] The controller 108 may manage one or more operations of the data storage device 106. For example, the controller 108 may manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 may initiate a data storage command to store the data in the NVM 110 and monitor the progress of the data storage command. The controller 108 may determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data in an internal memory or write buffer 116 before sending the data associated with the write command to the NVM 110.

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

[0038] Figure 2FIG. 200 is a schematic diagram of a magnetic recording device 200 according to one embodiment. The magnetic recording device 200 includes a magnetic recording head, such as a write head. The magnetic recording device 200 is a magnetic medium drive that communicates with a host device 250, such as a hard disk drive (HDD). Such magnetic medium drives can be a single drive / device or include multiple drives / devices. For ease of illustration, in the Figure 2 illustrated embodiment, a single disk drive is shown as the magnetic recording device 200. The magnetic recording device 200 (e.g., disk drive) includes at least one rotatable disk 212 that is supported on a spindle 214 and rotated by a drive motor 218. The magnetic recording on each rotatable disk 212 is in the form of any suitable data track pattern, such as an annular pattern of concentric data tracks on the rotatable disk 212.

[0039] At least one slider 213 is positioned near the rotatable disk 212. Each slider 213 supports a head assembly 221. The head assembly 221 includes one or more magnetic recording heads (such as read / write heads), such as a write head that includes a spintronic device. As the rotatable disk 212 rotates, the slider 213 moves radially in and out over the disk surface 222 so that the head assembly 221 can access different tracks of the rotatable disk 212 for writing desired data. Each slider 213 is attached to an actuator arm 219 by a suspension 215. The suspension 215 provides a slight spring force that biases the slider 213 toward the disk surface 222. Each actuator arm 219 is attached to an actuator 227. As Figure 2 illustrated, the actuator 227 can be a voice coil motor (VCM). The VCM includes a coil that can move within a fixed magnetic field, and the direction and speed of the coil movement are controlled by a motor current signal provided by a control unit 229.

[0040] The head assembly 221 (such as the write head of the head assembly 221) includes a medium facing surface (MFS), such as an air bearing surface (ABS) facing the disk surface 222. During operation of the magnetic recording device 200, the rotation of the rotatable disk 212 generates an air or gas bearing between the slider 213 and the disk surface 222, and the air or gas bearing exerts an upward force or lift on the slider 213. Thus, the air or gas bearing counteracts the slight spring force of the suspension 215 and supports the slider 213 off the disk surface 222 and slightly above the disk surface at a small, substantially constant interval during operation.

[0041] The various components of the magnetic recording device 200 are controlled in operation by control signals generated by the control unit 229, such as access control signals and internal clock signals. The control unit 229 includes a logic control circuit, a storage device, and a microprocessor. The control unit 229 generates control signals to control various system operations, such as the drive motor control signal on line 223 and the head positioning and seek control signal on line 228. The control signal on line 228 provides a desired current distribution to optimally move and position the slider 213 to a desired data track on the rotatable disk 212. Write and read signals are communicated to and from the head assembly 221 through the recording channel 225. In one embodiment that can be combined with other embodiments, the magnetic recording device 200 may also include multiple media or disks, multiple actuators, and / or multiple sliders.

[0042] Figure 3 FIG. is a block diagram showing a system 300 with telemetry according to one embodiment. The system 300 includes a host operating system (OS) 302, a first storage device 304, and multiple other storage devices 306. The host OS 302 includes a user-defined telemetry hook. The user-defined telemetry hook communicates with both the multiple storage devices 306 and the first storage device 304. The first storage device 304 and the multiple storage devices 306 each include a user-defined telemetry program and a device log.

[0043] Figure 4 FIG. is a block diagram showing a storage system 400 with a telemetry tap function according to one embodiment. The storage system 400 includes a host 402 and a storage device 404. The storage device 404 includes a runtime environment 406 on the device, a device log 408, and storage device events 410. The runtime environment 406 on the device includes a telemetry program. The storage device events 410 include a logging process. The telemetry program will communicate with the logging process to condition any requests received from the host to determine how to condition the telemetry tap function.

[0044] Figure 5 FIG. is a block diagram showing a storage system 500 for listening to telemetry data taps in an SSD according to certain embodiments. When listening to a telemetry tap, the user sends a host-defined executable command to the drive to enable streaming of telemetry data from the drive through an in-band or out-of-band mechanism. The linux kernel driver creates a character device for streaming the inbound telemetry data to. The host application then opens and streams data from the interface for analysis. Streaming all available telemetry data from the device when telemetry is generated is a powerful and low-disruptive mechanism for debugging the behavior of one or more drives in a storage system.

[0045] The storage system 500 includes a host 502 and a storage device 504. The host 502 is configured to enable a user to compile telemetry that can be executed against the SSD / storage device 504. The kernel forwards the user telemetry program to the storage device 504 via NVMe and enables any streaming interface endpoints required by the host 502. Some host processes listen for drive telemetry on the data tap interface.

[0046] The storage device 504 includes a created NVMe interface (in-band or out-of-band). The NVMe interface is configured to implement a telemetry data stream to storage device events such as Figure 4 storage device event 410). The storage device events include a logging process configured to drive events to the NVMe interface. The NVMe interface is further configured to pass the telemetry to the host 502.

[0047] Figure 6 is a block diagram showing a storage system 600 for refined telemetry data tapping in an SSD according to certain embodiments. For refined telemetry tapping, a user will send an NVMe payload consisting of a host-defined telemetry program with host-defined instructions to the drive to enable streaming of certain telemetry data from the drive via an in-band or out-of-band mechanism. The linux kernel driver creates a device for streaming the inbound telemetry data to. The host application then opens and streams data from the interface for analysis. Filtering the streamed telemetry data allows for curating the telemetry for continuous monitoring of the health of a large-scale population. Filtering also allows the user to understand which telemetry metrics are important to capture in their specific environment.

[0048] The storage system 600 includes a host 602 and a storage device 604. The host 602 is configured to enable a user to compile telemetry that can be executed against the SSD / storage device 604. The kernel forwards the user telemetry program to the storage device 604 via NVMe and enables any streaming interface endpoints required by the host 602. Some host processes listen for drive telemetry on the data tap interface.

[0049] The storage device 604 includes a created NVMe interface (in-band or out-of-band). The NVMe interface is configured to implement a telemetry data stream to storage device events such as Figure 4 storage device event 410). The NVMe interface is configured to pass a filtering program or pass instructions for filtering. The storage device events include a logging process configured to drive events to filter the log based on host telemetry program instructions. The filtered log (telemetry) is then sent to the NVMe interface, which is further configured to pass the telemetry to the host 602.

[0050] Figure 7FIG. 0 is a block diagram showing a storage system 700 for delivering a telemetry program to an SSD according to some embodiments. When delivering a telemetry program in the storage system 700, a user constructs an eBPF class program in the user space of the host 702, sends it to the storage device, enables host telemetry data tapping, and runs the program. For example, the program can track the value of the drive log counter x and issue an alert to the host if the value becomes greater than y. The eBPF class program code passes through a code validator and a compiler. If the validation fails in the compiler, the code needs to be refactored. Once the validation passes, the linux kernel hooks into the NVMe driver. The linux kernel then obtains the compiled telemetry program and transfers the program to the storage device 704 via mechanisms. These mechanisms can be, but are not limited to, a streaming device-to-host data interface where the host can listen for and capture device-side telemetry when generating the program; a mechanism for running a device-side user-defined program that allows pre-computation of device-side telemetry (e.g., aggregation of events) and streaming the results of the computation through the device-to-host data interface; and a mechanism for refining which device-side telemetry events are forwarded to the device-side user-defined program and which are forwarded to the streaming device-to-host data interface.

[0051] The telemetry program is deployed into a small compute / memory area in the storage device 704 that can interpret eBPF class VM bytecode. The program issues alerts to the NVMe device logs, including the logging process and the logs. The alerts are the counter categories that the telemetry program is interested in. The logs are then sent to the runtime environment on the device. The internal logging mechanism of the storage device collects the telemetry that is of interest to the eBPF VM class application to increment the internal count when a user-defined event occurs.

[0052] Figure 8 FIG. 7 is a flowchart showing a method 800 for utilizing telemetry data tapping according to some embodiments. Method 800 begins at block 802. At block 802, telemetry tapping is set up. At block 804, the controller determines whether the data tapping is crawling, walking, or running. If the controller determines that the data tapping is crawling, method 800 proceeds to block 806. At block 806, the controller collects telemetry data. At block 808, the controller streams all the telemetry data. When block 808 is completed, method 800 returns to block 806 to continue collecting telemetry data.

[0053] If the controller determines that the data tapping is walking, method 800 proceeds to block 810. At block 810, the controller collects telemetry data. At block 812, the controller filters the telemetry data to only the requested telemetry data. At block 814, the controller streams the requested telemetry data. Then, the method continues by continuing to collect telemetry data at block 810.

[0054] If the controller determines that the data tap is a run, method 800 proceeds to block 816. At block 816, the controller collects telemetry data. At block 818, the controller determines whether there is any telemetry data to be filtered. If the controller determines that there is telemetry data to be filtered, method 800 proceeds to block 820. At block 820, the controller filters the telemetry data to only the requested telemetry data. At block 822, the controller determines whether the filtered telemetry data is above a predetermined threshold. If the controller determines that the filtered telemetry data is not above a predetermined threshold, method 800 returns to block 816. If the controller determines that the filtered telemetry data is above a predetermined threshold, method 800 proceeds to block 826.

[0055] If the controller determines that there is no telemetry data to be filtered, method 800 proceeds to block 824. At block 824, the controller determines whether this is any telemetry data above a predetermined threshold. If the controller determines that the telemetry data is not above a predetermined threshold, method 800 returns to block 816. If the controller determines that the filtered telemetry data is above a predetermined threshold, method 800 proceeds to block 826.

[0056] At block 826, the controller determines whether to stream or ping. If the controller determines to stream, method 800 proceeds to block 828. At block 828, the controller streams the telemetry data above a predetermined threshold. If the controller determines to ping, method 800 proceeds to block 830. At block 830, the controller pings the host device to notify of a telemetry issue. At block 832, the controller receives a request for the telemetry data from the host and provides the requested telemetry data to the host.

[0057] Much of the telemetry collected by the storage device is not currently exposed to the host unless large proprietary binary logs are extracted and pulled. The effort to do this is significant and impacts the quality of service (QoS) of the user's internal operation (IO) workload. Once pulled, the logs must be parsed and cleaned for what may be a small amount of useful data. Reducing the difficulty and amount of the collected drive telemetry data for storage device monitoring greatly increases the likelihood that customers will use these now more accessible metrics for device monitoring.

[0058] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: collect telemetry data of the data storage device; determine an amount of telemetry data to be provided to a host device, wherein the amount of data is typically less than all of the collected telemetry data, and wherein the amount of data is predetermined telemetry data; and provide the predetermined telemetry data to the host device. The memory device is a hard disk drive. The memory device is a solid state drive (SSD). The determination includes receiving an indication from the host device of specific telemetry data that the host device should receive. The determination includes receiving an indication from the host device of a threshold that the telemetry data is to exceed prior to providing the predetermined telemetry data to the host device. The threshold is for typically less than all of the telemetry data. The controller is configured to determine whether any of the thresholds has been exceeded. Providing the predetermined telemetry data to the host device includes streaming the predetermined telemetry data. The controller is configured to receive a command from the host device to enable in-band or out-of-band streaming. Providing the predetermined telemetry data to the host device includes: interrogating the host device; receiving a request for the predetermined telemetry data from the host device; and transmitting the predetermined telemetry data in response to receiving the request.

[0059] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive an indication from the host device for providing telemetry data to the host device in-band or out-of-band; collect telemetry data of the data storage device; and stream at least some of the collected telemetry data to the host device. The controller is configured to stream at least some of the telemetry data to a host device interface. At least some of the telemetry data is less than all of the telemetry data. The controller is configured to receive an instruction from the host device that identifies less than all of the telemetry data to be streamed. The controller is configured to receive an instruction from the host device. The telemetry data includes monitoring information of the health of the data storage device. The controller is configured to maintain a filter log of the telemetry data.

[0060] In another embodiment, a data storage device includes: means for storing data; and a controller coupled to the means for storing data, wherein the controller is configured to: collect telemetry data of the data storage device; and transmit less than all of the telemetry data to a host device, wherein the transmission is based on a host device command for transmitting less than all of the telemetry data. The transmission occurs after interrogating the host device and receiving a command for transmitting less than all of the telemetry data. Less than all of the telemetry data is based on exceeding a predetermined threshold.

[0061] While the foregoing is directed to embodiments of the present disclosure, other and additional embodiments of the present disclosure may be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A data storage device, the data storage device comprising: A memory device; And A controller coupled to the memory device, wherein the controller is configured to: Collect telemetry data of the data storage device; Determine an amount of telemetry data to be provided to a host device, wherein the amount of data is generally less than all of the collected telemetry data, and wherein the amount of data is predetermined telemetry data; And Provide the predetermined telemetry data to the host device.

2. The data storage device according to claim 1, wherein the memory device is a hard disk drive.

3. The data storage device according to claim 1, wherein the memory device is a solid state drive (SSD).

4. The data storage device according to claim 1, wherein the determining includes receiving an indication from the host device of specific telemetry data that the host device should receive.

5. The data storage device according to claim 1, wherein the determining includes receiving an indication from the host device of a threshold that the telemetry data is to exceed before providing the predetermined telemetry data to the host device.

6. The data storage device according to claim 5, wherein the threshold is for generally less than all of the telemetry data.

7. The data storage device according to claim 5, wherein the controller is configured to determine whether any of the thresholds have been exceeded.

8. The data storage device according to claim 1, wherein providing the predetermined telemetry data to the host device includes streaming the predetermined telemetry data.

9. The data storage device according to claim 8, wherein the controller is configured to receive a command from the host device to enable in-band or out-of-band streaming.

10. The data storage device according to claim 1, wherein providing the predetermined telemetry data to the host device includes: Probing the host device; Receiving a request for the predetermined telemetry data from the host device; And Sending the predetermined telemetry data in response to receiving the request.

11. A data storage device, the data storage device comprising: A memory device; And A controller coupled to the memory device, wherein the controller is configured to: Receive an indication from a host device for providing telemetry data to the host device in-band or out-of-band; Collect the telemetry data of the data storage device; And Stream at least some of the collected telemetry data to the host device.

12. The data storage device according to claim 11, wherein the controller is configured to stream the at least some telemetry data to a host device interface.

13. The data storage device according to claim 12, wherein the at least some telemetry data is less than all of the telemetry data.

14. The data storage device according to claim 13, wherein the controller is configured to receive an instruction from the host device that identifies the less than all telemetry data to be streamed.

15. The data storage device according to claim 11, wherein the controller is configured to receive instructions from the host device.

16. The data storage device according to claim 11, wherein the telemetry data includes monitoring information of the health status of the data storage device.

17. The data storage device according to claim 11, wherein the controller is configured to maintain a filter log of the telemetry data.

18. A data storage device, the data storage device comprising: means for storing data; and a controller, the controller being coupled to the means for storing data, wherein the controller is configured to: collect telemetry data of the data storage device; and send less than all of the telemetry data to a host device, wherein the sending is based on a host device command for sending less than all of the telemetry data.

19. The data storage device according to claim 18, wherein the sending occurs after the host device is inspected and a command for sending the less than all of the telemetry data is received.

20. The data storage device according to claim 18, wherein the less than all of the telemetry data is based on exceeding a predetermined threshold.

Images