System task exception processing method and device

Abstract

The present disclosure provides a system task exception processing method and device, and relates to the technical field of computers. The method comprises the following steps: obtaining metadata state variables; wherein the state variables comprise a first state variable indicating whether a metadata repair process is being executed, and a second state variable indicating that a repair operation of the metadata repair process has been completed and verified; determining whether the metadata state variables meet a preset exception state condition; and executing a first decision if the metadata state variables meet the preset exception state condition. In this way, diversified decisions are made according to the combination of two state variables of metadata with internal logical association. Single state marking can be replaced to make more accurate and safe behavior decisions, so that normal background tasks can be avoided from being unnecessarily suspended, thereby improving the system's continuous service capability and system robustness.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and particularly relates to a system task exception processing method and device. BACKGROUND

[0002] In the related art, a centralized storage system has been widely applied as a system with high performance, strong consistency and simple management. In the centralized storage system, normal tasks and exception tasks usually need to be coordinated and processed. At present, a single state flag is usually used to coordinate normal tasks and exception processes. If the state flag is true, the processing flow is immediately interrupted and jumps to a unified error processing branch, and enters a waiting or suspended state, expecting that the system can be woken up after the fault repair process is completed. This method has a coarse granularity, and many normal background tasks are easily suspended unnecessarily, thereby reducing the continuous service capability of the system during the fault period. SUMMARY

[0003] The present disclosure provides a system task exception processing method and device. The main purpose is to solve the problem of poor continuous service capability of the system during the fault period.

[0004] According to a first aspect of the present disclosure, a system task exception processing method is provided, comprising:

[0005] obtaining a metadata state variable; wherein the state variable comprises a first state variable indicating whether a metadata repair process is in execution, and a second state variable indicating that a repair operation of the metadata repair process has been completed and verified successfully;

[0006] determining whether the metadata state variable meets a preset exception state condition; wherein the preset exception state condition comprises at least one of the first state variable indicating that the repair process is in progress, and the second state variable indicating that the repair operation is not completed or fails in verification;

[0007] in a case where the metadata state variable meets the preset exception state condition, performing a first decision.

[0008] According to a second aspect of the present disclosure, a system task exception processing device is provided, comprising:

[0009] an obtaining module configured to obtain a metadata state variable; wherein the state variable comprises a first state variable indicating whether a metadata repair process is in execution, and a second state variable indicating that a repair operation of the metadata repair process has been completed and verified successfully;

[0010] The determining module is configured to determine whether the metadata state variable meets a preset abnormal state condition, wherein the preset abnormal state condition comprises at least one of the first state variable indicating that the repair process is in progress, the second state variable indicating that the repair operation is not completed or verification fails.

[0011] The executing module is configured to execute the first decision if the metadata state variable meets the preset abnormal state condition.

[0012] According to a third aspect of the present disclosure, an electronic device is provided, comprising:

[0013] at least one processor; and

[0014] a memory connected with the at least one processor; wherein

[0015] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method of the first aspect.

[0016] According to a fourth aspect of the present disclosure, a non-transitory computer readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute the method of the first aspect.

[0017] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the method of the first aspect.

[0018] In the embodiments provided by the present disclosure, by obtaining metadata state variables, wherein the state variables comprise a first state variable indicating whether a metadata repair process is in execution, and a second state variable indicating that a repair operation of the metadata repair process has been completed and passed verification, it is determined whether the metadata state variables meet a preset abnormal state condition, wherein the preset abnormal state condition comprises at least one of the first state variable indicating that the repair process is in progress, the second state variable indicating that the repair operation is not completed or verification fails, and a first decision is executed if the metadata state variables meet the preset abnormal state condition. In this way, by two state variables of metadata having an internal logical association, diversified decisions are made according to the combination of the two state variables. In this way, a single state flag can be replaced, and more accurate and safe behavior decisions can be made, so that normal background tasks can be avoided from being unnecessarily suspended, and the system continuous service capability and system robustness can be improved.

[0019] It should be appreciated that the description set forth in this section is not intended to identify key or essential features of embodiments of the disclosure, and the scope of the disclosure is not to be limited to any of the features set forth in this section. Other features of the disclosure will be apparent from review of the disclosure, both hereinafter and in the drawings, which are not to be construed as limiting. BRIEF DESCRIPTION OF DRAWINGS

