Selective panic mitigation

Abstract

The invention relates to selective panic mitigation. Not all panic situations in the data storage device require the host device to initiate a reset. Efficiency is achieved when the data storage device is likely to handle a panic event and simply notifies the host device that the panic event is avoided. For a multi-tenant situation, the data storage device may trace the type of trace and determine whether a reset initiated by the host device is necessary or whether the data storage device may internally process the reset. The data storage device may delay a host device initiated reset required by a tenant until other tenants are ready to perform the host device initiated reset.

Description

Background Technology Technical Field

[0001] The implementation plan disclosed herein generally addresses panic mitigation.

[0002] Related technical descriptions

[0003] The Fast Peripheral Component Interconnect (PCIe) standard introduced Single Root Input / Output (I / O) Virtualization (SR-IOV), which includes Physical Functions (PF) and Virtual Functions (VF). PF is a full-featured PCIe function. VF is a lightweight function lacking some configuration resources.

[0004] A multi-tenant environment typically means the presence of some type of virtualization implemented in the device controller, such as one or more Virtual Functions (VFs), one or more Virtual Powers (PFs), or a combination thereof. Most specifically, a multi-tenant environment involves a variety of functionalities.

[0005] When a data storage device encounters an internal failure, it has several recovery paths. Some failures can be handled within the data storage device, while others involve resetting the host interface or otherwise disrupting host-device communication. Events involving host-device interaction are called panic events. Mechanisms exist in Fast Non-Volatile Memory (NVM) (NVMe) and Open Compute Project (OCP) standards to resolve panic events while minimizing the impact on end users.

[0006] Whether operating in a client or enterprise solid-state drive (SSD) environment, reducing the frequency of panic events is valuable in preventing host interface damage under any possible circumstances.

[0007] Therefore, there is a need in this field to mitigate panic events. Summary of the Invention

[0008] Not all panic events in a data storage device require a host device-initiated reset. Efficiency is achieved when the data storage device can handle the panic event and simply notify the host device that the panic event has been averted. In multi-tenant scenarios, the data storage device can track the type of trace and determine whether a host device-initiated reset is necessary or whether the data storage device can handle the reset internally. The data storage device can delay a host device-initiated reset required by one tenant until other tenants are ready to perform the host device-initiated reset.

[0009] 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: track indications of resets of one or more physical functions (PF), one or more virtual functions (VF), or a combination of PF and VF; determine whether a reset is to occur; determine whether the workload is a read workload; and determine whether to process the reset internally or transfer it to the host device to initiate a reset.

[0010] In another embodiment, a data storage device includes: a memory device; a controller coupled to the memory device, wherein the controller is configured to: operate as a multitenant device coupled to one or more physical functions (PF), one or more virtual functions (VF), or a combination of PF and VF; trace the traces of each of the one or more PF, the one or more VF, or the combination of PF and VF; determine whether the traces are for a read workload; and store an indication of whether the workload is a read workload.

[0011] In another embodiment, a data storage device includes: means for storing data; a controller coupled to the means for storing data, wherein the controller is configured to: determine that a near-failure event has occurred; determine that the near-failure event can be handled without a host device reset; initiate host device isolation; handle a state reset; restore the system state from a state recovery database; and remove host device isolation. Attached Figure Description

[0012] To gain a more detailed understanding of the features described above, the present disclosure can be described in more specific terms by referring to embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only typical embodiments of the present disclosure and should not be construed as limiting the scope of the disclosure, as other equivalent embodiments are permissible.

[0013] Figure 1 This is a schematic block diagram illustrating a storage system according to certain implementation schemes, in which the data storage device can be used as a storage device for the host device.

[0014] Figure 2 It is a block diagram depicting the standard for introducing single-root input / output (I / O) virtualization (SR-IOV) systems.

[0015] Figure 3 This is a schematic diagram for internal reset of a single-port memory device.

[0016] Figure 4 This is a flowchart illustrating the handling of failure events according to one implementation scheme.

