Log storage method and device, electronic equipment, storage medium and product

Abstract

The application discloses a log storage method and device, electronic equipment, storage medium and product, and relates to the technical field of log management, and comprises the following steps: in the case that a target storage controller is in a normal operating state and an interrupt request instruction sent by a target small core is received, the interrupt request instruction is added to a task queue; in the case that the interrupt request instruction is in a scheduled processing state, a first release lock instruction is sent to the target small core, so that, after the target small core releases an access lock of a full log interval based on the first release lock instruction, full log interval bitmap information of the target small core is determined, first to-be-stored log data is determined, and the first to-be-stored log data is stored in a first storage area, thereby solving the problem that, in a multi-core architecture of a solid state disk, due to limited storage space of a small core, logs are difficult to be stored in real time and are prone to loss, and through a cooperative mechanism of interval partitioning-bitmap interrupt asynchronous storage-hardware forced release lock, the small core logs are stored in real time without blocking under the premise that the small core memory does not need to be expanded.

Description

Technical Field

[0001] This invention relates to the field of log management technology, and in particular to log storage methods, devices, electronic devices, storage media and products. Background Technology

[0002] With the rapid development of flash memory technology, SSDs (Solid State Drives) have become mainstream storage devices. Currently, SSD controllers generally adopt multi-core heterogeneous architectures to effectively improve concurrent processing capabilities. Among these, log recording is a key means for SSD development, debugging, and on-site problem localization and analysis. However, if the related technical solutions expand the small core RAM (Random Access Memory), it will lead to increased costs. If the large core is used to periodically poll the small core log area, it will result in poor real-time performance and no protection against abnormal scenarios. These issues urgently need to be addressed. Summary of the Invention

[0003] This invention provides a log saving method, apparatus, electronic device, storage medium, and product to at least solve the problem in related technologies that logs are difficult to save in real time and are easily lost due to the limited storage space of small cores in multi-core solid-state drive architectures.

[0004] This invention provides a log storage method, comprising: determining the current operating state of a target storage controller; in response to the current operating state being a normal operating state, adding the interrupt request instruction to a task queue upon receiving an interrupt request instruction sent by a target small core; in response to the interrupt request instruction being in a scheduled processing state, sending a first release lock instruction to the target small core, so as to determine the full log interval bitmap information of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction; and determining a first log data to be stored based on the full log interval bitmap information, and storing the first log data to be stored in a first storage area.

[0005] The present invention also provides a log storage device, comprising: The first determining module is used to determine the current operating status of the target storage controller; The receiving module is configured to, in response to the current running state being a normal running state, add the interrupt request instruction sent by the target small core to the task queue. The second determining module is used to send a first release lock instruction to the target small core in response to the interrupt request instruction being in a scheduled processing state, so as to determine the full log interval bitmap information of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction; The first storage module is used to determine the first log data to be stored based on the bitmap information of the full log interval, and to store the first log data to be stored in the first storage area.

[0006] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described log saving methods.

[0007] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described log saving methods.

[0008] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described log saving methods.

[0009] This invention addresses the problem of logs being difficult to save in real time and easily lost due to limited storage space in small cores in multi-core SSD architectures. By employing a collaborative mechanism of interval partitioning, bitmap interrupt asynchronous saving, and hardware-forced lock release, logs can be saved in real time without expanding the small core's memory. Attached Figure Description

[0010] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic flowchart of a log saving method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the log saving process during normal operation of a storage controller according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the log saving process during an abnormal power-down according to an embodiment of the present invention. Figure 4 This is a flowchart illustrating the log saving process during a large-core core dump according to an embodiment of the present invention. Figure 5 This is a flowchart illustrating the log saving process during a small core dump according to an embodiment of the present invention. Figure 6 This is a block diagram of a log storage device according to an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0013] It should be noted that, in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] Specifically, before introducing the embodiments of the present invention, we will first introduce the background technology of the present invention and the technical defects existing in the related technologies.

[0016] With the rapid development of flash memory technology, SSDs have become the mainstream storage devices. Currently, SSD controllers generally adopt a multi-core heterogeneous architecture: multiple high-performance large cores are responsible for FTL mapping table management, host command processing, and front-end processes; multiple dedicated small cores (Core-NFC (NAND Flash Controller Core, NAND (Not-And-Not-D (NAND) Flash Memory) flash memory controller core)) each manage one NFC, which is dedicated to handling back-end NAND operations, such as read, write, erase, status query, etc., thereby improving concurrent processing capabilities.

[0017] Log recording is a crucial tool for SSD firmware development, debugging, and on-site problem localization and analysis. However, due to their specialized nature, small cores have extremely limited internal RAM space (typically only tens of KB), making it impossible to allocate a dedicated, large-capacity log buffer like large cores. If small cores use a traditional circular log buffer, its depth is insufficient, making it highly susceptible to log overwriting under high-frequency NAND operations, leading to the loss of critical information. Furthermore, the small and large cores operate independently, lacking an efficient log upload mechanism. Small core logs are difficult to save to persistent storage (such as DRAM (Dynamic Random Access Memory)) or NAND in real time. More problematic is that in cases of abnormal power loss or core dumps, unsaved logs in the small core's RAM will be completely lost, severely impacting problem reproduction and root cause analysis.

[0018] In related technologies, the problem is mainly alleviated by expanding the RAM of small cores and using large cores to periodically poll the log area of ​​small cores. However, the above solutions have problems such as increased chip cost, poor real-time performance, and interrupt conflicts. At the same time, they lack a systematic full-data saving design for abnormal power failure and CoreDump scenarios.