[0020] The accompanying drawings are included to provide a further understanding of the present application, and are incorporated in and constitute a part of this specification, illustrate embodiments of the present application, and together with the description serve to explain the principles of the present application. In the drawings:

[0021] Figure 1 A flowchart of a system task exception processing method provided by the related art;

[0022] Figure 2 A flowchart of a system task exception processing method provided by an embodiment of the present disclosure;

[0023] Figure 3 A flowchart of a metadata repair process method provided by an embodiment of the present disclosure;

[0024] Figure 4 A flowchart of a block space balancing task provided by an embodiment of the present disclosure;

[0025] Figure 5 A structural diagram of a system task exception processing apparatus provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0026] Exemplary embodiments of the present disclosure are described herein with reference to the accompanying drawings, which are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure, and together with the description serve to explain the principles of the present disclosure. It will be readily apparent to those skilled in the art that various embodiments of the present disclosure can be realized without departing from the scope of the present disclosure. Thus, the present disclosure should not be construed as being limited to the embodiments set forth in the following description. Embodiments of the present disclosure are described in sufficient detail to enable those skilled in the art to make and use it, and it is understood that the descriptions are given solely for understanding of the principles of the present disclosure, with reference made to the appended drawings.

[0027] As known from the background, centralized storage systems play a core role in enterprise critical business due to their high performance, strong consistency and easy management. In order to ensure high reliability of data and efficient use of storage space, a variety of background maintenance tasks (such as space balancing, snapshot, data reduction, etc.) and real-time high-priority fault recovery processes (such as metadata repair, RAID (Redundant Array of Independent Disks) reconstruction, etc.) are usually running inside the centralized storage system. These tasks and processes share the limited resources of the system (such as CPU (Central Processing Unit), memory, IO channel (Input / Output Channel)) and run concurrently in the same software stack.

[0028] In a centralized storage architecture, the coupling degree between various modules (such as a management module, a data module, and a metadata module) is usually very high. In this way, a typical problem can exist: when the system is performing a regular space balancing task to optimize disk space layout, a metadata page check error can be triggered due to a small defect in a disk medium or a memory error, and at this time, the system will immediately interrupt the current operation and jump to a high-priority metadata repair process. If the interruption processing of the normal task is not handled properly, the task can be stuck in some intermediate state and the resources (such as locks, memory buffers, and task slots) occupied by the task cannot be released. In this way, not only the task itself fails, but also other operations that depend on these tasks can be blocked, eventually leading to task timeout or entire system service crash, which requires manual intervention to recover, thereby possibly greatly affecting the continuity and reliability of the storage service.

[0029] In related technologies, a centralized storage system usually uses a single state flag (that is, a global interruption flag) bit to coordinate normal tasks and abnormal processes. For example, as shown in FIG. 1, when metadata corruption occurs, the system sets a global interruption flag metadata_corrupt_flag in global memory. The flag (global interruption flag) can be queried in a callback function or a critical checkpoint of a background task such as space balancing. Once the flag is found to be true, the task will immediately interrupt its own process and jump to a unified error processing branch and usually enter a waiting or suspended state, expecting to be awakened after the fault repair process is completed. Figure 1

[0030] This single-flag-based interruption mechanism in a centralized storage system at least has the following defects: (1) coarse-grained interruption and false positives: once the flag (global interruption flag) is set, its impact is global, and any background task that checks the flag before repair is completed, regardless of whether it is related to the fault point or whether it is in a safe interruption state, will be unconditionally interrupted, and this strategy usually causes many normal background tasks to be unnecessarily suspended, reducing the continuous service capability of the system during a fault. (2) weakened system self-healing capability: the interruption of normal tasks and the inability to release resources can cause the performance of the system to drop sharply during a fault, and after the completion of the high-priority repair process, the system cannot quickly and automatically recover all background services, requiring a longer recovery time or even restarting the service.