[0017] Figure 5 This is a flowchart illustrating the status recording module and database operations according to an implementation scheme.

[0018] Figure 6 This is a flowchart illustrating the mitigation of panic events in a multi-tenant system.

[0019] Figure 7 This is a flowchart illustrating selective reset preparation for a multi-tenant system.

[0020] Figure 8 This is a schematic diagram of a storage system with resources for mitigating panic events.

[0021] For ease of understanding, the same reference numerals are used to denote the same elements used in the accompanying drawings, where possible. Elements disclosed in one embodiment are intended to be usefully used in other embodiments without being specifically listed. Detailed Implementation

[0022] In the following text, reference is made to embodiments of this disclosure. However, it should be understood that this disclosure is not limited to the specifically described embodiments. Rather, any combination of the following features and elements (whether or not different embodiments are involved) is contemplated to realize and practice this disclosure. Furthermore, while embodiments of this 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 this disclosure. Therefore, the following aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims. Similarly, reference to “this disclosure” should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0023] Not all panic events in a data storage device require a host device-initiated reset. Efficiency is achieved when the data storage device can handle the panic event and simply notify the host device that the panic event has been averted. In multi-tenant scenarios, the data storage device can track the type of trace and determine whether a host device-initiated reset is necessary or whether the data storage device can handle the reset internally. The data storage device can delay a host device-initiated reset required by one tenant until other tenants are ready to perform the host device-initiated reset.

[0024] Figure 1This is a schematic block diagram illustrating a storage system 100 having a data storage device 106 that can be used as a storage device for a host device 104, according to some embodiments. For example, the host device 104 may 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 may include multiple storage devices, such as the data storage device 106, which may operate as a storage array. For example, the storage system 100 may include multiple data storage devices 106 configured as a redundant array of inexpensive / disk-only (RAID) that collectively act as a mass storage device for the host device 104.

[0025] Host device 104 can store data to and / or retrieve data from one or more storage devices (such as data storage device 106). Figure 1 As illustrated, host device 104 can communicate with data storage device 106 via interface 114. Host device 104 may include any of a wide range of devices, including computer servers, network attached storage (NAS) units, desktop computers, notebook computers, tablet computers, set-top boxes, handsets (such as so-called "smart" phones), so-called "smart" boards, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending data to or receiving data from data storage devices.

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

[0027] Data storage device 106 includes a controller 108, an NVM 110, a power source 111, volatile memory 112, an interface 114, a write buffer 116, and optional DRAM 118. In some examples, data storage device 106 may include components not shown for clarity. Figure 1 Additional components are shown in the diagram. For example, data storage device 106 may include a printed circuit board (PCB) to which components of data storage device 106 are mechanically attached, and the PCB includes conductive traces for electrically interconnecting components of data storage device 106, etc. In some examples, the physical dimensions and connector configuration of 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" data storage devices (e.g., HDDs or SSDs), 2.5" data storage devices, 1.8" data storage devices, peripheral component interconnect (PCI), PCI expansion (PCI-X), and fast PCI (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe mini-cards, mini PCI, etc.). In some examples, data storage device 106 may be directly coupled (e.g., directly soldered or inserted into a connector) to the motherboard of host device 104.

[0028] 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, High Speed ​​Non-Volatile Memory (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. Interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to controller 108, thereby providing an electrical connection between host device 104 and controller 108 to allow data exchange 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 As illustrated, power source 111 can receive power from host device 104 via interface 114.

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

[0030] 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.

[0031] NVM 110 may include multiple flash memory devices or memory cells. The NVM flash memory devices may include NAND-based or NOR-based flash memory devices and may store data based on the charge in the floating gate of the transistor included in each flash memory cell. In the NVM flash memory device, the flash memory device may be divided into multiple dies, each of which includes multiple physical or logical blocks, which may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. Rows of NVM cells may be electrically connected using word lines to define pages within the multiple pages. A corresponding cell in each of the multiple pages may be electrically connected to a corresponding bit line. Furthermore, the NVM flash memory device may be a 2D or 3D device and may be a single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), or four-level cell (QLC). 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.

