Assertion processing method, computer program product, device and medium for multi-core solid state drive

Abstract

The present application provides an assertion processing method, computer program product, device and medium for a multi-core solid-state drive, including selecting an execution CPU in the multi-core solid-state drive in response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state drive, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system; triggering the execution CPU to process an abnormal I / O command currently processed by the abnormal CPU and feeding it back to an upper-level read-write device in the storage system; in response to the upper-level read-write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state drive; detecting that the device driver layer stops sending I / O commands to the multi-core solid-state drive and that a specified field of the controller register has changed, removing the multi-core solid-state drive from the storage system. Ensure timely identification of faulty solid-state drives; ensure the reliability and speed of kicking the upper-level storage.

Description

Technical Field

[0001] The present application relates to the field of storage technology, and in particular to an assertion processing method, computer program product, device and medium for a multi-core solid-state hard disk. Background Art

[0002] Existing storage systems inevitably have the problem that the hard disk cannot store data normally due to firmware failure. The traditional solution to the firmware failure problem is usually to directly use the assertion mechanism to force the CPU into an infinite loop mode.

[0003] In this mode, the SSD will be in a lost disk state, causing some external I / O commands of the host to be unable to respond on the disk side because they are in an asserted state; further, after the SSD fails, the storage system cannot kick the failed hard disk in time, thus affecting the normal operation of the entire storage system.

[0004] Therefore, there is an urgent need for a method that can ensure that the storage system can quickly kick out a failed hard disk that has an assertion problem to solve the above technical problems. Summary of the invention

[0005] Based on this, it is necessary to provide an assertion processing method, computer program product, device and medium for a multi-core solid-state hard disk to address the above technical problems, so as to quickly remove the solid-state hard disk that has asserted from the storage system and quickly kick the storage system.

[0006] In a first aspect, the present application provides an assertion processing method for a multi-core solid-state hard disk, which is applied to a storage system, comprising:

[0007] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0008] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0009] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0010] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0011] In some embodiments, the method comprises:

[0012] In response to detecting that there are one or more abnormal CPUs in the multi-core solid state drive, changing an assertion flag pre-stored in the multi-core solid state drive to 1;

[0013] In response to detecting that the assertion flag is 1, the normal CPUs other than the abnormal CPU in the multi-core solid-state drive are notified to execute a fault mode to ensure that the normal CPUs feed back the currently received I / O commands to be processed to the upper-level read-write device.

[0014] In some embodiments, the normal CPU executes a fault mode to ensure that the normal CPU feeds back the currently received pending I / O command to the upper-layer read / write device, including:

[0015] The normal CPU performs loopback processing on the to-be-processed I / O command in the front-end module;

[0016] The normal CPU changes the status code of the pending I / O command to an error state and feeds back the pending I / O command with the status code changed to the error state to the upper-layer read-write device.

[0017] In some embodiments, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule includes:

[0018] Obtaining resource occupancy rates of each normal CPU in the multi-core solid-state hard disk except the abnormal CPU;

[0019] Compare the minimum resource occupancy rate among the resource occupancy rates corresponding to the normal CPUs with a first preset threshold;

[0020] If the minimum resource occupancy rate is less than or equal to the first preset threshold, a normal CPU corresponding to the minimum resource occupancy rate is selected as the execution CPU.

[0021] In some embodiments, selecting an execution CPU from the multi-core solid-state drive according to a preset selection rule further includes:

[0022] If the minimum resource occupancy rate is greater than the first preset threshold, obtaining a virtual address of the abnormal CPU in the multi-core solid-state hard disk;

[0023] Acquire two adjacent CPUs corresponding to virtual addresses adjacent to the virtual address corresponding to the abnormal CPU;

[0024] Determining whether there is the abnormal CPU in the two adjacent CPUs;

[0025] If the abnormal CPU does not exist in the adjacent CPUs, any one of the adjacent CPUs is selected as the execution CPU;

[0026] If there is one abnormal CPU among the adjacent CPUs, another adjacent CPU other than the abnormal CPU among the adjacent CPUs is selected as the execution CPU;

[0027] If the adjacent CPUs are all abnormal CPUs, a CPU is randomly selected from the multiple normal CPUs as the execution CPU.

[0028] In some embodiments, the method further comprises:

[0029] In response to the selection of the execution CPU, triggering the execution CPU to copy the exception context of the exception I / O command currently processed by the exception CPU;

[0030] The execution CPU is triggered to feed back the exception context to the upper-layer read-write device, so as to analyze the assertion cause of the multi-core solid-state drive based on the exception context.

[0031] In some embodiments, the method further comprises:

[0032] In response to detecting that a specified field of the controller register has been changed, determining that a multi-core solid-state hard disk matched by the controller register in which the specified field has been changed is a faulty solid-state hard disk, wherein the controller register corresponds to the multi-core solid-state hard disk in a one-to-one manner;

[0033] Detecting whether the storage system removes the faulty solid state drive within a first preset time period;

[0034] If the storage system does not remove the multi-core solid-state hard disk within the first preset time period, the PCIe link between the device driver layer and the faulty multi-core solid-state hard disk is disconnected to achieve physical isolation of the faulty solid-state hard disk.

[0035] In some embodiments, detecting whether the storage system removes the faulty solid state drive within a first preset time period includes:

[0036] Detecting whether there is a reset operation instruction within the first preset time period;

[0037] If the reset operation instruction is detected within the first preset time period, determining that the storage system removes the faulty solid state drive within the first preset time period;

[0038] If the reset operation instruction is detected within the first preset time period, it is determined that the storage system has not removed the faulty solid state drive within the first preset time period.

[0039] In some embodiments, the method includes detecting whether a specified field of the controller register has changed:

[0040] Triggering a status inspection mechanism to detect whether a specified field of the controller register corresponding to each of the multi-core solid state drives is changed, wherein the status inspection mechanism includes:

[0041] Acquire the current value of the specified field of the controller register once every second preset time period;

[0042] Comparing the obtained current value with an initial value corresponding to a specified field of the controller register;

[0043] If the current value is inconsistent with the initial value, determining that a designated field of the controller register is changed;

[0044] If the current value is consistent with the initial value, it is determined that the designated field of the controller register has not been changed.

[0045] In some embodiments, the method further comprises:

[0046] The status inspection mechanism is set in the device driver layer, and the device driver layer receives the inspection start instruction generated by the upper layer read / write device in response to receiving the abnormal I / O command, and triggers the status inspection mechanism;

[0047] Alternatively, the status inspection mechanism is set in the upper-layer read / write device, and the upper-layer read / write device triggers the status inspection mechanism in response to a received abnormal I / O command.

[0048] In some embodiments, after detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, the method further includes:

[0049] If no change in the specified field of the controller register is detected within a third preset time period, an assertion detection exception prompt is generated and fed back to the user to prompt the user to choose whether to remove the multi-core solid state drive;

[0050] If the user chooses to remove the multi-core solid-state hard disk, the multi-core solid-state hard disk is forcibly removed from the storage system;

[0051] Otherwise, the removal of the multi-core solid-state drive from the storage system is triggered according to the number of I / O commands received by the upper-layer read / write device and the corresponding response time.

[0052] In some embodiments, the triggering of removing the multi-core solid-state drive from the storage system according to the number of I / O commands received by the upper-layer read / write device and the corresponding response time includes:

[0053] In response to the number of I / O commands with error status codes among the received I / O commands exceeding a second preset threshold, triggering removal of the multi-core solid-state drive from the storage system;

[0054] And, in response to the number of I / O commands with response time timeouts among the received I / O commands exceeding the second preset threshold, triggering removal of the multi-core solid state drive from the storage system.

[0055] In some embodiments, the method comprises:

[0056] In response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state drive, changing the value of a fatal status field in the controller register;

[0057] In response to detecting a fatal status field change in the controller register, removing the failed solid state drive from the storage system.

[0058] In some embodiments, in response to detecting that the assertion flag is 1, notifying a normal CPU other than the abnormal CPU in the multi-core solid-state drive to execute a fault mode to ensure that the normal CPU feeds back the currently received pending I / O command to the upper-layer read / write device, including:

[0059] In response to detecting that the assertion flag is 1, generating an interrupt signal and sending it to the normal CPU;

[0060] or, in response to detecting that the assertion flag is 1, generating an assertion message and sending it to the normal CPU;

[0061] In response to the received interrupt signal or the assertion message, the normal CPU interrupts the processing of the currently received pending I / O command and executes the fault mode to ensure that the normal CPU feeds back the pending I / O command to the upper-level read / write device.

[0062] In some embodiments, after the multi-core solid-state drive is removed from the storage system, the method further includes:

[0063] Generate a fault cause prompt based on the assertion cause analyzed by the upper-layer read-write device to prompt

[0064] The user repairs the faulty solid state drive;

[0065] In response to detecting that the fault repair of the faulty solid state drive is complete, the faulty solid state drive is formatted and the faulty solid state drive after the fault repair is complete is reinstalled into the storage system.

[0066] In some embodiments, it is characterized in that

[0067] The assertion flag is stored in a pre-set general register in the multi-core solid state drive in the form of a field;

[0068] or,

[0069] The assertion flag is stored in the form of bytes in a storage space pre-divided in the multi-core solid state drive.

[0070] In some embodiments, the method includes detecting an abnormal CPU in a multi-core solid-state drive:

[0071] Detecting whether a CPU execution assertion statement exists in a plurality of CPUs included in the multi-core solid state drive;

[0072] If it is detected that there is a CPU execution assertion statement, it is determined that there is an abnormal CPU in the multi-core solid state drive;

[0073] If no CPU execution assertion statement is detected, it is determined that no abnormal CPU exists in the multi-core solid state drive.

[0074] In a second aspect, the present application provides an assertion processing system for a multi-core solid-state hard disk, the system comprising:

[0075] an abnormal response module, configured to select an execution CPU in the multi-core solid-state drive according to a preset selection rule in response to detecting that one or more abnormal CPUs exist in the multi-core solid-state drive, and to change a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0076] An I / O command processing module, used for triggering the execution CPU to process the abnormal I / O command currently processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0077] The I / O command processing module is further used to trigger the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk in response to the upper-layer read / write device receiving an abnormal I / O command;

[0078] The hard disk processing module is used to remove the multi-core solid state disk from the storage system in response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state disk and there is a change in the specified field of the controller register.

[0079] In a third aspect, the present application provides a computer program product, which, when executed by a processor, implements the steps of the following method:

[0080] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0081] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0082] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0083] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0084] In a fourth aspect, the present application provides an electronic device, the electronic device comprising:

[0085] one or more processors;

[0086] and a memory associated with one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, perform the following operations:

[0087] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0088] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0089] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0090] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0091] In a fifth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and the computer program enables a computer to perform the following operations:

[0092] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0093] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0094] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0095] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0096] The beneficial effects achieved by this application are:

[0097] The present application provides an assertion processing method for a multi-core solid-state drive, including, in response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU with an assertion problem; triggering the execution CPU to process the abnormal I / O command currently processed by the abnormal CPU and feeding back the processed abnormal I / O command to an upper-level read-write device in the storage system; in response to the upper-level read-write device receiving the abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state drive; in response to detecting that the device driver layer stops sending I / O commands to the multi-core solid-state drive and there is a change in the specified field of the controller register, removing the multi-core solid-state drive from the storage system. Ensure timely identification of faulty solid-state drives; ensure the reliability and speed of kicking the upper-level storage; in actual application, greatly ensure the storage system's rapid perception and fault isolation of solid-state drives with assertions, and complete rapid switching of customer services and data migration. BRIEF DESCRIPTION OF THE DRAWINGS

[0098] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work, among which:

[0099] Figure 1 is a schematic diagram of a typical storage system provided in an embodiment of the present application;

[0100] Figure 2 It is a schematic diagram of an assertion processing method for a multi-core solid-state hard disk provided in an embodiment of the present application;

[0101] Figure 3 It is a schematic diagram of a storage system supporting assertion processing of a multi-core solid-state hard disk provided in an embodiment of the present application;

[0102] Figure 4 This is an architecture diagram of an assertion processing system for a multi-core solid-state hard disk provided in an embodiment of the present application;

[0103] Figure 5 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0104] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0105] It should be understood that in the description of the present application, unless the context clearly requires otherwise, words such as "include", "comprises", and the like in the entire specification and claims should be interpreted as inclusive rather than exclusive or exhaustive; that is, the meaning of "including but not limited to".

[0106] It should also be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of this application, unless otherwise specified, "plurality" means two or more.

[0107] It should be noted that the terms "S1", "S2", etc. are only used for the purpose of describing the steps, and do not specifically refer to the order or sequence, nor are they used to limit the present application. They are only for the convenience of describing the method of the present application, and cannot be understood as indicating the order of the steps. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in this field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present application.

[0108] As mentioned in the background technology, with the continuous development of storage systems, solid-state drives are gradually replacing traditional hard drives. However, solid-state drives inevitably have firmware failure problems in actual product applications. Directly using the Assert assertion mechanism according to the traditional processing method will force the CPU to be in an infinite loop mode. In this mode, the solid-state drive will always be in a lost disk state, resulting in the host's external I / O commands being unable to respond on the disk side due to ASSERT.

[0109] In the existing solution, when one of the SSDs in the disk array fails, the storage system needs to wait for the SSD to return all the I / O commands that have been issued before deciding whether to kick the disk; the speed of kicking the disk usually determines the fault handling speed of the entire storage system and the impact on customer business progress. According to the method provided by the prior art, the firmware in the SSD has been in an infinite loop state after the assertion problem occurs and does not perform other operations. The disk is kicked only after the upper-layer application is abnormal, which takes a long time and causes the storage system to fail to isolate the faulty hard disk in time, thereby triggering the problem of slow data migration and affecting the customer's business process.

[0110] Therefore, this case provides an assertion processing method for a multi-core solid-state hard drive. After a firmware failure occurs in the solid-state hard drive, a method is provided to quickly remove the solid-state hard drive with firmware failure from the storage system, thereby ensuring the normal operation of the business by ensuring the rapid kicking of the storage system. Embodiment 1

[0111] The present application embodiment provides an assertion processing method for a multi-core solid-state hard disk, which is applied to a storage system. Figure 1 A typical storage system is disclosed, including an application layer, a file system, a buffer layer, a read-write device layer, a block device layer, and a device driver layer, wherein the device driver layer is connected to a solid state drive (not shown in the figure).