[0031] ​Based on this, embodiments of this disclosure provide a system task exception handling method. This method introduces two state variables of metadata with inherent logical correlation, enabling diversified decision-making based on the combination of these two state variables. This replaces a single state flag, allowing for more refined and secure behavioral decisions. Consequently, it avoids unnecessary suspension of normal background tasks, thereby improving the system's continuous service capability and robustness.

[0032] The system task exception handling method and device of this disclosure are described below with reference to the accompanying drawings.

[0033] Figure 2 This is a flowchart illustrating a system task exception handling method provided in an embodiment of this disclosure. Figure 2 As shown, the system task exception handling method includes the following steps:

[0034] Step 201: Obtain metadata status variables.

[0035] The status variables include a first status variable that indicates whether the metadata repair process is in progress, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified.

[0036] When handling system task exceptions, it's necessary to obtain metadata status variables. For example, this could involve obtaining a first status variable indicating whether the metadata repair process is in progress, and a second status variable indicating that the repair operation has been completed and verified. These two status variables can be set to false when the repair process starts and only set to true after the repair operation has been successfully executed and verified. For instance, when the metadata repair process begins, the first status variable is set to true; when the repair process ends, the first status variable is set to false; when the repair operation is completed and verified, the second status variable is set to true; otherwise, the second status variable remains false. As an example, the current metadata status variables can be obtained by setting an interface function (e.g., GetMetadataStatusVariables()).

[0037] Step 202: Determine whether the metadata status variables meet the preset abnormal status conditions.

[0038] The preset abnormal state conditions include at least one of the following: a first state variable indicating that the repair process is in progress, and a second state variable indicating that the repair operation is not completed or the verification has failed.

[0039] The preset abnormal state condition can be self-defined according to actual needs, for example, the preset abnormal state condition can be set by setting the variable values of the first state variable and the second state variable as true or false. Correspondingly, after obtaining the metadata state variable, it can be determined whether the metadata state variable meets the preset abnormal state condition, for example, whether the first state variable indicates that the repair process is in progress, whether the second state variable indicates that the repair operation is not completed or fails, and whether the metadata state variable meets the preset abnormal state condition by determining the variable values of the first state variable and the second state variable.

[0040] As an example, the preset abnormal state condition can include that the first state variable indicates that the repair process is in progress, for example, the first state variable=true, and whether the second state variable indicates that the repair operation is not completed or fails, for example, the second state variable=false. When determining whether the metadata state variable meets the preset abnormal state condition, it can include determining whether the first state variable indicates that the repair process is in progress, and determining whether the second state variable indicates that the repair operation is not completed or fails. It can be understood that in order to determine whether the metadata state variable meets the preset abnormal state condition, a logical judgment function can be designed, which can determine whether the metadata state variable meets the abnormal state condition according to the values of the first state variable and the second state variable. As a specific example, the logical judgment function can be defined as: the function receives two Boolean value parameters: the first state variable value and the second state variable value. The function returns a Boolean value indicating whether the abnormal state condition is met. The logical judgment logic can be: if the first state variable is true, it indicates that the repair process is in progress, which meets the abnormal state condition; if the second state variable is false, it indicates that the repair operation is not completed or fails, which meets the abnormal state condition. If neither condition is met, it indicates that the state variable does not meet the abnormal state condition. In this way, by defining the metadata state variable and the abnormal state condition, and designing a logical judgment function, it can be effectively determined whether the metadata state variable meets the preset abnormal state condition, so as to timely detect the abnormal condition of the metadata, provide a basis for subsequent decision-making, and thus improve the stability and reliability of the system.

[0041] Step 203, in the case where the metadata state variable meets the preset abnormal state condition, performing a first decision.

[0042] The first decision can be a predefined decision, and its specific content can be set according to actual needs, for example, can be set as a task exit operation. If the metadata state variable meets the preset abnormal state condition, that is, the variable values of the first state variable and the second state variable meet the preset abnormal state condition, the first decision can be executed. For example, the first decision can include suspending or terminating the related data operation to prevent the abnormal state from further affecting the normal operation of the system, or can also include recording the abnormal state information in a log file for subsequent analysis and troubleshooting, and sending an alarm notification to the system administrator to remind him to pay attention to the abnormal situation of the metadata.