[0032] Power source 111 can provide power to one or more components of data storage device 106. When operating in standard mode, power source 111 can use power supplied by an external device (such as host device 104) to power one or more components. For example, power source 111 can use power received from host device 104 via interface 114 to power one or more components. In some examples, power source 111 may include one or more power storage components configured to provide power to one or more components when operating in a shutdown mode (such as when power is stopped from external devices). In this way, power source 111 can be used as an onboard backup power source. Some examples of such power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of power that can be stored by one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of such power storage components. In other words, as the amount of power stored by one or more power storage components increases, the cost and / or size of such power storage components also increases.

[0033] Controller 108 may use volatile memory 112 to store information. Volatile memory 112 may include one or more volatile memory devices. In some examples, controller 108 may use volatile memory 112 as a cache. For example, controller 108 may store cached information in volatile memory 112 until that cached information is written to NVM 110. Figure 1 As illustrated, volatile memory 112 can consume power received from power source 111. Examples of 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, optional DRAM 118 can be used to store mapped data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, etc. In some examples, data storage device 106 does not include optional DRAM 118, making data storage device 106 DRAM-free. In other examples, data storage device 106 includes optional DRAM 118.

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

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

[0036] When a panic event is averted, the issue can still be reported to the host device via the telemetry interface to notify the host device that the panic event has been averted, but the issue should still be investigated. Logs provided via telemetry can be collected and returned to the storage vendor for classification. This disclosure describes a mechanism that can implement an internal device reset in situations currently involving host device resets, thereby transforming a panic situation into a notification.

[0037] Previously, system state was not written to memory, and in many failure events, the data storage device relied on a host device reset to recover that state. This disruption not only affected end users but also potentially impacted the overall efficiency and productivity of the data storage device or system. This scenario should be minimized.

[0038] Figure 2This is a block diagram 200 that depicts the standard for introducing a single root input / output (I / O) virtualization (SR-IOV) system. Figure 2 This example illustrates multiple virtual machines, various virtual functions (VFs), and physical functions (PFs). In a typical scenario, there might be several PFs and multiple VFs. The root complex shown and the rest of the system also exist.

[0039] SR-IOV allows a PCIe device to appear as multiple PCIe devices. The NVMe standard includes support for SR-IOV, allowing multiple virtual controllers to address the same media pool. This has use cases in enterprise computing and automotive storage devices. These use cases are collectively referred to as multi-tenancy, where each tenant is a VF or PF that has access to a sandboxed and limited representation of the device that appears to be a full storage device but is actually part of the entire storage device.

[0040] Another part of this disclosure relates to handling panic events at a data storage device. A panic event occurs when certain adverse events have already occurred internally within the data storage device. Examples of panic events include extreme heat, errors in flash memory, etc. The data storage device will need to recover from the panic event. There are two types of recovery: host device-initiated reset and recovery without host device intervention.

[0041] For a reset initiated by the host device, the data storage device only notifies the host device that the data storage device is stuck and needs to be reset. Most users prefer to avoid resets or at least minimize resets in their system. Therefore, even if a fault can be detected, it is preferable to avoid resets. Instead of performing a reset, one option is to handle the panic event internally within the data storage device without host device intervention. This is preferred if a panic event is detected and host device intervention is indeed not required. The host device can be updated, but there are no functional expectations from the host device. When there is a single host device interacting with the data storage device, the process is fairly simple, but as discussed in this paper, there will be some complexity when there are multi-tenant devices.

[0042] When a data storage device encounters an internal failure, it has multiple recovery paths. Some failures can be handled within the data storage device itself, while others involve resetting the host interface or otherwise disrupting host-device communication. While, as mentioned above, mechanisms exist in the NVMe and OCP standards to mitigate panic events while minimizing the impact on end users, some users of both client-side and enterprise SSDs prefer to reduce the frequency of panic events and find creative ways to avoid disrupting the host device interface in any possible way.