[0112] Specifically, in the storage system, the file system will call the specific file read and write process, convert the starting position and offset of the file into the data block in the specific file system, and pass this information to the buffer layer below; the buffer layer encapsulates this data block into a buffer header, first searches for the buffer header in the buffer cache, and responds immediately if it is found, otherwise it allocates a buffer and forms an I / O request, and hangs it in the request queue of the device according to the logical device name and block number of the data block. The RAID driver in the read-write device layer analyzes the I / O request and passes it to each submodule (raid0, raid1 or raid5) for processing according to the different RAID levels used. After these processes, the I / O request is re-imaged to each real block device, and the block device initiates the block I / O request. In the read-write device layer, some current storage systems generally use RAID technology to ensure the reliability and redundancy of the data in the disk, including RAID management, RAID read and write processing, RAID fault processing and RAID monitoring modules. Finally, the driver in the device driver layer completes the protocol layer conversion of the I / O request, sends it to the SSD, and the SSD completes the corresponding I / O command. After completion, the processing results are passed up layer by layer to the read-write device layer, the file system, and even the upper business layer.

[0113] Specifically, Figure 2 As shown, the method disclosed in the embodiment of the present application is used to implement assertion processing of a hard disk whose firmware fails and thus an assertion occurs, and includes the following contents:

[0114] S1. In response to detecting the presence of one or more abnormal CPUs in a multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a control register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system.

[0115] Wherein, the above step S1 includes:

[0116] S11 . In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule.

[0117] The firmware of a multi-core solid-state drive includes multiple CPUs. When these CPUs process I / O commands during operation, an assertion problem may occur due to a firmware failure. In this embodiment, the CPU with the assertion problem is defined as an abnormal CPU. The abnormal CPU is in an endless loop state and cannot provide feedback on the I / O commands that have been issued (the I / O commands issued to the abnormal CPU are defined as abnormal I / O commands at this time). Therefore, this embodiment discloses the selection of an execution CPU to replace the abnormal CPU to feedback the abnormal I / O commands that currently need to be processed to the upper-level read-write device.

[0118] Specifically, the above-mentioned selection of the execution CPU in the multi-core solid-state hard disk according to the preset selection rule includes: obtaining the resource occupancy rate of each normal CPU in the multi-core solid-state hard disk except the abnormal CPU; comparing the minimum resource occupancy rate among the resource occupancy rates corresponding to each normal CPU with the first preset threshold value; if the minimum resource occupancy rate is less than or equal to the first preset threshold value, then selecting the normal CPU corresponding to the minimum resource occupancy rate as the execution CPU. The above-mentioned resource occupancy rate is the ratio of the resources already used by the CPU to the total resources of the CPU, which is used to indicate the busyness of the CPU. If the resource occupancy rate is high, the current CPU is relatively busy, and if the resource occupancy rate is low, the current CPU is relatively idle. Among them, the above-mentioned first preset threshold value can be set by the staff in this field according to the actual situation, and can preferably be set to 60% or 50%, which is not limited in this embodiment.

[0119] This application selects the CPU with the lowest resource utilization to process abnormal I / O commands that the abnormal CPU cannot process normally, that is, selects the normal CPU with the best performance to ensure the rapid processing of abnormal I / O commands, avoiding the problem of selecting other normal CPUs with high resource utilization to process abnormal I / O commands, which may increase the operating pressure of the normal CPU and cause the normal CPU to be unable to process the abnormal I / O commands in time; further improving the kicking efficiency of the entire storage system.

[0120] Furthermore, the above-mentioned selecting an execution CPU in a multi-core solid-state hard disk according to a preset selection rule also includes: if the minimum resource occupancy rate is greater than a first preset threshold, obtaining the virtual address of the abnormal CPU in the multi-core solid-state hard disk; obtaining two adjacent CPUs corresponding to virtual addresses adjacent to the virtual address corresponding to the abnormal CPU; judging whether there is an abnormal CPU among the two adjacent CPUs; if there is no abnormal CPU among the adjacent CPUs, selecting any one of the adjacent CPUs as the execution CPU; if there is an abnormal CPU among the adjacent CPUs, selecting another adjacent CPU among the adjacent CPUs except the abnormal CPU as the execution CPU; if all the adjacent CPUs are abnormal CPUs, randomly selecting a CPU from multiple normal CPUs as the execution CPU.

[0121] In the specific implementation scenario, Figure 3 In the storage system schematic diagram shown, the present application also discloses that in response to the selection of the execution CPU, the execution CPU is triggered to copy the abnormal context of the abnormal I / O command currently processed by the abnormal CPU, wherein the abnormal context is stored in the memory of the hard disk; the execution CPU is triggered to feed back the abnormal context to the upper-layer read-write device, so as to analyze the assertion cause of the multi-core solid-state hard disk based on the abnormal context. The execution CPU copies the context of the abnormal I / O command, and feeds back to analyze the cause of the assertion in the firmware of the multi-core solid-state hard disk in the subsequent analysis, so as to locate the problem and facilitate fault repair.

[0122] In addition, in a specific implementation scenario, each CPU in a multi-core solid-state drive may be numbered in advance and the serial number corresponding to each CPU may be stored. When an assertion occurs in one of the CPUs, the previous or next normal CPU corresponding to the serial number of the abnormal CPU may be directly queried and stored as an adjacent CPU.

[0123] When the resource occupancy rates of all normal CPUs in a multi-core solid-state drive are not less than or equal to the first pre-examination threshold, each normal CPU is relatively busy at this time. This embodiment proposes selecting a normal CPU near the abnormal CPU as the execution CPU, shortening the access path of the execution CPU, and improving the feedback speed of the execution CPU to abnormal I / O commands to a certain extent, thereby improving the kick speed of the storage system.

[0124] The present embodiment also discloses a detection method for an abnormal CPU, including detecting whether a CPU execution assertion statement exists in multiple CPUs included in a multi-core solid-state hard disk; if a CPU execution assertion statement is detected, determining that an abnormal CPU exists in the multi-core solid-state hard disk; if no CPU execution assertion statement is detected, determining that no abnormal CPU exists in the multi-core solid-state hard disk.

[0125] In a specific implementation scenario, the following specific methods are included but not limited to detecting whether the above-mentioned CPU executes the assertion statement: 1. Install a detection program, in which the assertion statement is used to check the internal state or assumption of the program; if the detection program prints an error message or stack trace when the assertion fails, the standard output or error data of the program can be checked to detect whether the CPU has executed the assertion statement; if the detection program is configured with logging, check whether the log file contains information about assertion failure to determine whether the CPU has executed the assertion statement. 2. Change the behavior during assertion by customizing the assertion macro, such as calling a specific function to record errors or perform other operations during assertion; determine whether the CPU has executed the assertion statement by determining whether errors or other operations are recorded, if there is an error, the CPU has executed the assertion statement, otherwise it has not been executed. 3. It is also possible to determine whether the CPU has executed the interrupt statement by reading the CPU's status register to check whether the CPU is in interrupt mode. This application does not limit the specific method for detecting whether the above-mentioned CPU executes the assertion statement. In addition to the specific method disclosed above, it also includes other methods that can detect whether the CPU executes the assertion statement, such as setting a hardware monitoring tool, etc.

[0126] The above step S1 comprises:

[0127] S12: In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state hard disk, a specified field of a control register provided by the multi-core solid-state hard disk for interacting with a device driver layer in the storage system is changed.