[0019] Therefore, based on the aforementioned technical problems, this invention provides a low-cost, highly reliable method for saving small core logs, ensuring that small core logs can be securely saved to DRAM in all scenarios, including normal system operation, abnormal power-off, and Core Dump, thereby solving the problems of logs being difficult to save in real time, easily lost, and unable to be uploaded in real time in SSD multi-core architectures due to the limited storage space of small cores.

[0020] The embodiments of the present invention provide a log saving method, and the method is described in detail in conjunction with the execution flow of the log saving method.

[0021] Specifically, Figure 1 This is a flowchart illustrating a log saving method provided in an embodiment of the present invention; like Figure 1 As shown, the log saving method includes the following steps: In step S101, the current operating state of the target storage controller is determined.

[0022] The target storage controller is a multi-core storage control chip with a large core (log management core) and at least one small core (log working core), such as an SSD controller; the current operating state is the overall operating state of the target storage controller at the current moment, including normal operating state (e.g., normal system power supply, normal operation of each core) and abnormal operating state (e.g., abnormal power-off, large core fault dump, small core fault dump, etc.).

[0023] Specifically, firstly, the system hardware structure and log RAM organization of the SSD controller of this invention are introduced. The system hardware structure mainly includes a target large core, multiple target small cores, and an inter-core interrupt register. Each target small core has an independent shared log RAM area, and the log RAM areas of each target small core are independent and do not interfere with each other. A dedicated large core (denoted as Core-0) is designated in the target large core to access the log RAM areas of all target small cores. An inter-core interrupt register is set between the target large core and the target small cores to realize bidirectional interrupt communication between the target large core and each target small core. The target large core can notify the designated small core of the interrupt through the interrupt register (REG_CORE0_INFO_CORE_NFCx). Each target small core can trigger an interrupt through its own interrupt register (REG_CORE_NFCx_INFO_CORE0 (specifying the interrupt register that the small core notifies the large core)). Each target small core can also trigger an interrupt through its own interrupt register (REG_CORE_NFCx_INFO_CORE0 (specifying the interrupt register that the small core notifies the large core)). Each target small core's log RAM area is equipped with an atomic lock, allowing only one core to access the log RAM area at a time to ensure data consistency. In addition, the atomic lock can be used to forcibly clear the log data in the log RAM area through the hardware register (REG_LOCK_FORCE_RELEASE_NFCx (forcibly releasing the specified small core's log RAM lock register)). This forced clearing mechanism is only used in special abnormal scenarios (such as when the small core itself fails and cannot actively release the lock during a fault dump).

[0024] Furthermore, the log RAM organization of the present invention includes: dividing the log RAM area of ​​each small core into N fixed-size log intervals, and maintaining metadata such as the status of each log interval, the current write interval index, and the write offset within the interval. Each log interval has a status identifier, including a writing status (i.e., WRITE, indicating that the interval is being written), a full status (i.e., FULL, indicating that the interval is full and ready to be saved), and an idle status (i.e., FREE, indicating that the interval has been saved and can be reused). The current write interval index identifies the log interval currently being written to, and the write offset within the interval identifies the write position within the current write interval.

[0025] Furthermore, in the process of saving logs through small cores, the current operating state of the target storage controller mainly includes four scenarios: non-blocking log upload during normal operation, emergency full save during abnormal power failure, complete image save during large core CoreDump (fault dump), and complete image save during small core CoreDump. The log saving process under each operating scenario will be described in detail below.

[0026] In step S102, in response to the current running state being normal running state, the interrupt request instruction is added to the task queue upon receiving the interrupt request instruction sent by the target small core.

[0027] Specifically, such as Figure 2 As shown, if the current running state is normal, firstly, the target small core enters the log writing stage. At this time, the target small core holds a RAM lock (access lock for the log interval). The target small core writes log data to the log interval currently marked as being written in the log RAM area. When the log interval is full, the target small core switches to the next log interval currently marked as being written to continue writing log data. At the same time, the status of the previous full log interval is changed from being written to full (FULL state). At this time, the status of the log interval is updated and recorded as a full log interval, and it is marked that the full log interval is to be saved. At the same time, an interrupt request instruction is sent to the target large core through the interrupt register REG_CORE_NFCx_INFO_CORE0, triggering the large core Core-0 interrupt to notify the target large core that the log data of the full log interval can be saved.

[0028] Secondly, when the target large core receives the interrupt request instruction sent by the target small core, it adds the interrupt request instruction to the task queue, and the background task processes the interrupt request of the target small core serially.

[0029] In step S103, in response to the interrupt request instruction being in the scheduled processing state, a first release lock instruction is sent to the target small core, so as to determine the bitmap information of the full log interval of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction.

[0030] According to one embodiment of the present invention, determining the first log data to be stored based on the bitmap information of the full log interval includes: identifying each bit in the bitmap information of the full log interval to determine the full log interval; and using the log data of the full log interval as the first log data to be stored.

[0031] Specifically, the target large core adds the interrupt request instruction to the task queue. After the background task processes the interrupt request from the target small core serially, when the interrupt request instruction is in the scheduled processing state, that is, when it is the turn of the interrupt request sent by the target small core, the target large core sends a first lock release instruction to the target small core through the interrupt register REG_CORE0_INFO_CORE_NFCx, notifying the target small core to release the access lock of the full log range. After receiving the first lock release instruction sent by the target large core, the target small core stops log writing and releases the access lock of the full log range. It also replies to the target large core through the interrupt register REG_CORE_NFCx_INFO_CORE0, that is, triggers the Core-0 interrupt of the target large core, and carries the bitmap information of the full log range. This bitmap information represents the log range in the shared memory area of ​​the target small core that is in a full state.