[0043] Even when a panic event is averted, the issue can still be reported to the host device via the telemetry interface, as described above. This notification informs the host device that the panic has been averted, but the issue should still be investigated. Logs provided via telemetry can be collected and returned to the storage vendor for categorization.

[0044] Previously, a mechanism that enabled internal device resets in situations requiring host device resets transformed panic into notifications. This reduces host device interaction by decreasing the number of resets requiring explicit host device involvement. In the event of a failure, the system will be able to recover its state and continue operation.

[0045] Storage systems connected to a single (physical or virtual) host are straightforward. Multitenant systems (which include a single PCIe port with several VF / PF, or a standard multi-host system with several PCIe ports) present additional challenges. Some host devices may be read-intensive and therefore qualified to handle internal resets, while others have more complex workloads requiring host device-initiated resets.

[0046] The standard state-of-the-art technical solutions for memory device resets are dictated by the fact that system state is not written to memory. In many failure events, storage systems rely on host device resets to recover their state. Disruptions not only affect direct users but also potentially impact the overall efficiency and productivity of the device or system. As mentioned above, some end users wish to minimize those scenarios.

[0047] The single-interface system uses a hardware log that records parameters in the front-end state as the data storage device operates and runs correctly. When the data storage device detects an internal fault, it rolls back its state to the last known good configuration, essentially aborting any incomplete or acknowledged in-flight commands. The data storage device then continues from the last known good configuration.

[0048] The key difference between a panic event and a warning mentioned in telemetry is the need to reset the host interface. Typically, a host interface needs to be reset during a panic event as part of returning the interface to a known state after a failure. As will be discussed below, many of these issues can be isolated to allow an internal reset to return the interface to a known state without host device intervention.

[0049] While applicable to various interface protocols, this description focuses on PCIe / NVMe to illustrate a specific implementation. Candidate protocols that may benefit from this disclosure may possess the following characteristics: device bus mastering to allow silent restarts of aborted commands; a queuing architecture where command execution is device-initiated and the host device is unaware of when command execution begins; and decoupled logical and physical protocols where a failure in NVMe does not necessarily require a link restart.

[0050] Hardware logs are used to record parameters in the front-end state as the data storage device operates and runs correctly. When the data storage device detects an internal failure, it rolls back its state to the last known good configuration, essentially aborting any incomplete or acknowledged in-flight commands. The data storage device then continues from the last known good configuration.

[0051] Figure 3 This is a schematic diagram 300 of a block diagram for an internal reset of a single-port memory device. Figure 3 This illustrates the host device and the interface between the host device and the data storage device. In NVMe, there are command queues and many other items. Within the data storage device controller, there are HIM, Physical Interface (PHY), Endpoint (EP) or MAC, and other components not shown. There is also a fault indication model, a fault detector model that updates the fault indication model upon failure, a status logging module responsible for periodically capturing the current state of the host device, and a fault recovery module. The status logging module is responsible for determining the current state of the interface between the host device and the data storage device. Whenever fault recovery is required and it is desirable to avoid host device involvement, the log can be stored in flash memory. Generally, the data storage device retrieves the latest update from the status logging module and recovers from that update. This concept is more relevant to heavy read workloads, as managing write commands becomes very difficult if they exist, as the host device anticipates that previous write operations will eventually be written to the storage device.

[0052] The fault indication module added to the controller is used to monitor the current controller status and, if any indication of a fault event is observed, to check whether the fault can be handled without a host reset.

[0053] Not all commands can be rolled back during fault recovery. If a command is in progress or was recently processed, it may trigger the need for host-assisted recovery and a panic event. Some examples include: acknowledged write commands, DSM commands, and management commands that change device state. For acknowledged write commands, the host-side memory buffer is released once the write command is acknowledged, and the write cannot be restarted without additional host involvement. For DSM commands (prune / unmap), the executed DSM command will corrupt data. If an interleaved write command may have completed after a DSM, rolling back and re-executing the DSM may result in data loss. In these cases, a panic event should be triggered. For management commands that change device state, management commands are typically processed orthogonally, while I / O commands are being processed in parallel. If a management command will change device state, it may lead to complex interactions with restarting I / O commands.