[0128] After detecting that there are one or more abnormal CPUs in the multi-core SSD, it is also necessary to change the specified field of the control register provided by the multi-core SSD for interacting with the device driver layer in the storage system to ensure that the multi-core SSD is identified as a faulty SSD that needs to be removed in the storage system.

[0129] In a specific implementation scenario, the detection of whether the specified field of the controller register has changed includes: triggering a status inspection mechanism to detect whether the specified field of the controller register corresponding to each multi-core solid-state hard disk has changed, wherein the status inspection mechanism includes: obtaining the current value of the specified field of the controller register once every second preset time period; comparing the obtained current value with the initial value corresponding to the specified field of the controller register; if the current value is inconsistent with the initial value, determining that the specified field of the controller register has changed; if the current value is consistent with the initial value, determining that the specified field of the controller register has not changed. Among them, the above-mentioned second preset time period is set by a technician in this field according to actual needs, preferably set to 10ms, and this application does not limit this.

[0130] In the above implementation scenario, a status patrol mechanism can be set in the device driver layer, and the device driver layer receives a patrol start instruction generated by the upper-layer read-write device in response to receiving an abnormal I / O command, thereby triggering the status patrol mechanism; or, a status patrol mechanism can be set in the upper-layer read-write device, and the upper-layer read-write device triggers the status patrol mechanism in response to receiving an abnormal I / O command.

[0131] In a specific implementation scenario, the present application also proposes to change the value of the fatal status field in the control register in response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state hard disk; in response to detecting the change of the fatal status field in the control register, remove the faulty solid-state hard disk from the storage system. By implementing the change of the specified field of the control register provided by the multi-core solid-state hard disk for interacting with the device driver layer in the storage system, the storage system is notified to remove the faulty solid-state hard disk; wherein the fatal status field value is initially 0, and the field value is changed to 1 after the assertion occurs. The controller register is an NVMe controller register used by the multi-core solid-state hard disk to interact with the upper device driver layer, wherein the setting of the NVMe controller register is a conventional technical means in the art, which will not be repeated here. In addition to the previously disclosed method of changing the fatal status field in the controller register to ensure that the storage system identifies the corresponding multi-core solid-state hard drive as a faulty solid-state hard drive that needs to be removed, a specific field can be selected from the register fields contained in the NVMe controller register, and the storage can be defined to identify the multi-core solid-state hard drive corresponding to the controller register as a faulty solid-state hard drive when the field is identified as 1. In addition, an I / O space register can be added to the NVMe controller register, a specific field can be selected from the I / O space register, and the storage can be defined to identify the multi-core solid-state hard drive corresponding to the controller register as a faulty solid-state hard drive when the field is identified as 1.

[0132] It is worth noting that in some specific implementation scenarios, after detecting the presence of one or more abnormal CPUs in a multi-core solid-state drive, the present application also proposes: if no change in the specified field of the controller register is detected within the third preset time period, an assertion detection abnormality prompt is generated and fed back to the user to prompt the user to choose whether to remove the multi-core solid-state drive; if the user chooses to remove the multi-core solid-state drive, the multi-core solid-state drive is forcibly removed from the storage system; otherwise, the multi-core solid-state drive is removed from the storage system based on the number of I / O commands received by the upper-layer read-write device and the corresponding response time. Among them, the above-mentioned third preset time period is set by those skilled in the art according to actual conditions, preferably set to 1s, and the present application does not limit this; it is worth noting that the starting time node of the above-mentioned third preset time period is the time node when one or more abnormal CPUs in the multi-core solid-state drive are detected. The present application determines that the controller register has not performed the expected operation within the specified time, and the controller register cannot respond to the assertion, that is, it is judged that there may be an assertion detection exception at this time, and the solid-state drive cannot be identified as a faulty solid-state drive; at this time, an assertion detection exception prompt is generated, and the user decides whether to force the drive to be kicked. Once the user chooses, the multi-core solid-state drive is immediately removed from the storage system; the kicking speed is improved to a certain extent.

[0133] Among them, the above-mentioned triggering of removing the multi-core solid-state drive from the storage system based on the number of I / O commands received by the upper-layer read-write device and the corresponding response time includes: in response to the number of I / O commands with error status codes among the received I / O commands exceeding a second preset threshold, triggering the removal of the multi-core solid-state drive from the storage system; and, in response to the number of I / O commands with response time timeouts among the received I / O commands exceeding the second preset threshold, triggering the removal of the multi-core solid-state drive from the storage system. The above-mentioned second preset threshold is actually adjusted by those skilled in the art according to the business processed by the storage system, and this application does not impose any constraints on this.

[0134] In addition, in some specific implementation scenarios, the above step S1 further includes:

[0135] S13, the assertion flag is changed to notify the normal CPU in the multi-core solid state drive to execute the fault mode: in response to detecting that there are one or more abnormal CPUs in the multi-core solid state drive, the assertion flag pre-stored in the multi-core solid state drive is changed to 1; in response to detecting that the assertion flag is 1, the normal CPUs in the multi-core solid state drive other than the abnormal CPU are notified to execute the fault mode to ensure that the normal CPU feeds back the currently received pending I / O command to the upper layer read-write device. The assertion flag is stored in the form of a field in a pre-set general register in the multi-core solid state drive, and the general memory can be stored in the hard disk memory; or, the assertion flag is stored in the form of a byte in the storage space pre-divided by the multi-core solid state drive, and the storage space can be divided from the hard disk memory; in addition, the above-mentioned assertion flag can also be stored through the register of the peripheral device that has been mapped to the memory address space, etc. The above-mentioned storage method is only a preferred method, and this application does not restrict the specific storage method. Those skilled in the art can select a suitable storage method to store the assertion flag according to their needs.

[0136] Among them, in response to detecting that the assertion flag is 1, notifying the normal CPUs other than the abnormal CPU in the multi-core solid-state hard disk to execute the fault mode to ensure that the normal CPU feeds back the currently received pending I / O commands to the upper-level read-write device, and also includes: in response to detecting that the assertion flag is 1, generating an interrupt signal and sending it to the normal CPU; or, in response to detecting that the assertion flag is 1, generating an assertion message and sending it to the normal CPU; the normal CPU responds to the received interrupt signal or assertion message, interrupting the processing of the currently received pending I / O commands and executing the fault mode to ensure that the normal CPU feeds back the pending I / O commands to the upper-level read-write device.

[0137] Further, in this embodiment, if Figure 3 As shown, the above-mentioned normal CPU executes the fault mode to ensure that the normal CPU feeds back the currently received pending I / O commands to the upper-layer read-write device, including: the normal CPU performs loopback processing on the pending I / O commands in the front-end module; the normal CPU changes the status code of the pending I / O commands to an error state and feeds back the pending I / O commands with the status code changed to an error state to the upper-layer read-write device. After the abnormal CPU appears, the present application promptly notifies the normal CPU where no assertion occurs by setting the assertion flag, switches the processing mode of the pending I / O commands to the fault mode, and the normal CPU only performs loopback processing on the pending I / O commands in the front-end module, and does not perform real I / O command reading and writing processing, thereby ensuring rapid feedback of the pending I / O commands in the error state and avoiding waste of resources in the normal CPU.

[0138] It is understandable that there is no order of precedence among the above-mentioned steps S11, S12 and S13, and they may be executed simultaneously or in a random order, and the present application does not impose any limitation on this.

[0139] S2, triggering the execution CPU to process the abnormal I / O command currently processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-level read-write device in the storage system.