[0032] Furthermore, when the target large core receives the access lock from the target small core to release the full log interval, it determines the full log interval bitmap information bitmap of the target small core. That is, it identifies each bit in the full log interval bitmap information bitmap to determine the full log interval. When the bitmap value is 1, it indicates that the log interval is full. When the bitmap value is 0, it indicates that the log interval is not full. For example, if log intervals 0, 1, and 2 are full, then the bitmap is 0x7 (i.e., 0b111). Then, the log data of the log interval with a bit value of 1 is used as the first log data to be stored.

[0033] Therefore, by identifying full log intervals bit by bit based on the bitmap information of full log intervals and determining their log data as the first log data to be stored, all log intervals to be saved can be accurately and in batches in a single interrupt interaction, without the need for interval-by-interval query or multiple interrupts, which significantly reduces the communication overhead between cores and improves the log saving efficiency.

[0034] In step S104, based on the bitmap information of the full log interval, the first log data to be stored is determined and stored in the first storage area.

[0035] Specifically, when the target large core detects that the target small core has released the access lock of the full log interval, the full log interval is determined based on the bitmap information of the full log interval carried by the target small core in the interrupt reply, and the log data of the full log interval is saved to the first storage area, that is, the first log data to be stored is saved to the first storage area. The first storage area is a power-off retention storage area, such as a capacitor-retained DRAM device.

[0036] According to one embodiment of the present invention, before storing the first log data to be stored in the first storage area, the method further includes: determining the remaining storage capacity of the first storage area and the duration of unstored data in the second storage area; if the occupied capacity of the log data is greater than the remaining storage capacity, or the duration of unstored data is greater than a preset duration, then storing the first log data to be stored in the second storage area and updating the status flag of the full log interval to the idle state.

[0037] According to one embodiment of the present invention, after storing the first log data to be stored in the first storage area, the method further includes: in response to the first storage area completing the storage of the first log data to be stored, updating the status flag of the full log interval to an idle state.

[0038] The preset duration can be set by those skilled in the art based on the transmission performance and requirements of log data, or it can be obtained based on a limited number of computer simulation calculations, and is not specifically limited here.

[0039] Specifically, after the target large core reads the first log data to be stored in the full log interval according to the bitmap information of the full log interval, it determines whether the capacity of the first log data to be stored exceeds the remaining storage capacity of the first storage area, or whether the duration of unstored data exceeds a preset duration. If the capacity of the first log data to be stored does not exceed the remaining storage capacity of the first storage area and the duration of unstored data is less than or equal to the preset duration, it means that the remaining storage capacity of the first storage area is sufficient to continue storing the first log data to be stored, and the first log data to be stored is stored in the first storage area. If the capacity of the first log data to be stored exceeds the remaining storage capacity of the first storage area, or the duration of unstored data exceeds the preset duration, it means that the remaining storage capacity of the first storage area is insufficient to continue storing the first log data to be stored, that is, the first log data to be stored in the first storage area has accumulated to a certain amount, or the duration of unstored data not being stored in the second storage area exceeds the preset duration. At this time, the first log data to be stored is stored in the second storage area, and the status flag of the full log interval is updated to the idle state. Then, the target small core is notified to rediscover the lock and continue writing logs through the interrupt register REG_CORE0_INFO_CORE_NFCx.

[0040] Therefore, by determining whether the remaining capacity of the first storage area is sufficient or whether the unstored data in the second storage area has timed out, log data is directly written to the second storage area in the case of insufficient capacity or timeout, thereby avoiding log writing blockage or loss caused by a full cache or data retention for too long, ensuring the timeliness of log storage and the stability of system operation.

[0041] According to one embodiment of the present invention, the method further includes: polling the log interval of the target small core based on a preset polling mechanism, and determining whether there is a full log interval in the target small core; in response to the existence of a full log interval in the target small core and no interrupt request instruction sent by the target small core, triggering an active storage process, and storing the first log data to be stored in the target small core into the first storage area.

[0042] According to one embodiment of the present invention, after determining whether there is a full log interval in the target small core, the method further includes: if there is no full log interval in the target small core, then the current polling ends and polling is performed after a preset period.

[0043] The preset polling mechanism and preset cycle can be set based on log production rate, system real-time requirements, and large core processing load, etc., and are not specifically limited here.

[0044] Specifically, during the log storage process, the present invention uses an automatic timer on the target large core and triggers a polling task periodically (e.g., every 100ms) based on a preset polling mechanism to poll the log intervals of all target small cores. It also reads the status flag for each log interval. If a target small core has a full log interval, it further determines whether it has received an interrupt request command corresponding to the full log interval. If an interrupt request command is received, the interrupt is triggered normally and placed in the task queue for processing by background tasks. If a target small core has a full log interval but has not received an interrupt request command, it indicates that the interrupt may be lost. In this case, an active storage process is triggered, which actively stores the first log data to be stored in the full log interval of the target small core to the first storage area to prevent interrupt loss.

[0045] Furthermore, if there is no full log interval within the target kernel, the current round of polling ends, and the system waits for the next cycle.