[0054] Figure 4 This is flowchart 400 illustrating the handling of a fault event according to one implementation. Initially, at block 402, the fault indication module signals that a near-fault event has occurred. Then, at block 404, a reset is performed to determine whether the fault event can be handled without host device intervention. If the fault cannot even be handled without host device intervention, the fault is handled with a host state reset at block 406. However, if the fault event can be handled without a host device reset, host device isolation is initiated at block 408, followed by internal fault handling and state reset at block 410. At block 412, the fault recovery module restores the system state from the state recovery database, and at block 414, host device isolation is removed and normal operation is restored.

[0055] The fault indication module may also include a listener assertion mechanism. If certain assertions are set, the fault indication module can instruct the status recording module to record the status. To avoid problems related to fault event handling, the dedicated memory for status recording may have a reset field separate from other memory sections. This is handled internally by the storage controller. Figure 3 The thick dashed line indicates this. Even if parts of the memory are reset during a fault event, the state record memory domain should not be affected, allowing host queue processing to resume after the fault event is resolved. The state record database should contain the minimum information required to restore the system state after an internal reset. This information may include queue pointers, pending CIDs in devices that have been committed by the host device but not yet completed by the data storage device, and other information.

[0056] Operations of the status recording module in Figure 5 As described in the text. Figure 5This is flowchart 500 illustrating the status logging module and database operations according to one implementation scheme. At box 502, the status logging module writes status parameters to the status logging database when a certain time threshold has elapsed, or when an event triggers the operation (such as a new host command arriving). After a predetermined time period has elapsed or another triggering event has occurred, the status logging module decides to delete expired data at box 504. At box 506, when data in the database has expired, the data is deleted.