[0140] After the execution CPU is selected, the execution CPU immediately processes the abnormal I / O command currently being processed by the abnormal CPU, and the status code of the returned abnormal I / O command is an error state, which effectively avoids the problem of the abnormal I / O command processing timeout. It can be understood that the above-mentioned execution CPU processing of the abnormal I / O command only modifies the status code of the abnormal I / O command and feeds the abnormal I / O command back to the upper-level read-write device, and does not involve business processing.

[0141] S3. In response to the upper-layer read / write device receiving an abnormal I / O command, trigger the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk.

[0142] After receiving an abnormal I / O command, the upper-layer read / write device will not get correct feedback even if it sends an I / O command. The upper-layer read / write device immediately triggers the device driver layer to stop sending I / O commands to the multi-core solid-state drive, avoiding waste of resources and further ensuring the normal execution of the business.

[0143] S4. In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid-state hard disk and a specified field of a controller register is changed, the multi-core solid-state hard disk is removed from the storage system.

[0144] In addition, in some implementation scenarios, after executing the above steps S1 to S4, there is a situation where the storage system does not remove the multi-core solid-state hard disk in which the assertion occurs within the specified time. In response to this situation, the present application also proposes that in response to detecting that a specified field of a control register has changed, the multi-core solid-state hard disk matching the control register in which the specified field has changed is determined to be a faulty solid-state hard disk, wherein the control register corresponds to the multi-core solid-state hard disk one by one; detecting whether the storage system removes the faulty solid-state hard disk within the first preset time period; if the storage system does not remove the multi-core solid-state hard disk within the first preset time period, the PCIe link between the device driver layer and the faulty multi-core solid-state hard disk is disconnected to achieve physical isolation of the faulty solid-state hard disk. Among them, the first preset time period is set by the staff in this field according to the actual situation, and the preferred setting interval is 2s-3s; this application does not limit this; it is worth noting that the starting time node of the first time period is the time node when one or more abnormal CPUs are detected in the multi-core solid-state hard disk. When a faulty SSD has been identified at the software level but cannot be removed from the storage system, the PCIe link between the multi-core SSD and the upper host is disconnected to physically isolate the faulty SSD, thereby ensuring the stability of the storage system.

[0145] Among them, in a specific implementation scenario, the above detection of whether the storage system removes the faulty solid-state hard disk within the first preset time period includes: detecting whether there is a reset operation instruction within the first preset time period; if the reset operation instruction is detected within the first preset time period, then judging that the storage system removes the faulty solid-state hard disk within the first preset time period; if the reset operation instruction is detected within the first preset time period, then judging that the storage system does not remove the faulty solid-state hard disk within the first preset time period. Of course, it is also possible to judge whether the storage system removes the faulty solid-state hard disk by connecting a status register on the solid-state hard disk side to indicate whether the solid-state hard disk is in place.

[0146] This application ensures that all I / O commands issued by the upper layer are returned to the upper-layer read-write device by selecting a normal CPU after an assertion occurs in the firmware of a multi-core solid-state hard drive, and changes the specified field of the corresponding controller register, thereby ensuring timely identification of the faulty solid-state hard drive; ensuring the reliability and speed of kicking the upper-layer storage; and in actual application, greatly ensuring the storage system's rapid perception and fault isolation of the solid-state hard drive with an assertion, completing rapid switching of customer services and data migration. Embodiment 2

[0147] Corresponding to the above-mentioned embodiment 1, as Figure 4 As shown, the embodiment of the present application also provides an assertion processing system for a multi-core solid-state hard disk, including:

[0148] The abnormal response module 410 is used for selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule in response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0149] An I / O command processing module 420, configured to trigger the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and to feed back the processed abnormal I / O command to an upper-layer read / write device in the storage system;

[0150] The I / O command processing module 420 is further used to trigger the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk in response to the upper-layer read / write device receiving an abnormal I / O command;

[0151] The hard disk processing module 430 is used to remove the multi-core solid state disk from the storage system in response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state disk and a specified field of the controller register is changed.

[0152] In some implementation scenarios, the exception response module 410 is also used to change the assertion flag pre-stored in the multi-core solid-state hard disk to 1 in response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state hard disk; in response to detecting that the assertion flag is 1, notify the normal CPUs other than the abnormal CPU in the multi-core solid-state hard disk to execute the fault mode to ensure that the normal CPU feeds back the currently received I / O commands to be processed to the upper-level read-write device.

[0153] In some implementation scenarios, the I / O command processing module 420 is also used to trigger the normal CPU to perform loop processing on the I / O command to be processed in the front-end module; the normal CPU changes the status code of the I / O command to be processed to an error state and feeds back the I / O command to be processed with the status code changed to an error state to the upper-level read-write device.

[0154] In some implementation scenarios, the abnormal response module 410 is also used to obtain the resource occupancy rate of each normal CPU in the multi-core solid-state hard disk except the abnormal CPU; compare the minimum resource occupancy rate among the resource occupancy rates corresponding to each normal CPU with a first preset threshold; if the minimum resource occupancy rate is less than or equal to the first preset threshold, then select the normal CPU corresponding to the minimum resource occupancy rate as the execution CPU.

[0155] In some implementation scenarios, the abnormal response module 410 is also used to obtain the virtual address of the abnormal CPU in the multi-core solid-state hard disk if the minimum resource occupancy rate is greater than the first preset threshold; obtain two adjacent CPUs corresponding to the virtual addresses adjacent to the virtual address corresponding to the abnormal CPU; determine whether the abnormal CPU exists among the two adjacent CPUs; if the abnormal CPU does not exist among the adjacent CPUs, select any one of the adjacent CPUs as the execution CPU; if there is one abnormal CPU among the adjacent CPUs, select another adjacent CPU among the adjacent CPUs except the abnormal CPU as the execution CPU; if the adjacent CPUs are all abnormal CPUs, randomly select a CPU from multiple normal CPUs as the execution CPU.

[0156] In some implementation scenarios, the I / O command processing module 420 is also used to trigger the execution CPU to copy the exception context of the exception I / O command currently processed by the exception CPU in response to the selection of the execution CPU; trigger the execution CPU to feed back the exception context to the upper-level read-write device, so as to analyze the assertion cause of the multi-core solid-state hard disk based on the exception context.

[0157] In some implementation scenarios, the exception response module 410 is also used to determine that the multi-core solid-state hard disk matching the controller register with the changed specified field is a faulty solid-state hard disk in response to detecting that a change has occurred in the specified field of the controller register, wherein the controller register corresponds one-to-one to the multi-core solid-state hard disk; the hard disk processing module 430 is also used to detect whether the storage system removes the faulty solid-state hard disk within a first preset time period; if the storage system does not remove the multi-core solid-state hard disk within the first preset time period, the PCIe link between the device driver layer and the faulty multi-core solid-state hard disk is disconnected to achieve physical isolation of the faulty solid-state hard disk.

[0158] In some implementation scenarios, the hard disk processing module 430 is also used to detect whether there is a reset operation instruction within the first preset time period; if the reset operation instruction is detected within the first preset time period, it is determined that the storage system removes the faulty solid-state hard disk within the first preset time period; if the reset operation instruction is detected within the first preset time period, it is determined that the storage system does not remove the faulty solid-state hard disk within the first preset time period.