[0043] In the embodiments provided in the present disclosure, a metadata state variable is obtained; wherein the state variable includes a first state variable indicating whether a metadata repair process is in execution, and a second state variable indicating that a repair operation of the metadata repair process has been completed and passed verification; it is determined whether the metadata state variable meets a preset abnormal state condition, and the preset abnormal state condition includes at least one of the first state variable indicating that the repair process is in progress, and the second state variable indicating that the repair operation is not completed or verification fails; in the case where the metadata state variable meets the preset abnormal state condition, a first decision is executed. In this way, through two state variables of metadata with internal logical association, diversified decisions are made according to the combination of the double state variables. In this way, a single state flag can be replaced, and more delicate and safe behavior decisions can be made, so that unnecessary suspension of normal background tasks can be avoided, and the system continuous service capability and system robustness can be improved.

[0044] In some possible implementations, in the case where the metadata state variable meets the preset abnormal state condition, the first decision is executed, including:

[0045] In the case where the first state variable indicates that the repair process is in progress, and the second state variable indicates that the repair operation is not completed or verification fails, a task exit operation is executed.

[0046] The task exit operation includes releasing at least one of all locks, memory buffers, and system resources currently held by the current task.

[0047] If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation is not completed or the verification fails, it can be determined that the metadata state variable meets the preset abnormal state condition. At this time, the first decision can be executed, such as releasing all locks, memory buffers, system resources currently held by the current task. In this way, by defining the metadata state variable and the abnormal state condition, and executing the first decision when the condition is met, the abnormal situation in the metadata repair process can be effectively handled, so that the abnormality can be found and handled in time, further errors or data damage can be prevented, and the stability and reliability of the system can be improved.

[0048] In some possible embodiments, after determining whether the metadata state variable meets the preset abnormal state condition, the method further includes:

[0049] In the case that the metadata state variable does not meet the preset abnormal state condition, a second decision is executed; wherein the second decision includes continuing to execute the current task.

[0050] In the case that the metadata state variable does not meet the preset abnormal state condition, executing the second decision includes:

[0051] In the case that the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation verification passes, the second decision is executed.

[0052] In the case that the metadata state variable does not meet the preset abnormal state condition, executing the second decision further includes:

[0053] In the case that the first state variable indicates that there is no repair process in progress, the second decision is executed.

[0054] If the metadata does not satisfy the preset abnormal state condition, for example, the first state variable indicates that the repair process is in progress, and the second state variable indicates that the repair operation verification is passed, that is, the combined state of the metadata state variable indicates that the core operation of the metadata repair has been successfully completed, and the system state has returned to stable; or, the first state variable indicates that there is no repair process in progress, that is, the metadata state variable indicates that the system is completely normal and no metadata failure has occurred. At this time, the second decision can be executed, for example, it is determined that the current environment is safe, and the background task continues its normal execution process without any interruption or intervention. As an example, the logic for continuing to execute the current task can be defined as: continuing to execute the current metadata repair task, ensuring that the task proceeds normally until completion or a new abnormality is encountered. After determining that the metadata state variable does not satisfy the abnormal state condition, the above logic is called to continue executing the current task. In this way, by defining the metadata state variable and the abnormal state condition, and executing the continue to execute the current task when the abnormal state condition is not satisfied, the normal progress of the metadata repair process can be ensured, so that the task execution in the normal state can be effectively handled, and at the same time, measures can be taken in time when an abnormality is detected, further improving the stability and reliability of the system.

[0055] In some possible embodiments, the metadata state variable is obtained, including:

[0056] In the case where the task execution needs to make a process selection decision, the metadata state variable is obtained.