[0046] It should be noted that the preset polling mechanism and the interrupt mechanism of the present invention are executed in parallel. The interrupt mechanism is triggered by the target large core responding to the interrupt request instruction sent by the target small core, and the preset polling mechanism is triggered by the target large core periodically and actively checking the status flag of the log interval. The preset polling mechanism is used to prevent the log data of the full log interval from not being stored in time due to the loss of the interrupt request instruction.

[0047] Therefore, by periodically and proactively checking the log interval status of the target small core through a preset polling mechanism, the storage process is proactively triggered when the log interval is found to be full but no corresponding interrupt request is received. This effectively prevents log data in the full log interval from being lost due to interruption, thereby improving the reliability and fault tolerance of log storage.

[0048] According to one embodiment of the present invention, before sending a first release lock instruction to the target small core in response to an interrupt request instruction being in a scheduled processing state, the method further includes: identifying the current storage state of multiple log intervals in the target small core; in response to multiple log intervals being in a full storage state, determining the target log interval that is earliest in a full state based on the storage timestamps of the multiple log intervals; clearing the log data in the target log interval, updating the status identifier of the target log interval to a writable state, and sending a writable notification to the target small core.

[0049] Specifically, if the write speed of the target small core is too fast and consistently faster than the save speed of the target large core, the current storage status of multiple log intervals in the target small core is identified. If the current storage status of multiple log intervals is full, then based on the storage timestamps of multiple log intervals, the log data in the target log interval that was first in a full state is cleared. In other words, because the write speed of the target small core is consistently faster than the save speed of the target large core, all the log intervals of the target small core become full, resulting in the target small core having no free log intervals to write data. At this time, the target large core first saves the log data of the target log interval that was first in a full state to the first storage area, then clears the old log data to release the target log interval, and after clearing, updates the status flag of the target log interval to a writable state, and sends a writable notification to the target small core so that the target small core can use the target log interval to continue writing new log data.

[0050] Therefore, before the large core processes the save request, it is possible to identify in advance whether all log intervals of the small core are full. In the extreme case where all are full, the earliest filled log interval is actively reclaimed and released to a writable state. This avoids log write blocking caused by the small core's write speed being consistently faster than the large core's save speed, thus ensuring the system's continuous availability in log flood scenarios.

[0051] According to one embodiment of the present invention, after determining the current operating state of the target storage controller, the method further includes: in response to the current operating state being an abnormal operating state, determining the abnormal type of the abnormal operating state; determining the second log data to be stored according to the abnormal type, and storing the second log data to be stored in the first storage area.

[0052] According to one embodiment of the present invention, the exception type is an abnormal power-down type. Determining the second log data to be stored based on the exception type includes: in response to the exception type being an abnormal power-down type, sending a second release lock instruction to the target small core; and upon receiving a release lock completion signal sent by the target small core based on the second release lock instruction, using the full amount of log data in the shared memory area of ​​the target small core as the second log data to be stored.

[0053] Specifically, such as Figure 3 As shown, if the current running state is in an abnormal running state, and the abnormal type is abnormal power-down, firstly, after the target large core Core-0 receives the power-down signal notification, it sequentially sends a second lock release instruction to the target small cores through the interrupt register REG_CORE0_INFO_CORE_NFCx, notifying each target small core of the "abnormal power-down" event; secondly, after receiving the second lock release instruction sent by the target large core, the target small core immediately stops all log write operations to prevent data from being modified during the saving process, and releases the log RAM lock of the full log interval when there is a full log interval, so that the target large core can read. The target small core takes its shared memory area; then, the target small core sends a lock release completion signal to the target large core through the interrupt register REG_CORE_NFCx_INFO_CORE0, triggering the target large core Core-0 interrupt and notifying the target large core that the log RAM is ready. When the target large core receives the lock release completion signal sent by the target small core based on the second lock release instruction, it takes the full log data (including all log intervals and metadata) in the shared memory area of ​​the target small core as the second log data to be stored, and stores the second log data to be stored in the first memory area (such as capacitor-supported DRAM) at once to ensure that the data is not lost at the moment of power failure.

[0054] Therefore, when the abnormality type is abnormal power-off, by sending a lock release command to the target working core and receiving its lock release completion signal, the full log data in the shared storage area of ​​the target working core is identified as the log data to be stored. This allows for timely and complete acquisition of all log information of each working core before the system loses power, ensuring that log data is not lost at the moment of power failure and preserving complete field data for subsequent fault analysis.

[0055] According to one embodiment of the present invention, after storing the second log data to be stored in the first storage area, the method further includes: determining whether all the second log data to be stored has been stored in the first storage area; if all the second log data to be stored has been stored in the first storage area, generating a system power-down command.

[0056] Specifically, after the target large core stores the second log data to be stored in the first storage area, it further determines whether all the second log data to be stored has been stored in the first storage area. If all the second log data to be stored has been stored in the first storage area, a system power-down command is generated to allow the system to power down. If the second log data to be stored has not been fully stored in the first storage area, the remaining log data of the target small core continues to be stored until all the second log data to be stored is stored in the first storage area, and a system power-down command is generated to allow the system to power down.

[0057] Therefore, after storing the full log data of each target core to the power-loss retention storage device, the system determines whether all the log data of all target cores has been stored. Only after confirming that all logs have been safely saved will a system power-down command be generated. This ensures that the log data of all target cores is completely saved when the system is powered down abnormally, avoiding log loss due to some target core logs not being completely saved before power-down, and ensuring the integrity and reliability of log storage in abnormal power-down scenarios.