[0159] In some implementation scenarios, the exception response module 410 is also used to trigger a status inspection mechanism to detect whether the specified field of the controller register corresponding to each of the multi-core solid-state hard drives has changed, wherein the status inspection mechanism includes: obtaining the current value of the specified field of the controller register once every second preset time period; comparing the obtained current value with the initial value corresponding to the specified field of the controller register; if the current value is inconsistent with the initial value, determining that the specified field of the controller register has changed; if the current value is consistent with the initial value, determining that the specified field of the controller register has not changed.

[0160] In some implementation scenarios, the exception response module 410 is also used to set the status patrol mechanism in the device driver layer, and the device driver layer receives the patrol start instruction generated by the upper-layer read-write device in response to receiving an abnormal I / O command, triggering the status patrol mechanism; or, the status patrol mechanism is set in the upper-layer read-write device, and the upper-layer read-write device triggers the status patrol mechanism in response to the received abnormal I / O command.

[0161] In some implementation scenarios, the hard disk processing module 430 is also used to: if no change in the specified field of the controller register is detected within a third preset time period, generate an assertion detection exception prompt and feed it back to the user to prompt the user to choose whether to remove the multi-core solid-state hard disk; if the user chooses to remove the multi-core solid-state hard disk, forcibly remove the multi-core solid-state hard disk from the storage system; otherwise, trigger the removal of the multi-core solid-state hard disk from the storage system based on the number of I / O commands received by the upper-level read / write device and the corresponding response time.

[0162] In some implementation scenarios, the hard disk processing module 430 is also used to trigger the removal of the multi-core solid-state hard disk from the storage system in response to the number of I / O commands with error status codes among the received I / O commands exceeding a second preset threshold; and to trigger the removal of the multi-core solid-state hard disk from the storage system in response to the number of I / O commands with response time timeout among the received I / O commands exceeding the second preset threshold.

[0163] In some implementation scenarios, the hard disk processing module 430 is also used to change the value of the fatal status field in the controller register in response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state hard disk; in response to detecting a change in the fatal status field in the controller register, remove the faulty solid-state hard disk from the storage system.

[0164] In some implementation scenarios, it is characterized in that the exception response module 410 is also used to generate an interrupt signal and send it to the normal CPU in response to detecting that the assertion flag is 1; or, in response to detecting that the assertion flag is 1, generate an assertion message and send it to the normal CPU; the normal CPU responds to the received interrupt signal or the assertion message by interrupting the processing of the currently received pending I / O command and executing a fault mode to ensure that the normal CPU feeds back the pending I / O command to the upper-level read-write device.

[0165] In some implementation scenarios, the hard disk processing module 430 is also used to generate a fault cause prompt based on the assertion cause obtained by analyzing the upper-level read-write device to prompt the user to repair the faulty solid-state hard disk; in response to detecting that the fault repair of the faulty solid-state hard disk is complete, format the faulty solid-state hard disk and reinstall the faulty solid-state hard disk after the fault repair is completed to the storage system.

[0166] In some implementation scenarios, the assertion flag is stored in a pre-set general register in the multi-core solid state drive in the form of a field; or, the assertion flag is stored in a pre-allocated storage space in the multi-core solid state drive in the form of a byte.

[0167] In some implementation scenarios, the abnormal response module 410 is also used to detect an abnormal CPU in a multi-core solid-state drive: detect whether there is a CPU execution assertion statement among the multiple CPUs contained in the multi-core solid-state drive; if a CPU execution assertion statement is detected, determine that there is an abnormal CPU in the multi-core solid-state drive; if no CPU execution assertion statement is detected, determine that there is no abnormal CPU in the multi-core solid-state drive. Embodiment 3

[0168] Corresponding to all the above embodiments, the embodiments of the present application further provide a computer program product, which implements the steps of the following method when the computer program is executed by a processor:

[0169] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0170] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0171] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0172] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0173] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0174] In response to detecting that there are one or more abnormal CPUs in the multi-core solid state drive, changing an assertion flag pre-stored in the multi-core solid state drive to 1;

[0175] In response to detecting that the assertion flag is 1, the normal CPUs other than the abnormal CPU in the multi-core solid-state drive are notified to execute a fault mode to ensure that the normal CPUs feed back the currently received I / O commands to be processed to the upper-level read-write device.

[0176] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0177] The normal CPU performs loopback processing on the I / O command to be processed in the front-end module;

[0178] The normal CPU changes the status code of the pending I / O command to an error state and feeds back the pending I / O command with the status code changed to the error state to the upper-layer read-write device.

[0179] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0180] Obtaining resource occupancy rates of each normal CPU in the multi-core solid-state hard disk except the abnormal CPU;

[0181] Compare the minimum resource occupancy rate among the resource occupancy rates corresponding to the normal CPUs with a first preset threshold;

[0182] If the minimum resource occupancy rate is less than or equal to the first preset threshold, a normal CPU corresponding to the minimum resource occupancy rate is selected as the execution CPU.

[0183] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0184] If the minimum resource occupancy rate is greater than the first preset threshold, obtaining a virtual address of the abnormal CPU in the multi-core solid-state hard disk;

[0185] Acquire two adjacent CPUs corresponding to virtual addresses adjacent to the virtual address corresponding to the abnormal CPU;

[0186] Determining whether there is the abnormal CPU in the two adjacent CPUs;

[0187] If the abnormal CPU does not exist in the adjacent CPUs, any one of the adjacent CPUs is selected as the execution CPU;

[0188] If there is one abnormal CPU among the adjacent CPUs, another adjacent CPU other than the abnormal CPU among the adjacent CPUs is selected as the execution CPU;

[0189] If the adjacent CPUs are all abnormal CPUs, a CPU is randomly selected from the multiple normal CPUs as the execution CPU.

[0190] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0191] In response to the selection of the execution CPU, triggering the execution CPU to copy the exception context of the exception I / O command currently processed by the exception CPU;

[0192] The execution CPU is triggered to feed back the exception context to the upper-layer read-write device, so as to analyze the assertion cause of the multi-core solid-state drive based on the exception context.

[0193] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0194] In response to detecting that a specified field of the controller register has been changed, determining that a multi-core solid-state hard disk matched by the controller register in which the specified field has been changed is a faulty solid-state hard disk, wherein the controller register corresponds to the multi-core solid-state hard disk in a one-to-one manner;

[0195] Detecting whether the storage system removes the faulty solid state drive within a first preset time period;

[0196] If the storage system does not remove the multi-core solid-state hard disk within the first preset time period, the PCIe link between the device driver layer and the faulty multi-core solid-state hard disk is disconnected to achieve physical isolation of the faulty solid-state hard disk.

[0197] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0198] Detecting whether there is a reset operation instruction within the first preset time period;

[0199] If the reset operation instruction is detected within the first preset time period, determining that the storage system removes the faulty solid state drive within the first preset time period;

[0200] If the reset operation instruction is detected within the first preset time period, it is determined that the storage system has not removed the faulty solid state drive within the first preset time period.

[0201] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0202] Triggering a status inspection mechanism to detect whether a specified field of the controller register corresponding to each of the multi-core solid state drives is changed, wherein the status inspection mechanism includes:

[0203] Acquire the current value of the specified field of the controller register once every second preset time period;

[0204] Comparing the obtained current value with an initial value corresponding to a specified field of the controller register;

[0205] If the current value is inconsistent with the initial value, determining that a designated field of the controller register is changed;

[0206] If the current value is consistent with the initial value, it is determined that the designated field of the controller register has not been changed.