[0057] To address multi-tenant panic handling, a combination of internal resets and host-triggered panic mitigation is utilized. This concept allows for reduced overall host device involvement in resets for multi-tenant use cases. The concept involves coordinating and synchronizing a combination of internal and external reset operations across different tenants. The idea is to selectively adapt resets for different tenants to reset operations performed between devices or on external host devices (based on the tenant's typical and current workload), and then synchronize the execution of resets for the remaining tenants with the management functions themselves.

[0058] Figure 6 and Figure 7 The flowchart of the main implementation scheme is shown in the figure. Figure 6 This is flowchart 600, which illustrates the mitigation of panic events in a multi-tenant system. Figure 7 This is flowchart 700, which illustrates selective reset preparation for a multi-tenant system.

[0059] Generally, interface connections with multiple host devices should be considered, as one host device may have one workload while another may have a different workload, and how to manage these different workloads should be considered and managed. The bottom line is to minimize the number of panic events that occur when interacting with host devices.

[0060] Figure 6 A multi-tenant system is illustrated. There are two PFs, PF0 and PF1. PF0 has two VFs, VF0 and VF1. Of course, this disclosure is not limited to two PFs and two VFs, as other combinations are contemplated. Figure 6 On the left-hand side, at box 602, the type of trace the controller continuously tracks at box 602 is shown, such as the presence of read or write workloads as determined at box 604. The controller will track the workload for each PF and each VF in the system and label it, for example, a bitmap. The bitmap is a very simple bitmap and simply indicates whether there is a large read workload. For better flexibility, other things such as whether to apply panic mode can be considered, such as the data storage device preferring any special management commands that do not involve the host device. Temperature is another possibility.

[0061] On the right-hand side, at box 606, the controller tracks reset indications. At box 608, it is determined whether a fault exists and whether a fault in at least one of the PF or VF necessitates a reset to recover from operation. If so, at box 610, the bitmap is checked for each read type of PF and VF. If it is a read type VF or PF, the reset can be handled internally within the data storage device at box 612; however, for other types of VF / PF, the reset is initiated using the host device at box 614.

[0062] In cases with multiple faults or faults that will affect multiple VFs or PFs in the system, the system will wait for a reset, such as... Figure 7 As shown. Specifically, the controller will collect host reset feedback, and internal reset preparation will begin at box 702. It will be determined at box 704 whether all resets are ready. If not, the controller waits. If yes, a reset is initiated for all relevant VF / PF at box 706.

[0063] For example, one VF will handle a fault with panic mode, while another VF will handle a fault without panic mode and without updating or interacting with the host device. Synchronization should occur if multiple functional VFs and / or PFs are affected, or if a reset is required due to a fault. Even if one VF requests a host device reset and another VF can internally handle the fault, the reset will wait because the VF that can internally handle the fault is not ready to reset. Therefore, the host device reset will wait until all VFs are ready, and then everything will be reset immediately.

[0064] Figure 8 This is a schematic diagram 800 of a storage system with resources for mitigating panic events. Figure 8 A high-level block diagram of the system proposed in this invention is depicted. In this example, the device controller supports a multi-host PCIe configuration (4 PCIe ports). A fault detector engine is responsible for detecting such faults. It interacts with panic reset and transparent reset modules to communicate with each host in the host hierarchy, depending on the workload. A reset synchronization module is responsible for synchronizing this message and issuing a single reset to the device controller when all tenants are ready.

[0065] Device controller coupled to Figure 8 The system comprises multiple host devices (host A through host D) and includes a HIM, a fault detector that detects the types of faults in the device controller, and two modes (panic reset or transparent reset). Logs are sent to the host devices, and logic is provided to synchronize the VFs that are reset due to operation.

[0066] Panic mitigation will reduce the number of resets requiring host device involvement, not only for single-port memory devices but also for multi-tenant devices (such as those used in the enterprise computing or automotive markets). Panic mitigation will allow for improved system recovery in the event of a failure at one or more of the relevant VF / PF. In the event of a failure, the system will be able to recover its system state and continue operation.

[0067] 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: track indications of resets for one or more physical functions (PFs), one or more virtual functions (VFs), or a combination of PFs and VFs; determine whether a reset is to occur; determine whether the workload is a read workload; and determine whether to process the reset internally or to redirect to the host device to initiate a reset. The one or more PFs, the one or more VFs, or the combination of PFs and VFs includes a first PF and a second PF, wherein the first PF includes a first VF and a second VF. The controller is configured to determine that the workload is a read workload, and wherein the controller is configured to process the reset internally. The controller is configured to determine that the workload is not a read workload, and wherein the controller is configured to redirect to the host device to initiate the reset. The controller is configured to collect reset feedback and internal reset readiness, wherein the controller is configured to determine whether all resets are ready, and wherein the controller is configured to initiate a reset for all relevant VFs and PFs. The initiated reset is both internal and external. The controller is configured to track the type of trace. The controller is configured to store indications of whether a read workload is for each of the one or more Power Factors (PFs), the one or more Virtual Functions (VFs), or a combination of the PFs and VFs. The controller includes a fault detector. The controller includes a Host Interface Module (HIM), which includes a panic reset module, a transparent reset and logging module, and a reset synchronization module.

[0068] 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: operate as a multi-tenant device coupled to one or more physical functions (PFs), one or more virtual functions (VFs), or a combination of PFs and VFs; trace a path for each of the one or more PFs, the one or more VFs, or the combination of PFs and VFs; determine whether the traces are for a read workload; and store an indication of whether the workload is a read workload. The controller is configured to determine that a reset should occur and internally process the reset for functions with read workloads. The controller is also configured to determine that a reset should occur and redirect the reset to a host device for functions with workloads other than read workloads. Tracing is performed continuously. Once a reset is indicated, the tracing is performed by determining the current workload of each of the one or more PFs, each of the one or more VFs, or each VF and PF in the combination of PFs and VFs. At least one PF includes a plurality of VFs. The storage includes storing values ​​in a bitmap indicating whether the workload is a read workload or a workload other than a read workload.

[0069] 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: determine that a near-failure event has occurred; determine that the near-failure event can be handled without a host device reset; initiate host device isolation; handle a state reset; restore the system state from a state recovery database; and remove host device isolation. The controller includes a fault indication module and a fault recovery module, and wherein the controller maintains the state recovery database. The controller operates as a multi-tenant device coupled to one or more physical functions (PFs), one or more virtual functions (VFs), or a combination of PFs and VFs.

[0070] While the foregoing describes an embodiment of this disclosure, other and additional embodiments of this disclosure may be designed without departing from the basic scope of this disclosure, the scope of which is defined by the appended claims.

Claims

1. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, wherein the controller is configured to: Track indications for resetting one or more physical functions (PF), one or more virtual functions (VF), or a combination of PF and VF; Determine whether a reset is necessary; Determine if the workload is a read workload; and Determine whether to process the reset internally or transfer it to the host device to initiate a reset.

2. The data storage device according to claim 1, wherein the one or more PFs, the one or more VFs, or the combination of the PF and VFs includes a first PF and a second PF, wherein the first PF includes a first VF and a second VF.

3. The data storage device of claim 1, wherein the controller is configured to determine that the workload is a read workload, and wherein the controller is configured to internally process the reset.

4. The data storage device of claim 1, wherein the controller is configured to determine that the workload is not a read workload, and wherein the controller is configured to redirect to the host device to initiate the reset.

5. The data storage device of claim 1, wherein the controller is configured to collect reset feedback and internal reset preparation, wherein the controller is configured to determine whether all resets are ready, and wherein the controller is configured to initiate a reset for all relevant VFs and PFs.

6. The data storage device of claim 5, wherein the initiated reset is both internal and external.

7. The data storage device of claim 1, wherein the controller is configured to track the type of trace.

8. The data storage device of claim 7, wherein the controller is configured to store an indication of whether the workload is a read workload for each of the one or more PFs, the one or more VFs, or a combination of the PFs and VFs.

9. The data storage device of claim 1, wherein the controller includes a fault detector.

10. The data storage device according to claim 1, wherein the controller includes a host interface module (HIM), and the HIM includes a panic reset module, a transparent reset and logging module, and a reset synchronization module.

11. A data storage device, the data storage device comprising: Memory devices; and A controller, coupled to the memory device, wherein the controller is configured to: As a multi-tenant device operating coupled to one or more physical functions (PF), one or more virtual functions (VF), or a combination of PF and VF; Tracing the traces of each of the one or more PFs, the one or more VFs, or a combination of the PFs and VFs; Determine whether the trace is for a read workload; as well as The storage indicates whether the workload is a read workload.

12. The data storage device of claim 11, wherein the controller is configured to determine that a reset should occur and to internally process the reset for a function having a read workload.

13. The data storage device of claim 11, wherein the controller is configured to determine that a reset should occur and redirect the host device to initiate the reset for a function having a workload other than a read workload.

14. The data storage device of claim 11, wherein the tracking is performed continuously.

15. The data storage device of claim 11, wherein once a reset is indicated, the tracing is performed by determining the current workload of each of the one or more PFs, each of the one or more VFs, or each VF and PF in a combination of the PFs and VFs.

16. The data storage device of claim 11, wherein at least one PF comprises a plurality of VFs.

17. The data storage device of claim 11, wherein the storage includes storing in a bitmap a value indicating whether the workload is a read workload or a read workload other than the read workload.

18. A data storage device, the data storage device comprising: Devices for storing data; and A controller, coupled to the means for storing data, wherein the controller is configured to: A near-failure event has been confirmed. It was determined that the near-failure event could be handled without resetting the host device; Initiate host device isolation; Processing status reset; Restore the system state from the state recovery database; as well as Remove host device isolation.

19. The data storage device of claim 18, wherein the controller includes a fault indication module and a fault recovery module, and wherein the controller maintains the state recovery database.

20. The data storage device of claim 19, wherein the controller operates as a multitenant device coupled to one or more physical functions (PF), one or more virtual functions (VF), or a combination of PF and VF.

Images