[0058] According to one embodiment of the present invention, the exception type is a fault dump type. Determining the second log data to be stored based on the exception type includes: in response to the exception type being a fault dump type, determining whether the target large core is in a fault dump state; if the target large core is in a fault dump state, setting a global fault flag and sending a third release lock instruction and a fault instruction to the target small core; and upon receiving a release lock completion signal sent by the target small core based on the third release lock instruction and the target small core entering a fault mode, using the full log data in the shared storage area of ​​the target small core as the second log data to be stored.

[0059] Specifically, such as Figure 4 As shown, if the target large core malfunctions, for example, if it is in a fault dump state (i.e., target large core CoreDump), the target large core Core-0 sets a global fault flag (i.e., a global CoreDump flag) and sends a third lock release instruction and a fault instruction to the target small cores via the interrupt register REG_CORE0_INFO_CORE_NFCx, notifying all target small cores to enter fault mode. Secondly, upon receiving the third lock release instruction and the fault instruction, the target small cores immediately stop all log writing operations and, if a log interval is full, release the log RAM lock of that full log interval, allowing the target large core to read its logs. Shared memory area; next, the target small core sends a lock release completion signal to the target large core through the interrupt register REG_CORE_NFCx_INFO_CORE0, triggering the target large core Core-0 interrupt, notifying the target large core that the log RAM is ready. When the target large core receives the lock release completion signal sent by the target small core based on the third lock release instruction and the target small core enters fault mode, it uses the full log data (including all log intervals and metadata) in the shared memory area of ​​the target small core as the second log data to be stored, and stores the second log data to be stored in the first memory area (such as capacitor-supplied DRAM) at once to ensure that the log data is not lost.

[0060] Therefore, when the anomaly type is a fault dump type, by determining whether the target large core is in a fault dump state and, after confirmation, setting a global fault flag, sending a lock release command and a fault dump notification to each target small core, and after receiving the lock release completion signal from each target small core and it entering the fault dump mode, the full log data in the shared storage area of ​​each working core is determined as the log data to be stored. Thus, even in the emergency situation of the large core crashing, the log writing of all small cores can still be stopped in an orderly manner and all log data can be completely obtained, ensuring that the fault scene information is completely preserved and providing a reliable basis for subsequent root cause analysis.

[0061] According to one embodiment of the present invention, after determining whether the target large core is in a fault dump state, the method further includes: if the target large core is not in a fault dump state, detecting whether the target small core is an abnormal small core in a fault dump state; if the target small core is an abnormal small core in a fault dump state, setting a global fault flag and sending a fault command to the target small core.

[0062] Specifically, such as Figure 5 As shown, if the target large core detects an anomaly in the target small core, i.e., the target small core is in a fault dump state (i.e., target small core CoreDump), such as a watchdog timeout, the target large core Core-0 sets a global fault flag (i.e., a global CoreDump flag) and sends a fault command to the target small core through the interrupt register REG_CORE0_INFO_CORE_NFCx, notifying all target small cores to enter fault mode so that the corresponding log storage process can be executed when the target small core CoreDumps.

[0063] Therefore, when the target large core is not in a fault dump state, the system detects whether there are abnormal target small cores in the fault dump state among the target small cores. When an abnormal target small core is confirmed to exist, a global fault flag is set and a fault dump notification is sent to each target small core. This allows the system to promptly identify the source of the anomaly and initiate a full-scenario log protection process when individual small cores crash. This provides a trigger basis for subsequent forced reading of abnormal small cores and collaborative saving of normal small cores, ensuring that the system can still completely retain the log data of all small cores even when some small cores fail.

[0064] According to one embodiment of the present invention, after sending a fault instruction to the target small core, the method further includes: upon receiving that the abnormal small core has entered a fault mode, forcibly clearing the access lock of the abnormal small core, and storing the second log data to be stored of the abnormal small core in the first storage area.

[0065] Specifically, such as Figure 5As shown, when an abnormal small core enters fault mode, it cannot respond. Therefore, without waiting for the target small core to unlock and respond, the access lock of the abnormal small core is forcibly cleared directly through the interrupt register REG_CORE0_INFO_CORE_NFCx. The second log data to be stored (including all log ranges and metadata) in the shared memory area of ​​the abnormal small core is read directly, and the second log data to be stored of the abnormal small core is stored directly to the first memory area (such as capacitor-maintained DRAM), thereby avoiding the predicament of a dead core being unable to release the lock.

[0066] Therefore, after sending a fault dump notification to each target small core, for abnormal small cores that have entered fault dump mode, their access locks are forcibly cleared and their full log data is directly read and stored in the power-loss retention storage area. This solves the fundamental technical problem in the prior art where the log data cannot be read because the abnormal small core cannot actively release the lock. It ensures that even if the small core itself crashes and "deadlocks", its log data can be completely preserved, providing key evidence for fault root cause analysis.

[0067] According to one embodiment of the present invention, after detecting whether the target small core is an abnormal small core in a fault dump state, the method further includes: if the target small core is a normal small core, sending a fourth release lock instruction to the target small core; and upon receiving a release lock completion signal sent by the normal small core based on the fourth release lock instruction, storing the second log data to be stored of the normal small core in the first storage area.