[0207] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0208] The status inspection mechanism is set in the device driver layer, and the device driver layer receives the inspection start instruction generated by the upper layer read / write device in response to receiving the abnormal I / O command, and triggers the status inspection mechanism;

[0209] Alternatively, the status inspection mechanism is set in the upper-layer read / write device, and the upper-layer read / write device triggers the status inspection mechanism in response to a received abnormal I / O command.

[0210] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0211] If no change in the specified field of the controller register is detected within a third preset time period, an assertion detection exception prompt is generated and fed back to the user to prompt the user to choose whether to remove the multi-core solid state drive;

[0212] If the user chooses to remove the multi-core solid-state hard disk, the multi-core solid-state hard disk is forcibly removed from the storage system;

[0213] Otherwise, the removal of the multi-core solid-state drive from the storage system is triggered according to the number of I / O commands received by the upper-layer read / write device and the corresponding response time.

[0214] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0215] In response to the number of I / O commands with error status codes among the received I / O commands exceeding a second preset threshold, triggering removal of the multi-core solid-state drive from the storage system;

[0216] And, in response to the number of I / O commands with response time timeouts among the received I / O commands exceeding the second preset threshold, triggering removal of the multi-core solid state drive from the storage system.

[0217] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0218] In response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state drive, changing the value of a fatal status field in the controller register;

[0219] In response to detecting a fatal status field change in the controller register, removing the failed solid state drive from the storage system.

[0220] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0221] In response to detecting that the assertion flag is 1, generating an interrupt signal and sending it to the normal CPU;

[0222] or, in response to detecting that the assertion flag is 1, generating an assertion message and sending it to the normal CPU;

[0223] In response to the received interrupt signal or the assertion message, the normal CPU interrupts the processing of the currently received pending I / O command and executes the fault mode to ensure that the normal CPU feeds back the pending I / O command to the upper-level read / write device.

[0224] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0225] Generate a fault cause prompt based on the assertion cause obtained by the upper-layer read-write device analysis to prompt the user to repair the fault of the faulty solid-state hard disk;

[0226] In response to detecting that the fault repair of the faulty solid state drive is complete, the faulty solid state drive is formatted and the faulty solid state drive after the fault repair is complete is reinstalled into the storage system.

[0227] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0228] The assertion flag is stored in a pre-set general register in the multi-core solid state drive in the form of a field;

[0229] or,

[0230] The assertion flag is stored in the form of bytes in a storage space pre-divided in the multi-core solid state drive.

[0231] In some implementation scenarios, when the computer program is executed by a processor, the steps of the following method are also implemented:

[0232] Detecting whether a CPU execution assertion statement exists in a plurality of CPUs included in the multi-core solid state drive;

[0233] If it is detected that there is a CPU execution assertion statement, it is determined that there is an abnormal CPU in the multi-core solid state drive;

[0234] If no CPU execution assertion statement is detected, it is determined that no abnormal CPU exists in the multi-core solid state drive. Embodiment 4

[0235] Corresponding to all the above embodiments, an embodiment of the present application provides an electronic device, including: one or more processors; and a memory associated with the one or more processors, the memory is used to store program instructions, and when the program instructions are read and executed by the one or more processors, the following operations are performed:

[0236] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0237] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0238] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0239] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0240] in, Figure 5 The architecture of the electronic device is shown as an example, which may include a processor 510, a video display adapter 511, a disk drive 512, an input / output interface 513, a network interface 514, and a memory 520. The processor 510, the video display adapter 511, the disk drive 512, the input / output interface 513, the network interface 514, and the memory 520 may be communicatively connected via a bus 530.

[0241] Among them, the processor 510 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solution provided in this application.

[0242] The memory 520 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 520 can store an operating system 521 for controlling the execution of the electronic device 500, and a basic input and output system (BIOS) 522 for controlling the low-level operations of the electronic device 500. In addition, a web browser 523, a data storage management system 524, and an icon font processing system 525, etc. can also be stored. The above-mentioned icon font processing system 525 can be an application program that specifically implements the operations of the aforementioned steps in the embodiment of the present application. In short, when the technical solution provided in the present application is implemented by software or firmware, the relevant program code is stored in the memory 520 and is called and executed by the processor 510.

[0243] The input / output interface 513 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0244] The network interface 514 is used to connect to a communication module (not shown) to achieve communication interaction between the device and other devices. The communication module can achieve communication through a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WIFI, Bluetooth, etc.).

[0245] The bus 530 comprises a pathway for transmitting information between the various components of the device (eg, the processor 510 , the video display adapter 511 , the disk drive 512 , the input / output interface 513 , the network interface 514 , and the memory 520 ).

[0246] In addition, the electronic device 500 can also obtain information on specific collection conditions from the virtual resource object collection condition information database for use in condition judgment, etc.

[0247] It should be noted that, although the above device only shows a processor 510, a video display adapter 511, a disk drive 512, an input / output interface 513, a network interface 514, a memory 520, a bus 530, etc., in the specific implementation process, the device may also include other components necessary for normal execution. In addition, it can be understood by those skilled in the art that the above device may also only include components necessary for implementing the solution of the present application, and does not necessarily include all the components shown in the figure.

[0248] It can be seen from the description of the above implementation methods that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a disk, an optical disk, etc., including several instructions for enabling a computer device (which can be a personal computer, a cloud service end, or a network device, etc.) to execute the methods of various embodiments of the present application or certain parts of the embodiments. Embodiment 5

[0249] Corresponding to all the above embodiments, the embodiments of the present application further provide a computer-readable storage medium, characterized in that it stores a computer program, and the computer program enables a computer to perform the following operations:

[0250] In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem;

[0251] Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system;

[0252] In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk;

[0253] In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid state drive and that a specified field of the controller register is changed, the multi-core solid state drive is removed from the storage system.

[0254] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system or system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, in which the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0255] The above are only preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. An assertion processing method for a multi-core solid-state hard disk, applied in a storage system, characterized in that: The method comprises: In response to detecting that there are one or more abnormal CPUs in the multi-core solid-state drive, selecting an execution CPU in the multi-core solid-state drive according to a preset selection rule, and changing a specified field of a controller register provided by the multi-core solid-state drive for interacting with a device driver layer in a storage system, wherein the abnormal CPU is a CPU having an assertion problem; Triggering the execution CPU to process the abnormal I / O command currently being processed by the abnormal CPU and feeding back the processed abnormal I / O command to the upper-layer read-write device in the storage system; In response to an upper-layer read / write device receiving an abnormal I / O command, triggering the device driver layer to stop sending I / O commands to the multi-core solid-state hard disk; In response to detecting that the device driver layer stops sending I / O commands to the multi-core solid-state drive and that a specified field of the controller register is changed, removing the multi-core solid-state drive from the storage system; The method comprises: In response to detecting that there are one or more abnormal CPUs in the multi-core solid state drive, changing an assertion flag pre-stored in the multi-core solid state drive to 1; In response to detecting that the assertion flag is 1, notifying normal CPUs other than the abnormal CPU in the multi-core solid-state drive to execute a fault mode, so as to ensure that the normal CPUs feed back the currently received I / O commands to be processed to the upper-layer read-write device; The normal CPU executes the fault mode to ensure that the normal CPU feeds back the currently received I / O command to be processed to the upper-layer read-write device, including: The normal CPU performs loopback processing on the I / O command to be processed in the front-end module; The normal CPU changes the status code of the pending I / O command to an error state and feeds back the pending I / O command with the status code changed to the error state to the upper-layer read-write device.