[0057] In this context, considering the potential for multiple checkpoints or decision points during task execution—critical locations in the task flow where the next step needs to be determined based on the current state variables—the following steps are crucial: For example, a task might need to check the repair process halfway through execution to ensure its proper functioning, or it might need to decide whether to continue to the next stage after completing a certain phase. At these checkpoints or decision points, the current metadata state variable values ​​can be retrieved, i.e., the first and second state variables, to determine subsequent processing. As an example, during task execution, situations may arise where the next step needs to be determined based on the current state variable value. These situations typically include, but are not limited to: the task reaching a checkpoint requiring confirmation of the repair process's progress; the task reaching a decision point requiring selection of different execution paths based on the current repair status; and the task reaching an exception handling point requiring confirmation of whether the current repair status meets exception conditions. When a task reaches a point requiring a process selection decision, metadata status variables can be retrieved, and it can be determined whether these variables meet preset abnormal state conditions. If the metadata status variables meet the preset abnormal state conditions, the first decision (task exit operation) is executed; and if the metadata status variables do not meet the preset abnormal state conditions, the second decision (continue execution of the current task) is executed. Thus, by retrieving metadata status variables when the task reaches a point requiring a process selection decision, it is possible to better ensure that the task can make reasonable decisions based on its current recovery status, effectively handle various situations during task execution, and further improve the stability and reliability of the system.

[0058] In some possible implementations, after executing the first decision when the metadata state variable meets the preset abnormal state condition, the following steps are also included:

[0059] The current task has entered a delayed retry state; the delayed retry state includes exiting the execution queue and retrying execution after a preset time.

[0060] In this system, after executing the first decision (i.e., exiting the task), the current task can be removed from the execution queue to prevent it from continuing. A preset delay time (e.g., 5 minutes) can also be set. After the delay expires, the task is added back to the execution queue for a second attempt. This delayed retry state after the first decision not only allows for timely detection and handling of anomalies but also enables retrying the task at an appropriate time, further improving system stability and reliability.

[0061] In a further possible implementation, after the current task enters the delayed retry state, the following is also included:

[0062] obtaining a priority of the current task;

[0063] adjusting the preset time length based on the priority of the current task.

[0064] After the task exits the execution queue, the retry time length can be adjusted according to the priority of the task, that is, the preset time length is dynamically adjusted. For example, the priority of the current task can be obtained. If the priority of the current task is high, for example, higher than the preset priority, the preset time length can be shortened, for example, adjusted by a set step; on the contrary, if the priority of the current task is low, for example, lower than the preset priority, the preset time length can be increased. The specific setting of the priority can be set according to the actual situation, and the specific value of the adjustment step of the preset time length can also be set according to the actual needs.

[0065] In a further possible implementation, after the current task enters the delayed retry state, further comprising:

[0066] obtaining historical retry data of the current task within a preset time period; wherein the historical retry data includes the number of retries and the preset time length;

[0067] adjusting the retry strategy when the number of retries is greater than a preset threshold; wherein the adjustment of the retry strategy includes at least one of the following:

[0068] adjusting the retry method of the current task;

[0069] adjusting the preset time length.

[0070] Wherein, after the task exits the execution queue, the retry strategy can be intelligently adjusted according to the historical retry data of the current task. For example, the number of retries of the current task within a preset period of time and the preset duration (i.e., the retry duration) can be obtained. The preset period of time can be a set period of time before the current time from the current time. After obtaining the number of retries of the current task within the preset period of time and the preset duration, the retry strategy of the current task can be adjusted based on the number of retries and the preset duration, such as adjusting the retry method and the retry duration (i.e., the preset duration). For example, if the number of retry failures of the current task within the preset period of time is greater than a set number of times, the number of retries can be automatically reduced, the retry interval time can be increased, i.e., the preset duration can be increased, to avoid excessive pressure on the system caused by frequent failures; and the retry method can also be adjusted, such as adjusting the retry method according to the priority of the current task, the system load data, and the number of retry failures. For example, if the system load data shows that the current load is low, the priority of the current task is high, and the number of retry failures is less than a set number of times, a linear retry method can be used, i.e., a fixed time interval retry method; on the contrary, if the system load data shows that the current load is high, the priority of the current task is low, and the number of retries is greater than the set number of times, an exponential retry method can be used, i.e., a retry method with exponentially increasing retry interval duration. In this way, by selecting an appropriate retry strategy according to the specific scenario, the stability of the system and the recovery success rate of the task can be improved.

[0071] To make the system task exception handling method provided by the embodiments of the present disclosure clearer, the following examples are combined for illustration. The system task exception handling method provided by the embodiments of the present disclosure can include the following steps:

[0072] 1. Obtain metadata state variables:

[0073] In the case of task execution to the flow selection decision, obtain metadata state variables, including:

[0074] First state variable: used to identify whether the metadata repair process is in execution.

[0075] Second state variable: used to identify that the repair operation of the metadata repair process has been completed and verified.

[0076] 2. Determine whether the metadata state variables meet the preset exception state condition:

[0077] Check whether the first state variable indicates that the repair process is in progress;

[0078] Check whether the second state variable indicates that the repair operation is not completed or fails verification.

[0079] If both conditions are met, the metadata state variables meet the preset exception state condition.

[0080] 3. Perform the first decision:

[0081] If the metadata state variable meets the preset abnormal state condition, perform a task exit operation, for example, including recording abnormal state information into a log file, sending an alarm notification to a system administrator, terminating a current repair task, etc.

[0082] And can enter a delayed retry state: remove the current task from the execution queue; after a preset time length, reattempt execution, for example, set a preset delay time (such as 5 minutes) (the preset time length), after the delay time ends, re-add the task to the execution queue, and attempt execution again.

[0083] 4. Perform the second decision:

[0084] If the metadata state variable does not meet the preset abnormal state condition, check whether the first state variable indicates that the repair process is in progress, and check whether the second state variable indicates that the repair operation has been completed and verified. If the first state variable indicates that the repair process is in progress, and the second state variable indicates that the repair operation verification is passed, continue to execute the current task. Or, in the case that the first state variable indicates that there is no repair process in progress, continue to execute the current task.

[0085] To make the system task exception handling method provided by the embodiments of the present disclosure clearer, the following describes the embodiments of the present disclosure with reference to the examples of Figure 3 and Figure 4 In combination with Figure 3 and Figure 4 , the system task exception handling method provided by the embodiments of the present disclosure can include the following processing:

[0086] 1. Define a double state variable, that is, a metadata state variable, which can specifically include:

[0087] Define two state variables (that is, metadata state variables) in the system global memory: variable A (wait_bm) (that is, the first state variable): indicating whether the metadata repair process has been formally started and is in execution; variable B (finish_bm) (that is, the second state variable): indicating whether the core repair operation in the metadata repair process has been completed and verified, which is false at the start of the repair process, and is set to true only after the repair operation is successfully executed and verified.

[0088] 2. Modify the judgment logic in the task callback function, which can be specifically as follows:

[0089] The callback function or the processing logic of the key decision point of the block space balancing task is modified as follows: first, when the task executes to the decision point where the flow selection needs to be made, the system synchronously queries the current values of the first state variable and the second state variable. Then, according to different combinations of the values of the two state variables, different decision paths are executed, specifically including:

[0090] First, when the first state variable indicates that the repair flow is in progress, and the second state variable indicates that the verification has not passed: this combination of states indicates that the system is in a critical and most unstable period of repair operation. At this time, the system will control the background task to immediately execute a series of safe exit operations. These operations include but are not limited to: releasing all locks, memory buffers and other critical system resources currently held by the task. Then, the task itself enters a delayed retry state, that is, actively exits the execution queue and schedules to retry execution after a predetermined time. The core purpose of this path is to actively release resource occupation, and completely avoid resource competition or circular waiting with high-priority repair flow.

[0091] Second, when the first state variable indicates that the repair flow is in progress, and the second state variable indicates that the verification has passed: this combination of states indicates that the core operation of metadata repair has been successfully completed, and the system state has returned to stable. At this time, the system will determine that the current environment is safe, and control the background task to continue its normal execution flow without any interruption or intervention.

[0092] Third, when the first state variable indicates that there is no repair flow in progress: this state indicates that the system is completely normal and no metadata failure has occurred. At this time, the system also controls the background task to continue its normal execution flow.

[0093] 3. In the code of the metadata repair flow, the two state variables need to be accurately updated at the key nodes, which can be as follows:

[0094] At the beginning of the flow, wait_bm = TRUE and finish_bm = FALSE can be set. After the core repair operation of the flow is completed and verified, finish_bm = TRUE can be set. When the entire flow is completely finished, wait_bm = FALSE can be reset. Through the above implementation, the system can clearly distinguish between the two states of "repairing-unstable" and "repair completed-stable", so that the background task can make completely different but correct decisions, and deadlocks are fundamentally avoided.