[0068] Specifically, such as Figure 5 As shown, if the target small core is a normal small core, the normal small core's log storage process is executed. That is, the fourth release lock instruction is sent to the target small core. After the target small core receives the fourth release lock instruction, it immediately stops all log writing operations, and releases the log RAM lock of the full log interval when there is a full log interval, so that the target large core can read its shared memory area. Next, the target small core sends a release lock completion signal to the target large core through the interrupt register REG_CORE_NFCx_INFO_CORE0, triggering the target large core's Core-0 interrupt, notifying the target large core that the log RAM is ready. When the target large core receives the release lock completion signal sent by the target small core based on the fourth release lock instruction, it uses the full log data (including all log intervals and metadata) in the target small core's shared memory area as the second log data to be stored, and stores the second log data to be stored in the first memory area (such as capacitor-supplied DRAM) at once to ensure that the log data is not lost.

[0069] Therefore, when an abnormal working core is detected in the target small core, the normal small core that is not in the fault dump state sends a lock release command and, after receiving the lock release completion signal, stores all log data in the shared storage area of ​​the normal small core to the power failure retention storage area. This achieves differentiated collaborative storage of logs of abnormal small cores and normal small cores, ensuring that the logs of all small cores are completely preserved in the fault dump scenario.

[0070] According to one embodiment of the present invention, the method further includes: if no lock release completion signal is received from any target core within a preset waiting time, the access lock of the shared memory area of ​​the target core that did not send a lock release completion signal is cleared, and the second log data to be stored of the target core is stored in the first storage area.

[0071] The preset waiting time can be set by those skilled in the art based on the transmission performance and requirements of log data, or it can be obtained based on a limited number of computer simulation calculations, and no specific limitation is made here.

[0072] Specifically, after the target large core sends a lock release command to the target small core, it determines whether a lock release completion signal from any target small core is received within a preset waiting time to distinguish whether the target small core is responding normally or has timed out. If no lock release completion signal from any target small core is received within the preset waiting time, it is determined that the target small core has timed out and may be abnormal. At this time, the access lock of the shared memory area of ​​the target small core that did not send a lock release completion signal is forcibly cleared, and the second log data to be stored of the target small core is stored in the first storage area to ensure that the log data is not lost.

[0073] Therefore, after sending the lock release command to each working core, if no lock release completion signal is received from any working core within the preset waiting time, the access lock of that working core is forcibly cleared and its full log data is read directly. This ensures that the log data is completely saved even in the case of small core response timeout or freezing, avoiding log loss due to waiting timeout, and further enhancing the robustness and reliability of log saving in abnormal scenarios.

[0074] In summary, based on the detailed discussion above, the present invention can achieve the following beneficial effects: (1) Non-blocking log writing: After the small core fills a range, it immediately releases the lock and switches ranges. The big core is notified to save asynchronously through bitmap interrupt, which greatly improves log throughput and reduces loss rate; (2) Full-scenario coverage: It simultaneously solves the problem of small core log saving in four key scenarios: normal operation, abnormal power failure, large core CoreDump, and small core CoreDump. In particular, for the case where the small core itself cannot release the lock during CoreDump, forced reading of the log is achieved by hardware-forced release of the register; (3) Low-cost implementation: It does not require a significant increase in the RAM capacity of the small core, but only requires shared access capabilities, interrupt registers and a small amount of hardware forced release logic, resulting in minimal hardware overhead; (4) High reliability: The interrupt + polling dual triggering mechanism is adopted to avoid interrupt loss; atomic locks ensure data consistency; forced saving during abnormal power-down to preserve the fault scene to the maximum extent.

[0075] According to the log saving method proposed in this embodiment of the invention, when the target storage controller is in normal operation and receives an interrupt request instruction sent by the target small core, the interrupt request instruction is added to the task queue; when the interrupt request instruction is in the scheduled processing state, a first release lock instruction is sent to the target small core, so that after the target small core releases the access lock of the full log interval based on the first release lock instruction, the bitmap information of the full log interval of the target small core is determined, and the first log data to be stored is determined and stored in the first storage area. This solves the problem that logs are difficult to save in real time and are easy to be lost in the multi-core architecture of solid-state drives due to the limited storage space of the small core. Through the collaborative mechanism of interval partitioning-bitmap interrupt asynchronous saving-hardware forced lock release, non-blocking real-time saving of small core logs can be achieved without expanding the small core memory.

[0076] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0077] Embodiments of the present invention also provide a log storage device.

[0078] Figure 6 This is a block diagram of a log storage device according to an embodiment of the present invention.

[0079] like Figure 6 As shown, the log storage device 10 includes: a first determining module 100, a receiving module 200, a second determining module 300, and a first storage module 400.

[0080] The first determining module 100 is used to determine the current operating status of the target storage controller; The receiving module 200 is used to add the interrupt request instruction to the task queue when the current running state is normal and the interrupt request instruction sent by the target small core is received. The second determining module 300 is used to send a first release lock instruction to the target small core in response to the interrupt request instruction being in the scheduled processing state, so as to determine the bitmap information of the full log interval of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction. The first storage module 400 is used to determine the first log data to be stored based on the bitmap information of the full log interval, and to store the first log data to be stored in the first storage area.

[0081] According to an embodiment of the present invention, before storing the first log data to be stored in the first storage area, the first storage module 400 further includes: The first determining unit is used to determine the remaining storage capacity of the first storage area and the duration of unstored data in the second storage area; The first storage unit is used to store the first log data to be stored in the second storage area if the occupied capacity of the log data is greater than the remaining storage capacity, or if the duration of unstored data is longer than a preset duration, and update the status flag of the full log interval to the idle state.