2. The method according to claim 1, characterized in that The step of selecting an execution CPU from the multi-core solid state drive according to a preset selection rule includes: Obtaining resource occupancy rates of each normal CPU in the multi-core solid-state hard disk except the abnormal CPU; Compare the minimum resource occupancy rate among the resource occupancy rates corresponding to the normal CPUs with a first preset threshold; If the minimum resource occupancy rate is less than or equal to the first preset threshold, a normal CPU corresponding to the minimum resource occupancy rate is selected as the execution CPU.

3. The method according to claim 2, characterized in that The step of selecting an execution CPU from the multi-core solid state drive according to a preset selection rule also includes: If the minimum resource occupancy rate is greater than the first preset threshold, obtaining a virtual address of the abnormal CPU in the multi-core solid-state hard disk; Acquire two adjacent CPUs corresponding to virtual addresses adjacent to the virtual address corresponding to the abnormal CPU; Determining whether there is the abnormal CPU in the two adjacent CPUs; If the abnormal CPU does not exist in the adjacent CPUs, any one of the adjacent CPUs is selected as the execution CPU; If there is one abnormal CPU among the adjacent CPUs, another adjacent CPU other than the abnormal CPU among the adjacent CPUs is selected as the execution CPU; If the adjacent CPUs are all abnormal CPUs, a CPU is randomly selected from the multiple normal CPUs as the execution CPU.

4. The method according to claim 3, characterized in that The method further comprises: In response to the selection of the execution CPU, triggering the execution CPU to copy the exception context of the exception I / O command currently processed by the exception CPU; The execution CPU is triggered to feed back the exception context to the upper-layer read-write device, so as to analyze the assertion cause of the multi-core solid-state drive based on the exception context.

5. The method according to claim 4, characterized in that The method further comprises: In response to detecting that a specified field of the controller register has been changed, determining that a multi-core solid-state hard disk matched by the controller register in which the specified field has been changed is a faulty solid-state hard disk, wherein the controller register corresponds to the multi-core solid-state hard disk in a one-to-one manner; Detecting whether the storage system removes the faulty solid state drive within a first preset time period; If the storage system does not remove the multi-core solid-state hard disk within the first preset time period, the PCIe link between the device driver layer and the faulty multi-core solid-state hard disk is disconnected to achieve physical isolation of the faulty solid-state hard disk.

6. The method according to claim 5, characterized in that The detecting whether the storage system removes the faulty solid state drive within a first preset time period includes: Detecting whether there is a reset operation instruction within the first preset time period; If the reset operation instruction is detected within the first preset time period, determining that the storage system removes the faulty solid state drive within the first preset time period; If the reset operation instruction is detected within the first preset time period, it is determined that the storage system has not removed the faulty solid state drive within the first preset time period.

7. The method according to claim 6, characterized in that The method comprises detecting whether a specified field of the controller register has been changed: Triggering a status inspection mechanism to detect whether a specified field of the controller register corresponding to each of the multi-core solid state drives is changed, wherein the status inspection mechanism includes: Acquire the current value of the specified field of the controller register once every second preset time period; Comparing the obtained current value with an initial value corresponding to a specified field of the controller register; If the current value is inconsistent with the initial value, determining that a designated field of the controller register is changed; If the current value is consistent with the initial value, it is determined that the designated field of the controller register has not been changed.

8. The method according to claim 7, characterized in that The method further comprises: The status inspection mechanism is set in the device driver layer, and the device driver layer receives the inspection start instruction generated by the upper layer read / write device in response to receiving the abnormal I / O command, and triggers the status inspection mechanism; Alternatively, the status inspection mechanism is set in the upper-layer read / write device, and the upper-layer read / write device triggers the status inspection mechanism in response to a received abnormal I / O command.

9. The method according to claim 8, characterized in that After detecting that there are one or more abnormal CPUs in the multi-core solid-state hard disk, the method further includes: If no change in the specified field of the controller register is detected within a third preset time period, an assertion detection exception prompt is generated and fed back to the user to prompt the user to choose whether to remove the multi-core solid state drive; If the user chooses to remove the multi-core solid-state hard disk, the multi-core solid-state hard disk is forcibly removed from the storage system; Otherwise, the removal of the multi-core solid-state drive from the storage system is triggered according to the number of I / O commands received by the upper-layer read / write device and the corresponding response time.

10. The method according to claim 9, characterized in that The method of triggering the removal of the multi-core solid-state drive from the storage system according to the number of I / O commands received by the upper-layer read / write device and the corresponding response time includes: In response to the number of I / O commands with error status codes among the received I / O commands exceeding a second preset threshold, triggering removal of the multi-core solid-state drive from the storage system; And, in response to the number of I / O commands with response time timeouts among the received I / O commands exceeding the second preset threshold, triggering removal of the multi-core solid state drive from the storage system.

11. The method according to claim 10, characterized in that The method comprises: In response to detecting the presence of one or more abnormal CPUs in the multi-core solid-state drive, changing the value of a fatal status field in the controller register; In response to detecting a fatal status field change in the controller register, removing the failed solid state drive from the storage system.

12. The method according to claim 11, characterized in that In response to detecting that the assertion flag is 1, notifying normal CPUs other than the abnormal CPU in the multi-core solid-state drive to execute a fault mode to ensure that the normal CPU feeds back the currently received I / O command to be processed to the upper-layer read-write device, including: In response to detecting that the assertion flag is 1, generating an interrupt signal and sending it to the normal CPU; or, in response to detecting that the assertion flag is 1, generating an assertion message and sending it to the normal CPU; In response to the received interrupt signal or the assertion message, the normal CPU interrupts the processing of the currently received pending I / O command and executes the fault mode to ensure that the normal CPU feeds back the pending I / O command to the upper-level read / write device.

13. The method according to claim 12, characterized in that After the multi-core solid state drive is removed from the storage system, the method further includes: Generate a fault cause prompt based on the assertion cause obtained by the upper-layer read-write device analysis to prompt the user to repair the fault of the faulty solid-state hard disk; In response to detecting that the fault repair of the faulty solid state drive is complete, the faulty solid state drive is formatted and the faulty solid state drive after the fault repair is complete is reinstalled into the storage system.

14. The method according to any one of claims 1 to 13, characterized in that: The assertion flag is stored in a pre-set general register in the multi-core solid state drive in the form of a field; or, The assertion flag is stored in the form of bytes in a storage space pre-divided in the multi-core solid state drive.

15. The method according to claim 14, characterized in that The method includes detecting an abnormal CPU in a multi-core solid-state drive: Detecting whether a CPU execution assertion statement exists in a plurality of CPUs included in the multi-core solid state drive; If it is detected that there is a CPU execution assertion statement, it is determined that there is an abnormal CPU in the multi-core solid state drive; If no CPU execution assertion statement is detected, it is determined that no abnormal CPU exists in the multi-core solid state drive.

16. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 15 are implemented.

17. An electronic device, characterized in that: The electronic device comprises: one or more processors; And a memory associated with the one or more processors, the memory is used to store program instructions, and when the program instructions are read and executed by the one or more processors, the method according to any one of claims 1-15 is executed.

18. A computer-readable storage medium, characterized in that: The computer program stores a computer program, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 15.

Images