[0095] Based on this, the system task exception processing method provided by the embodiments of the present disclosure can maintain two metadata state variables (i.e., a first state variable indicating whether the metadata repair process is in execution, and a second state variable indicating whether the repair operation of the metadata repair process has been completed and verified), respectively indicating whether the fault repair process is in progress and whether the core operation thereof has been completed and verified; when the background task executes to a decision point, the current values of the two metadata state variables can be queried synchronously; according to the combination result of the values of the two metadata state variables, the background task is controlled to execute different operation decision branches (e.g., a first decision and a second decision); if the repair process is in progress but the verification fails, the background task can be controlled to release all occupied resources immediately, and can enter a delayed retry state; if the repair process is in progress and the verification has passed, the background task can be controlled to continue normal execution of the process; and in different execution stages of the fault repair process, the variable values of the two metadata state variables can be updated.

[0096] In this way, a simple state machine model can be constructed by using two metadata state variables (i.e., a first state variable indicating whether the metadata repair process is in execution, and a second state variable indicating whether the repair operation of the metadata repair process has been completed and verified) having an internal logical association, instead of a single Boolean flag, to achieve stage division of the repair process and fine management of the system exception state, so that clear and safe decision basis can be provided for complex process collaboration inside the centralized system; diversified decisions (e.g., including continue execution, release resources and exit, delayed retry, etc.) can be made according to the combination of the two metadata state variables (instead of true or false of a single state flag), to achieve fine control of the decision logic; and in addition, resources can be actively forced to release in the most critical unstable period of the system, so that the generation of a circular wait condition is prevented by design, and thus the deadlock problem caused by tight coupling of the centralized system is solved.

[0097] It should be noted that the embodiments of the present disclosure can include multiple steps, which are numbered for the convenience of description, but these numbers are not a limitation on the execution time slots and execution order of the steps; the steps can be implemented in any order, and the embodiments of the present disclosure do not limit this.

[0098] From the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software and a necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation.

[0099] According to the embodiments of the present disclosure, the present disclosure further provides a system task exception processing apparatus.

[0100] Exemplarily,Figure 5 This is a schematic diagram of a system task exception handling device provided in an embodiment of the present disclosure. The system task exception handling device 500 includes:

[0101] The acquisition module 510 is used to acquire metadata status variables; wherein, the status variables include a first status variable that indicates whether the metadata repair process is being executed, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified.

[0102] The determination module 520 is used to determine whether the metadata status variables meet the preset abnormal status conditions; wherein, the preset abnormal status conditions include at least one of the following: the first status variable indicates that the repair process is in progress, and the second status variable indicates that the repair operation is not completed or the verification has failed;

[0103] The execution module 530 is used to execute the first decision when the metadata state variables meet the preset abnormal state conditions.

[0104] Furthermore, execution module 530 is used for:

[0105] If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has not been completed or the verification has failed, a task exit operation is performed; wherein, the task exit operation includes releasing at least one of all locks, memory buffers, and system resources currently held by the current task.

[0106] Furthermore, execution module 530 is also used for:

[0107] If the metadata state variables do not meet the preset abnormal state conditions, a second decision is executed; the second decision includes continuing to execute the current task.

[0108] Furthermore, execution module 530 is used for:

[0109] If the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has been verified, then the second decision is executed.

[0110] Furthermore, execution module 530 is used for:

[0111] If the first state variable indicates that there is no ongoing repair process, then execute the second decision.

[0112] Furthermore, module 510 is used for:

[0113] When the task execution reaches the point where a process selection decision needs to be made, the metadata status variables are obtained.

[0114] Furthermore, it also includes a retry module for:

[0115] The current task enters a delay retry state; wherein the delay retry state comprises exiting the execution queue and reattempting execution after a preset time length.

[0116] Further, the adjustment module is further configured to:

[0117] obtain a priority of the current task;

[0118] adjust the preset time length based on the priority of the current task.

[0119] Further, the adjustment module is further configured to:

[0120] obtain historical retry data of the current task within a preset time period; wherein the historical retry data comprises a retry number and the preset time length;

[0121] adjust a retry strategy in a case where the retry number is greater than a preset threshold; wherein the adjustment of the retry strategy comprises at least one of the following:

[0122] adjusting a retry method of the current task;

[0123] adjusting the preset time length.

[0124] It should be noted that the features of the embodiments corresponding to the device can be referred to the related descriptions of the embodiments corresponding to the method, which will not be repeated here.

[0125] Embodiments of the present disclosure further provide an electronic device, comprising a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments.

[0126] Embodiments of the present disclosure further provide a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0127] In an example embodiment, the above computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0128] Embodiments of the present disclosure further provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps in any of the above method embodiments.

[0129] Embodiments of the present disclosure further provide another computer program product comprising a non-transitory computer readable medium storing a computer program, the computer program being executed by a processor to implement the steps in any of the above method embodiments.

[0130] Those skilled in the art will further appreciate that the units and algorithm steps of the examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or both, and that the implementation decisions are within the skill of an informed technician. The exemplary configurations and steps have been described in the foregoing specification in connection with the described examples for the purpose of clarity. One skilled in the art will recognize that the steps of the examples can be carried out in a different order, or using different configurations, and still achieve desirable results. One skilled in the art will also recognize that the steps of the examples can be implemented in a computer software instructions, a set of VLSI chips, or a combination of both. The application is not limited to the details given in the foregoing description.

[0131] The above has carried out the detailed introduction to the system task exception processing method provided by the present disclosure. The principle and implementation mode of the present disclosure are described by applying specific examples in the present disclosure. The above embodiment description is only for helping to understand the method of the present disclosure and its core idea. It should be pointed out that, for the ordinary skilled in the art, under the premise of not departing from the principle of the present disclosure, the present disclosure can be improved and modified in several ways. These improvements and modifications also fall within the protection scope of the claims of the present disclosure.

Claims

1. A method for handling system task exceptions, characterized in that, include: Obtain metadata status variables; among which, the status variables include a first status variable that indicates whether the metadata repair process is in progress, and a second status variable that indicates that the repair operation of the metadata repair process has been completed and verified. Determine whether the metadata status variable meets the preset abnormal status conditions; wherein, the preset abnormal status conditions include the first status variable indicating that the repair process is in progress, and the second status variable indicating that the repair operation has not been completed or the verification has failed; If the metadata state variable satisfies the preset abnormal state condition, a first decision is executed, which includes: performing a task exit operation.

2. The method according to claim 1, characterized in that, The task exit operation includes releasing at least one of the following: all locks currently held by the current task, memory buffers, and system resources.

3. The method according to claim 1, characterized in that, After determining whether the metadata state variable meets the preset abnormal state conditions, the method further includes: If the metadata state variable does not meet the preset abnormal state condition, a second decision is executed; wherein, the second decision includes continuing to execute the current task.

4. The method according to claim 3, characterized in that, When the metadata state variable does not meet the preset abnormal state condition, the second decision is executed, including: The second decision is executed when the first state variable indicates that the repair process is in progress and the second state variable indicates that the repair operation has been verified.

5. The method according to claim 3, characterized in that, When the metadata state variable does not meet the preset abnormal state condition, the second decision is executed, including: If the first state variable indicates that there is no ongoing repair process, the second decision is executed.

6. The method according to claim 1, characterized in that, The acquisition of metadata status variables includes: When the task execution reaches the point where a process selection decision needs to be made, the metadata status variables are obtained.

7. The method according to claim 1 or 2, characterized in that, After executing the first decision when the metadata state variable satisfies the preset abnormal state condition, the process further includes: The current task has entered a delayed retry state; wherein, the delayed retry state includes exiting the execution queue and retrying execution after a preset time.

8. The method according to claim 7, characterized in that, After the current task enters the delayed retry state, it also includes: Obtain the priority of the current task; The preset duration is adjusted based on the priority of the current task.

9. The method according to claim 7, characterized in that, After the current task enters the delayed retry state, it also includes: Obtain historical retry data of the current task within a preset time period; wherein, the historical retry data includes the number of retries and the preset duration; If the number of retries exceeds a preset threshold, the retry strategy is adjusted; wherein, the adjusted retry strategy includes at least one of the following: Adjust the retry method for the current task; Adjust the preset duration.

10. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-9.

Images