[0082] According to an embodiment of the present invention, before sending a first lock release instruction to the target small core while in a scheduled processing state in response to an interrupt request instruction, the second determining module 300 further includes: The first identification unit is used to identify the current storage status of multiple log ranges in the target small core; The second determining unit is used to determine the target log interval that is the earliest to be full, based on the storage timestamps of the multiple log intervals, in response to the current storage status of multiple log intervals being full. The first update unit is used to clear the log data in the target log range, update the status flag of the target log range to the writable state, and send a writable notification to the target small core.

[0083] According to an embodiment of the present invention, after storing the first log data to be stored in the first storage area, the first storage module 400 further includes: The second update unit is used to update the status flag of the full log interval to the idle state in response to the completion of the storage of the first log data to be stored in the first storage area.

[0084] According to one embodiment of the present invention, it further includes: The judgment module is used to poll the log range of the target small core based on a preset polling mechanism and determine whether there is a full log range in the target small core. The second storage module is used to trigger an active storage process in response to the fact that the target small core has a full log range and no interrupt request instruction has been received from the target small core, and to store the first log data to be stored in the target small core to the first storage area.

[0085] According to an embodiment of the present invention, after determining whether a full log interval exists within the target small core, the determination module further includes: The polling unit is used to end the current polling if there is no full log interval in the target small core, and to start polling again after a preset period.

[0086] According to one embodiment of the present invention, the first storage module 400 includes: The second identification unit is used to identify each bit in the bitmap information of the full log interval and determine the full log interval. The third update unit is used to take the log data in the full log range as the first log data to be stored.

[0087] According to an embodiment of the present invention, after determining the current operating state of the target storage controller, the first determining module 100 further includes: The third determining unit is used to determine the abnormal type of the abnormal operating state in response to the current operating state being an abnormal operating state; The second storage unit is used to determine the second log data to be stored based on the exception type, and to store the second log data to be stored in the first storage area.

[0088] According to one embodiment of the present invention, the second storage unit includes: The sending subunit is used to send a second lock release command to the target small core in response to an exception type of abnormal power-down. The first storage subunit is used to, upon receiving a lock release completion signal sent by the target small core based on the second lock release instruction, use the full log data in the shared storage area of ​​the target small core as the second log data to be stored.

[0089] According to one embodiment of the present invention, after storing the second log data to be stored in the first storage area, the second storage unit further includes: The first judgment subunit is used to determine whether all the second log data to be stored has been stored in the first storage area; The generation subunit is used to generate a system power-down command if all the second log data to be stored has been stored in the first storage area.

[0090] According to one embodiment of the present invention, the second storage unit includes: The second judgment subunit is used to determine whether the target large core is in a fault dump state in response to the exception type being fault dump type. The sending subunit is used to set a global fault flag and send a third release lock command and a fault command to the target small core if the target large core is in a fault dump state. The second storage subunit is used to store the full log data in the shared storage area of ​​the target small core as the second log data to be stored when the target small core receives the lock release completion signal sent by the target small core based on the third lock release instruction and the target small core enters the fault mode.

[0091] According to an embodiment of the present invention, after determining whether the target large core is in a fault dump state, the second determination subunit further includes: The detection component is used to detect whether the target small core is an abnormal small core that is in a fault dump state if the target large core is not in a fault dump state. The sender is used to set a global fault flag and send a fault command to the target core if the target core is an abnormal core in a fault dump state.

[0092] According to one embodiment of the present invention, after sending a fault command to the target small core, the sending component further includes: The clear sub-component is used to forcibly clear the access lock of the abnormal small core when it is received that the abnormal small core has entered the fault mode, and to store the second log data to be stored of the abnormal small core to the first storage area.

[0093] According to one embodiment of the present invention, after detecting whether the target small core is an abnormal small core in a fault dump state, the detection component further includes: The sending sub-component is used to send a fourth lock release command to the target small core if the target small core is a normal small core; The first storage component is used to store the second log data to be stored from the normal small core to the first storage area upon receiving a lock release completion signal sent by the normal small core based on the fourth lock release instruction.

[0094] According to one embodiment of the present invention, it further includes: The second storage component is used to clear the access lock of the shared storage area of ​​the target core that did not send the lock release completion signal if no lock release completion signal is received from any target core within a preset waiting time, and to store the second log data to be stored of the target core to the first storage area.

[0095] According to one embodiment of the present invention, the shared storage area is divided into multiple log intervals, and the log intervals have status identifiers, including at least one of the following: writing status, full status, and idle status.

[0096] In summary, the descriptions of the features in the embodiments corresponding to the log storage device can be found in the relevant descriptions of the embodiments corresponding to the log storage method, and will not be repeated here.

[0097] Embodiments of the present invention also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described log saving method embodiments.

[0098] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described log saving method embodiments when running.

[0099] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0100] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described log saving method embodiments.

[0101] Embodiments of the present invention also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described log saving method embodiments.

[0102] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0103] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0104] The log saving method provided by this invention has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make several improvements and modifications to this invention without departing from the principles of this invention, and these improvements and modifications also fall within the protection scope of the claims of this invention.

Claims

1. A log saving method, characterized in that, include: Determine the current operating status of the target storage controller; In response to the current running state being a normal running state, upon receiving an interrupt request instruction sent by the target small core, the interrupt request instruction is added to the task queue; In response to the interrupt request instruction being in a scheduled processing state, a first release lock instruction is sent to the target small core, so as to determine the full log interval bitmap information of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction; Based on the bitmap information of the full log interval, the first log data to be stored is determined and stored in the first storage area.

2. The log saving method according to claim 1, characterized in that, Before storing the first log data to be stored in the first storage area, the method further includes: Determine the remaining storage capacity of the first storage area and the duration of unstored data in the second storage area; If the occupied capacity of the log data is greater than the remaining storage capacity, or if the duration of the unstored data is longer than a preset duration, then the first log data to be stored is stored in the second storage area, and the status flag of the full log interval is updated to idle status.

3. The log saving method according to claim 1, characterized in that, Before sending the first lock release instruction to the target small core in response to the interrupt request instruction being in a scheduled processing state, the method further includes: Identify the current storage status of multiple log ranges in the target small core; In response to the fact that the current storage status of the plurality of log intervals is full, the target log interval that is earliest in the full state is determined based on the storage timestamps of the plurality of log intervals. Clear the log data in the target log range, update the status identifier of the target log range to a writable state, and send a writable notification to the target small core.

4. The log saving method according to claim 1, characterized in that, After storing the first log data to be stored in the first storage area, the process further includes: In response to the first storage area completing the storage of the first log data to be stored, the status flag of the full log interval is updated to idle status.

5. The log saving method according to claim 1, characterized in that, Also includes: Based on a preset polling mechanism, the log interval of the target small core is polled, and it is determined whether there is a full log interval within the target small core; If the target small core has a full log interval and no interrupt request instruction is received from the target small core, an active storage process is triggered, and the first log data to be stored in the target small core is stored in the first storage area.

6. The log saving method according to claim 5, characterized in that, After determining whether a full log interval exists within the target small core, the process also includes: If the target small core does not contain the full log interval, the current polling ends and polling resumes after a preset period.

7. The log saving method according to claim 1, characterized in that, The step of determining the first log data to be stored based on the bitmap information of the full log interval includes: Identify each bit in the bitmap information of the full log interval to determine the full log interval; The log data in the full log range is used as the first log data to be stored.

8. The log saving method according to claim 1, characterized in that, After determining the current operating state of the target storage controller, the process also includes: In response to the current operating state being an abnormal operating state, the abnormal type of the abnormal operating state is determined; The second log data to be stored is determined based on the anomaly type, and the second log data to be stored is stored in the first storage area.

9. The log saving method according to claim 8, characterized in that, The exception type is an abnormal power-off type. Determining the second log data to be stored based on the exception type includes: In response to the exception type being the abnormal power-down type, a second release lock command is sent to the target small core; Upon receiving the lock release completion signal sent by the target small core based on the second lock release instruction, the full log data in the shared memory area of ​​the target small core is used as the second log data to be stored.

10. The log saving method according to claim 8, characterized in that, After storing the second log data to be stored in the first storage area, the method further includes: Determine whether the second set of log data to be stored has been stored in the first storage area; If all the second log data to be stored has been stored in the first storage area, then a system power-down command is generated.

11. The log saving method according to claim 8, characterized in that, The anomaly type is a fault dump type, and the step of determining the second log data to be stored based on the anomaly type includes: In response to the exception type being the fault dump type, determine whether the target large core is in a fault dump state; If the target large core is in the fault dump state, then a global fault flag is set, and a third release lock command and a fault command are sent to the target small core; Upon receiving the lock release completion signal sent by the target small core based on the third lock release command and upon the target small core entering fault mode, the full log data in the shared storage area of ​​the target small core is used as the second log data to be stored.

12. The log saving method according to claim 11, characterized in that, After determining whether the target large core is in a fault dump state, the process also includes: If the target large core is not in the fault dump state, then detect whether the target small core is an abnormal small core in the fault dump state; If the target small core is an abnormal small core in the fault dump state, then the global fault flag is set and the fault command is sent to the target small core.

13. The log saving method according to claim 12, characterized in that, After sending the fault command to the target small core, the process also includes: Upon receiving a message that the abnormal small core has entered fault mode, the access lock of the abnormal small core is forcibly cleared, and the second log data to be stored of the abnormal small core is stored in the first storage area.

14. The log saving method according to claim 12, characterized in that, After detecting whether the target small core is an abnormal small core in the fault dump state, the method further includes: If the target small core is a normal small core, then a fourth lock release command is sent to the target small core; Upon receiving the lock release completion signal sent by the normal small core based on the fourth lock release instruction, the second log data to be stored of the normal small core is stored in the first storage area.

15. The log saving method according to claim 11 or 14, characterized in that, Also includes: If no lock release completion signal is received from any target core within the preset waiting time, the access lock of the shared memory area of ​​the target core that did not send a lock release completion signal is cleared, and the second log data to be stored of the target core is stored in the first storage area.

16. The log saving method according to claim 1, characterized in that, The shared storage area is divided into multiple log intervals, each log interval having a status identifier, which includes at least one of a writing status, a full status, and an idle status.

17. A log storage device, characterized in that, include: The first determining module is used to determine the current operating status of the target storage controller; The receiving module is configured to, in response to the current running state being a normal running state, add the interrupt request instruction sent by the target small core to the task queue. The second determining module is used to send a first release lock instruction to the target small core in response to the interrupt request instruction being in a scheduled processing state, so as to determine the full log interval bitmap information of the target small core after the target small core releases the access lock of the full log interval based on the first release lock instruction; The first storage module is used to determine the first log data to be stored based on the bitmap information of the full log interval, and to store the first log data to be stored in the first storage area.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the log saving method as described in any one of claims 1 to 16 when executing the computer program.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the log saving method as described in any one of claims 1 to 16.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the log saving method as described in any one of claims 1 to 16.

Images