Garbage collection test method and device, electronic equipment and storage medium

Abstract

The invention provides a garbage collection testing method and device, electronic equipment and a storage medium, and the method comprises the steps that a garbage collection triggering instruction from an external testing tool is received, and the garbage collection triggering instruction comprises a target identifier of to-be-collected data; in response to the garbage collection triggering instruction, starting garbage data collection operation on a data space corresponding to the target identifier; and after garbage collection is completed, a garbage collection completion signal is returned to the external test tool. By introducing a garbage collection mechanism actively triggered by an external test tool, the problems of uncontrollable test opportunity, limited scene coverage and the like caused by the fact that a traditional storage system GC test depends on internal condition triggering are effectively solved, a tester is allowed to accurately specify a target data space and trigger collection according to needs, and the test efficiency is improved. Redundant time consumption of automatic GC of a passive waiting system in a traditional method is avoided.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a garbage recycling testing method, device, electronic device, and storage medium. Background Art

[0002] With the development of cloud computing and big data technologies, storage systems need to efficiently manage storage space, of which garbage collection (GC) is a key component. GC mechanisms are responsible for identifying and recycling invalid data (i.e., data blocks or objects that are no longer referenced), freeing up storage space for new data. To ensure the reliability and performance of GC mechanisms, GC functionality is typically tested, including functional testing, performance testing, stability testing, and exception testing.

[0003] Currently, the garbage collection testing process for storage systems typically includes the following steps: 1. Simulate users frequently writing and deleting data; 2. Wait for the storage system to periodically (for example, every 10 minutes) check whether the GC trigger conditions are met (such as the garbage rate reaching a threshold); 3. If the conditions are met, the system performs garbage collection in sequence according to the priority strategy and multiple tasks; 4. After GC is completed, verify the correctness of the user data.

[0004] However, in existing technologies, the triggering of GC relies on the system's internal mechanism and cannot be manually intervened, making it difficult to accurately control the timing of the test. Summary of the Invention

[0005] The present application provides a garbage collection test method, device, electronic device and storage medium to solve the problem in the prior art that the triggering of GC depends on the internal mechanism of the system and cannot be intervened by humans, resulting in difficulty in accurately controlling the test timing.

[0006] In a first aspect, the present application provides a garbage collection testing method, comprising:

[0007] receiving a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected;

[0008] In response to the garbage collection trigger instruction, starting a garbage data collection operation on the data space corresponding to the target identifier;

[0009] After the garbage collection is completed, a garbage collection completion signal is returned to the external testing tool.

[0010] In a possible implementation, the initiating a garbage data collection operation on the data space corresponding to the target identifier includes:

[0011] Determine the data space range to be recovered according to the target identifier;

[0012] Scanning data blocks within the data space, and distinguishing valid data blocks from invalid data blocks based on a preset garbage collection determination rule;

[0013] Migrating the valid data block to a pre-allocated new storage location;

[0014] Release the physical storage space occupied by the data blocks that are judged to be invalid.

[0015] In one possible implementation, distinguishing valid data blocks from invalid data blocks based on a preset garbage collection determination rule includes:

[0016] For each data block, query the reference count of the data block in the metadata, where the reference count refers to the number of times the data block is effectively referenced;

[0017] When the reference count is zero, determining that the data block is an invalid data block;

[0018] When the reference count is greater than zero, reading the physical storage content of the data block and calculating a check value of the physical storage content;

[0019] comparing the checksum to the expected checksum recorded in the metadata;

[0020] If the check value matches the expected check value, determining that the data block is a valid data block;

[0021] In a case where the check value does not match the expected check value, the data block is determined to be an invalid data block.

[0022] In a possible implementation manner, after starting the garbage data collection operation, the method further includes:

[0023] During the execution of the garbage data recovery operation, multi-dimensional test verification is performed to obtain a verification result, wherein the multi-dimensional test verification includes one or more of function verification, performance verification, stability verification and robustness verification.

[0024] In one possible implementation, the functional verification includes:

[0025] Obtaining an actual check value of the data stored in the data space corresponding to the target identifier;

[0026] Reading an expected checksum value of the stored data from system metadata;

[0027] Comparing the actual verification value with the expected verification value for consistency;

[0028] When the actual verification value is consistent with the expected verification value, the verification is successful;

[0029] When the actual verification value is inconsistent with the expected verification value, the verification fails.

[0030] In one possible implementation, the functional verification further includes:

[0031] Counting the total amount of user data to be released in the data space corresponding to the target identifier;

[0032] Obtain the currently configured redundancy policy parameters from the storage system metadata;

[0033] Calculating the expected freed space size according to the redundancy policy parameters and the total amount of user data;

[0034] After garbage collection is completed, the actual freed space size is obtained;

[0035] The space release effect is verified according to the expected released space size and the actual released space size.

[0036] In one possible implementation, the performance verification includes:

[0037] During the execution of garbage collection operations, real-time performance indicators are continuously collected as process monitoring data;

[0038] When the process monitoring data is within a preset range, determining that the performance is normal;

[0039] When the process monitoring data is outside a preset range, it is determined that the performance is abnormal.

[0040] In one possible implementation, the performance verification further includes:

[0041] Before starting the garbage collection operation, collecting the system initial performance index as the first benchmark data, and after the garbage collection operation is completed, collecting the system steady-state performance index as the second benchmark data;

[0042] comparing the process monitoring data with the first reference data and the second reference data respectively;

[0043] When the difference does not exceed the preset tolerance threshold, it is determined that the performance is normal;

[0044] When the difference exceeds a preset tolerance threshold, it is determined to be a performance abnormality.

[0045] In one possible embodiment, the stability verification includes:

[0046] Real-time collection of operating indicator data of storage devices, including: interruption status records of read and write operations; comparison values ​​of data content verification results; statistics on delay time of read and write operations; and determination of device stability based on the operating indicator data.

[0047] In addition, real-time collection of operating status data of the storage service, the operating status data including: survival status information of the service process; usage and growth trend of memory resources; response time change curve of service requests; error records of data reading and writing; and judgment of service stability based on the operating status data.

[0048] In one possible implementation, the robustness verification includes:

[0049] Receiving an exception injection instruction sent by the external testing tool;

[0050] Parsing the exception injection instruction to obtain a target exception type and trigger parameters, wherein the target exception type is used to characterize the category of the exception scenario simulated during the garbage collection test, and the trigger parameters refer to configurable variables that control the exception simulation behavior;

[0051] Execute the corresponding exception handling process according to the target exception type and the trigger parameters:

[0052] Resume garbage collection operations after exception handling and record the exception handling results.

[0053] In a second aspect, the present application provides a garbage collection testing device, comprising:

[0054] A receiving module, configured to receive a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected;

[0055] a starting module, configured to start a garbage data collection operation on the data space corresponding to the target identifier in response to the garbage collection trigger instruction;

[0056] The return module is used to return a garbage collection completion signal to the external testing tool after completing garbage collection.

[0057] In one possible implementation, the startup module is specifically configured to:

[0058] Determine the data space range to be recovered according to the target identifier;

[0059] Scanning data blocks within the data space, and distinguishing valid data blocks from invalid data blocks based on a preset garbage collection determination rule;

[0060] Migrating the valid data block to a pre-allocated new storage location;

[0061] Release the physical storage space occupied by the data blocks that are judged to be invalid.

[0062] In one possible implementation, the startup module is further configured to:

[0063] For each data block, query the reference count of the data block in the metadata, where the reference count refers to the number of times the data block is effectively referenced;

[0064] When the reference count is zero, determining that the data block is an invalid data block;

[0065] When the reference count is greater than zero, reading the physical storage content of the data block and calculating a check value of the physical storage content;

[0066] comparing the checksum to the expected checksum recorded in the metadata;

[0067] If the check value matches the expected check value, determining that the data block is a valid data block;

[0068] In a case where the check value does not match the expected check value, the data block is determined to be an invalid data block.

[0069] In one possible implementation, the device further includes a verification module configured to:

[0070] During the execution of the garbage data recovery operation, multi-dimensional test verification is performed to obtain a verification result, wherein the multi-dimensional test verification includes one or more of function verification, performance verification, stability verification and robustness verification.

[0071] In one possible implementation, the verification module is specifically configured to:

[0072] Obtaining an actual check value of the data stored in the data space corresponding to the target identifier;

[0073] Reading an expected checksum value of the stored data from system metadata;

[0074] Comparing the actual verification value with the expected verification value for consistency;

[0075] When the actual verification value is consistent with the expected verification value, the verification is successful;

[0076] When the actual verification value is inconsistent with the expected verification value, the verification fails.

[0077] In one possible implementation, the verification module is further configured to:

[0078] Counting the total amount of user data to be released in the data space corresponding to the target identifier;

[0079] Obtain the currently configured redundancy policy parameters from the storage system metadata;

[0080] Calculating the expected freed space size according to the redundancy policy parameters and the total amount of user data;

[0081] After garbage collection is completed, the actual freed space size is obtained;

[0082] The space release effect is verified according to the expected released space size and the actual released space size.

[0083] In one possible implementation, the verification module is further configured to:

[0084] During the execution of garbage collection operations, real-time performance indicators are continuously collected as process monitoring data;

[0085] When the process monitoring data is within a preset range, determining that the performance is normal;

[0086] When the process monitoring data is outside a preset range, it is determined that the performance is abnormal.

[0087] In one possible implementation, the verification module is further configured to:

[0088] Before starting the garbage collection operation, collecting the system initial performance index as the first benchmark data, and after the garbage collection operation is completed, collecting the system steady-state performance index as the second benchmark data;

[0089] comparing the process monitoring data with the first reference data and the second reference data respectively;

[0090] When the difference does not exceed the preset tolerance threshold, it is determined that the performance is normal;

[0091] When the difference exceeds a preset tolerance threshold, it is determined to be a performance abnormality.

[0092] In one possible implementation, the verification module is further configured to:

[0093] Real-time collection of operating indicator data of storage devices, including: interruption status records of read and write operations; comparison values ​​of data content verification results; statistics on delay time of read and write operations; and determination of device stability based on the operating indicator data.

[0094] In addition, real-time collection of operating status data of the storage service, the operating status data including: survival status information of the service process; usage and growth trend of memory resources; response time change curve of service requests; error records of data reading and writing; and judgment of service stability based on the operating status data.

[0095] In one possible implementation, the verification module is further configured to:

[0096] Receiving an exception injection instruction sent by the external testing tool;

[0097] Parsing the exception injection instruction to obtain a target exception type and trigger parameters, wherein the target exception type is used to characterize the category of the exception scenario simulated during the garbage collection test, and the trigger parameters refer to configurable variables that control the exception simulation behavior;

[0098] Execute the corresponding exception handling process according to the target exception type and the trigger parameters:

[0099] Resume garbage collection operations after exception handling and record the exception handling results.

[0100] In a third aspect, the present application provides a device comprising: a processor and a memory, wherein the processor is configured to execute a garbage collection test program stored in the memory to implement the garbage collection test method described in any one of the first aspects.

[0101] In a fourth aspect, the present application provides a storage medium storing one or more programs, which can be executed by one or more processors to implement the garbage collection test method described in any one of the first aspects.

[0102] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application receives a garbage collection trigger instruction from an external test tool, wherein the garbage collection trigger instruction includes a target identifier of the data to be recovered; in response to the garbage collection trigger instruction, the garbage data recovery operation for the data space corresponding to the target identifier is started; after the garbage collection is completed, a garbage collection completion signal is returned to the external test tool. That is, by introducing a garbage collection mechanism actively triggered by an external test tool, the present application effectively solves the problems of uncontrollable test timing and limited scenario coverage caused by the reliance on internal condition triggers in traditional storage system GC tests. In addition, the method allows testers to accurately specify the target data space and trigger recovery on demand, avoiding the redundant time consumption of passively waiting for the system's automatic GC in traditional methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0103] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0104] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0105] One or more embodiments are exemplarily illustrated by pictures in the corresponding drawings. These exemplifications do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements. Unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0106] Figure 1 A flowchart of an embodiment of a garbage collection testing method provided in an embodiment of the present application;

[0107] Figure 2 A flowchart of another embodiment of a garbage collection testing method provided in an embodiment of the present application;

[0108] Figure 3 A flowchart of another embodiment of a garbage collection testing method provided in an embodiment of the present application;

[0109] Figure 4 A block diagram of an embodiment of a garbage collection test device provided in an embodiment of the present application;

[0110] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0111] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0112] The disclosure below provides many different embodiments or examples for implementing different structures of the present application. In order to simplify the disclosure of the present application, the components and settings of specific examples are described below. Of course, these are merely examples and are not intended to limit the present application. In addition, the present application may repeat reference numbers and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or settings discussed.

[0113] In order to solve the technical problem in the existing technology that the triggering of GC depends on the internal mechanism of the system and cannot be intervened by humans, resulting in difficulty in accurately controlling the test timing, the present application provides a garbage collection testing method that can realize the garbage collection mechanism actively triggered by introducing external testing tools. It effectively solves the problems of uncontrollable test timing and limited scenario coverage caused by the reliance on internal conditions to trigger GC tests in traditional storage systems. It also allows testers to accurately specify the target data space and trigger recycling on demand, avoiding the redundant time consumption of passively waiting for the system's automatic GC in traditional methods.

[0114] Figure 1 This is a flow chart of an embodiment of a garbage collection test method provided in the present application. Figure 1 As shown, the method includes the following steps:

[0115] Step 101: Receive a garbage collection trigger instruction from an external testing tool, where the garbage collection trigger instruction includes a target identifier of data to be collected.

[0116] An external test tool refers to a dedicated control program (such as a CLI tool or automated test platform) independent of the storage system. The system exposes the GC (Garbage Collection) interface through the tool, so that GC can be actively triggered through the tool.

[0117] The garbage collection trigger instruction refers to a structured command that includes a target identifier (such as a cloud disk ID or a service ID) and a priority tag (such as priority=HIGH). In the application, the GC task triggered by the external test tool has the highest priority.

[0118] Target identifiers are used to locate labels for data to be recycled. They are generally divided into two categories: user dimension, such as the cloud disk ID (disk_123), which identifies the data blocks of a specific user; and service dimension, such as the storage service node ID (storage_node_5), which identifies all garbage data on a physical node.

[0119] In an embodiment of the present application, the control node of the storage system listens to external tool requests, receives instructions through the RPC or HTTP interface, and after receiving the instructions, parses the target identifier in the instructions, verifies the permissions, and generates a high-priority GC task.

[0120] For example, if the tool sends force_gc --target=disk_123 --priority=CRITICAL , the storage system immediately interrupts the current low-priority GC task and processes this request instead.

[0121] Step 102: In response to the garbage collection trigger instruction, start a garbage data collection operation on the data space corresponding to the target identifier.

[0122] Garbage data refers to data blocks that have been logically deleted (marked with is_deleted = True) in the storage system but whose physical space has not been released. In an application, you can simulate users repeatedly writing and deleting data in a test environment. This data is garbage data.

[0123] Data space refers to the logical storage range where the garbage data to be recycled is located, which is determined by the target identifier (user dimension or service dimension): if the target identifier is a cloud disk ID, all logically deleted blocks of the disk are scanned; if the target identifier is a service ID, all dirty data of the node are scanned.

[0124] In the embodiment of the present application, first, task scheduling is performed: the GC scheduler inserts the task into the head of the queue and seizes the execution right; then, garbage identification is performed: the metadata database is queried to screen the data blocks in the target data space that meet is_deleted = True; finally, physical recycling is performed: the storage engine interface is called to release the physical space and update the metadata (such as the block bitmap).

[0125] Step 103: After garbage collection is completed, a garbage collection completion signal is returned to the external testing tool.

[0126] The garbage collection completion signal refers to a structured response message, which includes: a status code (such as 200OK); and collection statistics (such as the amount of freed space and the time consumed).

[0127] In an embodiment of the present application, after garbage collection is completed, the storage system sends a garbage collection completion signal to the tool to notify the user that the collection is complete.

[0128] The technical solution provided by the embodiment of the present application receives a garbage collection trigger instruction from an external test tool, wherein the garbage collection trigger instruction includes a target identifier of the data to be recycled; in response to the garbage collection trigger instruction, a garbage data collection operation is initiated for the data space corresponding to the target identifier; and after the garbage collection is completed, a garbage collection completion signal is returned to the external test tool. That is, by introducing a garbage collection mechanism actively triggered by an external test tool, the present application effectively solves the problems of uncontrollable test timing and limited scenario coverage caused by the reliance on internal condition triggers in traditional storage system GC testing. In addition, the application allows testers to accurately specify the target data space and trigger recycling on demand, avoiding the redundant time consumption of passively waiting for the system's automatic GC in traditional methods.

[0129] Figure 2 This is a flowchart of another embodiment of a garbage collection testing method provided in an embodiment of the present application. Figure 2 The process shown in Figure 1 Based on the process shown, the following steps are included:

[0130] Step 201: Determine the data space range to be reclaimed according to the target identifier.

[0131] In this step, the system parses the target identifier (such as disk_123 or storage_node_5) and queries the metadata service for its associated physical storage range (such as the LBA address range or data shard list). For example, if the target identifier is a cloud disk ID, all data blocks on that disk will be locked; if the target identifier is a service ID, all data shards managed by that node will be scanned.

[0132] Step 202: Scan the data blocks within the data space and distinguish valid data blocks from invalid data blocks based on a preset garbage collection determination rule.

[0133] Valid data blocks are those currently referenced by users or the system in the storage system, meaning they have not been logically deleted or are still within the retention period. Judgment criteria include: Not marked for deletion (is_deleted = False in the metadata); Within the retention period: Even if marked for deletion (is_deleted = True), the data has not exceeded the preset retention threshold (such as 7 days for a cloud disk's recycle bin); Referenced by other data: For example, dependencies such as snapshots and replicas still require the data block to be retained.

[0134] Invalid data block refers to a data block that has been logically deleted in the storage system and has no references, that is, data for which the physical space can be safely released. Determination conditions: Clearly marked for deletion: is_deleted = True in the metadata; Exceeded the retention period: The deletion time is earlier than the current time minus the retention threshold (e.g., delete_time < now() - 7 days); No dependencies: No snapshots, replicas, etc. reference this data block.

[0135] In the embodiments of this application, step 202 may specifically include the following steps: For each data block, query the reference count of the data block in the metadata, where the reference count refers to the number of times the data block is effectively referenced; In the case where the reference count is zero, determine that the data block is an invalid data block; In the case where the reference count is greater than zero, read the physical storage content of the data block and calculate the check value of the physical storage content; Compare the check value with the expected check value recorded in the metadata; In the case where the check value matches the expected check value, determine that the data block is a valid data block; In the case where the check value does not match the expected check value, determine that the data block is an invalid data block.

[0136] Reference count refers to the statistical value of the number of times a data block is effectively referenced in the storage system, usually recorded in the ref_count field of the metadata, including: Direct reference by user files; Indirect references such as snapshots and clones; Temporary internal system references.

[0137] Check value refers to the unique fingerprint value calculated for the physical content of a data block through a hash algorithm (such as CRC (Cyclic redundancy check), MD5 (Message-Digest algorithm 5)), used to detect data consistency.

[0138] This solution accurately distinguishes the validity of data blocks through a dual verification mechanism of reference count and check value: First, query the reference count (ref_count) of the data block. If it is zero, directly mark it as an invalid block; If it is greater than zero, read the physical content and calculate the real-time check value, and compare it with the expected value in the metadata: If they match, it is determined to be a valid block; If they do not match, it is regarded as an invalid block (possibly due to data corruption or metadata errors). This solution not only quickly filters out ownerless data through the reference count to improve the GC efficiency, but also ensures the physical integrity of referenced data through check value comparison.

[0139] Step 203: Migrate the valid data blocks to a newly allocated storage location.

[0140] New storage location: A continuous physical space pre-allocated by the storage system for reorganizing data fragments, usually located on different storage nodes or disks.

[0141] In this step, valid data blocks are written to new locations in sequence, and the physical address mapping in the metadata is updated.

[0142] Furthermore, the migration process can use copy-on-write to avoid business interruption; hot data is migrated first to improve subsequent read performance.

[0143] Step 204: Release the physical storage space occupied by the data block determined to be invalid.

[0144] In this step, the storage system notifies the underlying hardware to release physical blocks by calling the storage engine interface (such as trim / unmap), and performs metadata cleanup: deleting metadata records of invalid blocks to avoid repeated scanning in the next GC.

[0145] In another embodiment of the present application, the method may further include the following steps: after the migration of the valid data block is completed, reading the migrated data block content from the new storage location; recalculating the current check value of the data block content; comparing the current check value with the check value recorded before migration; and generating a data anomaly alarm if the current check value is inconsistent with the check value recorded before migration.

[0146] This solution builds a complete data integrity assurance system during the data migration process. The specific implementation process is as follows:

[0147] Verification mechanism after data migration: After the valid data block is migrated to the new storage location, the system will immediately start the data verification process, re-read the complete content of the migrated data block from the new storage location, and recalculate the current verification value of the data block using the same hash algorithm (such as SHA-256).

[0148] Checksum comparison analysis: The system automatically retrieves the original checksum recorded before the migration (this value is securely stored when the migration starts) and performs a rigorous bit-by-bit comparison analysis to ensure that the data content has not been changed during the migration process. The comparison process can use memory comparison technology to ensure efficiency and reliability.

[0149] Exception handling mechanism: When a checksum inconsistency is detected, the system will perform the following operations: a) immediately generate a three-level alarm (urgent, important, and general); b) record a detailed error log, including: the unique identifier of the data block; the original checksum and the new checksum; the migration timestamp and path information; and the storage node information involved; c) automatically trigger the data repair process.

[0150] This mechanism not only realizes real-time monitoring of data integrity, but also can quickly locate and repair abnormal situations, providing reliable data security for the storage system.

[0151] Figure 2 The process shown in the figure uses target identification to accurately locate the data space to be reclaimed, safely migrate valid data blocks to new storage locations, and completely release the space occupied by invalid data blocks. This solution reduces invalid scanning overhead through a targeted recycling mechanism, significantly improves garbage collection efficiency, realizes intelligent recycling and reuse of physical space, and effectively improves storage resource utilization.

[0152] Figure 3 This is a flow chart of another embodiment of a garbage collection testing method provided in an embodiment of the present application. Figure 3 The process shown in Figure 1 Based on the process shown, the following steps are included:

[0153] Step 301: During the execution of the garbage data recovery operation, multi-dimensional test verification is performed to obtain a verification result. The multi-dimensional test verification includes one or more of function verification, performance verification, stability verification, and robustness verification.

[0154] Functional verification includes: Data correctness verification: By comparing the actual checksum value (such as MD5, CRC, etc.) of the stored data with the expected checksum value in the system metadata, ensure that the data content is not damaged after GC; Space release verification: Based on the total amount of user data and redundancy strategy parameters (such as the number of copies or EC mode), the expected released space is calculated and compared with the actual released space to verify whether the storage resource recovery efficiency meets expectations.

[0155] Performance verification: Performance metrics (such as read / write bandwidth and IOPS) are collected before, during, and after GC. By comparing the difference between real-time monitoring data and preset ranges or benchmark data, we can determine whether GC has an abnormal impact on system performance.

[0156] Stability verification: Real-time monitoring of the operating indicators of storage devices (such as cloud disks) and services (such as storage processes), including read and write interruption records, latency, memory usage, error rates, etc., to ensure that there is no system lag, crash, or resource leakage during the GC process.

[0157] Robustness verification: Use external tools to inject exceptions (such as service restart, node downtime, and master switchover) to verify the GC's fault tolerance and data consistency guarantee mechanism in failure scenarios.

[0158] This solution performs multi-dimensional testing and verification during the GC process, covering GC data integrity, performance loss, system stability, and fault tolerance, ensuring the efficiency and reliability of the garbage collection process, while providing a quantitative evaluation basis for resource management and fault recovery of the storage system.

[0159] In the application, after obtaining the verification result, you can also write the verification result (such as {"status":"SUCCESS","expected":"30GB","actual":"29.8GB"}) into the GC completion signal for the test tool to automatically judge.

[0160] Specifically, functional verification may include the following steps: obtaining the actual verification value of the data stored in the data space corresponding to the target identifier; reading the expected verification value of the stored data from the system metadata; comparing the consistency of the actual verification value with the expected verification value; when the actual verification value is consistent with the expected verification value, the verification is successful; when the actual verification value is inconsistent with the expected verification value, the verification fails.

[0161] The actual checksum refers to the checksum calculated based on the current storage content of the data space; the expected checksum refers to the correct checksum result pre-stored in the system metadata.

[0162] During verification using this solution, the system obtains the actual checksum value in real time and compares it with the expected value. If the two match, GC has not compromised data integrity and verification is successful. If they do not match, data errors are detected and verification fails. This solution uses quantitative criteria to determine whether GC operations have caused data corruption and combines this with checksum comparison to automate verification, improving testing efficiency. Furthermore, by pre-storing expected values ​​in metadata, it ensures the reliability of the verification benchmark, providing key technical support for data security in storage systems.

[0163] In addition, functional verification may also include the following steps: counting the total amount of user data to be released in the data space corresponding to the target identifier; obtaining the currently configured redundancy policy parameters from the storage system metadata; calculating the expected released space size based on the redundant policy parameters and the total amount of user data; obtaining the actual released space size after completing garbage collection; and verifying the space release effect based on the expected released space size and the actual released space size.

[0164] Redundancy policy parameters refer to the data redundancy protection method configured for the storage system. For example, triple replicas means user data occupies three times the physical space. Another example is EC(4+2): user data occupies 1.5 times the physical space.

[0165] The expected freed space size refers to the ideal freed space value calculated based on the redundancy policy and the total amount of user data. The formula is: 3 replicas: Expected freed space = Total amount of user data × 3; EC(4+2): Expected freed space = Total amount of user data × 1.5.

[0166] The actual freed space size refers to the amount of physical space actually reclaimed by the storage system after GC is completed, which is calculated through metadata service statistics.

[0167] Verification results refer to determining whether GC is effective by comparing the difference between expected and actual freed space. If the difference is less than or equal to a threshold, the result is marked as SUCCESS (normal); if the difference is greater than the threshold, the result is marked as FAILED (abnormal).

[0168] The embodiment of the present application implements automated verification through the following steps: Pre-calculation stage: Count the total amount of user data in the target data space (such as 10GB), and calculate the expected released space (30GB) in combination with the redundancy strategy (such as 3 copies). GC execution stage: Physically release the garbage data block and record the actual released space (such as 29.8GB). Verification stage: Compare the expected value (30GB) with the actual value (29.8GB). If the difference is within the allowable error (such as ±1%), mark the verification as passed. The application can also include result feedback: write the verification result (such as {"status":"SUCCESS","expected":"30GB","actual":"29.8GB"}) into the GC completion signal for automatic judgment by the test tool.

[0169] For example, after a GC on an EC (4+2) storage system, the expected freed capacity is 15 GB (10 GB of user data × 1.5), but the actual freed capacity is 14.95 GB. The difference is 0.05 ≤ 0.1 (threshold). The verification result is marked as SUCCESS, confirming that the function is normal.

[0170] This solution achieves precise quantitative verification of garbage collection effectiveness by automatically comparing expected and actual freed space, ensuring that the storage system strictly adheres to pre-set redundancy strategies (such as triple replication or EC) for space reclamation. This not only significantly improves testing efficiency and accuracy, but also automatically identifies anomalies in GC algorithms or metadata management. It also provides unified verification standards for different redundancy architectures, significantly enhancing the reliability and maintainability of the storage system.

[0171] Performance verification may include the following steps: during the execution of the garbage collection operation, continuously collecting real-time performance indicators as process monitoring data; when the process monitoring data is within a preset range, determining that the performance is normal; when the process monitoring data is outside the preset range, determining that the performance is abnormal.

[0172] Real-time performance indicators refer to quantifiable parameters that reflect system performance (including but not limited to IOPS, read / write bandwidth, latency, etc.); process monitoring data refers to the time series data sets of the above indicators continuously collected during GC execution; preset ranges refer to reasonable fluctuation threshold intervals pre-set based on the system's baseline performance.

[0173] During verification using this solution, the system collects performance metrics in real time and compares them against preset thresholds. If all metrics fluctuate within a reasonable range, GC is deemed to have no significant impact on system performance (normal performance). If any metric exceeds the threshold, a performance anomaly is identified. This solution provides reliable data for resource scheduling decisions within the storage system through a dynamic monitoring mechanism, enabling the system to intelligently adjust GC execution strategies under various operating conditions, including peak business periods, thereby ensuring the stability of storage service quality.

[0174] In addition, performance verification may also include the following steps: before starting the garbage collection operation, collecting the system's initial performance indicators as the first benchmark data, and after the garbage collection operation is completed, collecting the system's steady-state performance indicators as the second benchmark data; comparing the differences between the process monitoring data and the first benchmark data and the second benchmark data respectively; when the difference does not exceed the preset tolerance threshold, determining that the performance is normal; when the difference exceeds the preset tolerance threshold, determining that the performance is abnormal.

[0175] The first baseline data refers to the initial system performance indicators collected before GC starts (such as IOPS and latency in idle state). The second baseline data refers to the performance indicators when the system returns to stability after GC is completed. The difference refers to the degree of deviation between the process monitoring data and the baseline data (such as percentage change or standard deviation). The preset tolerance threshold refers to the maximum allowable performance fluctuation range set according to business needs.

[0176] In this solution, the fio tool is used to test the bare disk before GC starts, obtaining initial IOPS, bandwidth, and latency data as the "first baseline data." During GC execution, the fio tool is continuously used to perform read and write operations, collecting real-time performance metrics as process monitoring data. After GC completes, the fio tool is again used to test steady-state performance as the "second baseline data." Using the quantitative metrics generated by the fio tool (including sequential and random read and write IOPS, bandwidth, and latency), the system calculates the "difference" (e.g., percentage IOPS drop) between the data during GC and the baselines before and after. A performance anomaly is identified when the difference exceeds a preset tolerance threshold (e.g., IOPS fluctuation not exceeding 15%).

[0177] This solution effectively eliminates the interference of environmental factors on test results by establishing a dual-benchmark performance indicator system before and after GC operation, and improves the accuracy and reliability of performance evaluation.

[0178] Stability verification may include the following steps: real-time collection of operating indicator data of the storage device, the operating indicator data including: interruption status records of read and write operations; verification result comparison values ​​of data content; delay time statistics of read and write operations; judging device stability based on the operating indicator data; and real-time collection of operating status data of the storage service, the operating status data including: survival status information of the service process; memory resource usage and growth trend; response time change curve of service requests; data reading and writing error occurrence records; judging service stability based on the operating status data.

[0179] Operational indicator data: refers to the various performance parameters collected from storage devices during the garbage collection process, mainly including: interrupt status records of read and write operations: log information recording whether the read and write operations are abnormally terminated; data content verification result comparison value: data consistency verification result calculated by verification algorithm (such as CRC32, MD5, etc.); read and write operation delay time statistics: records the time consumption distribution of each I / O operation from initiation to completion.

[0180] Operational status data: refers to the various status parameters collected from the storage service during the garbage collection process, mainly including: service process survival status information: monitoring data that records whether the service process exits abnormally; memory resource usage and growth trend: time series data that records the memory usage of the service process and its changes; service request response time change curve: records the time-consuming change trend of service processing requests; data reading and writing error records: log information that counts the number of failed read and write operations.

[0181] Device stability refers to the ability of storage devices to maintain normal service capabilities during the garbage collection process, and is evaluated through operational indicator data. Service stability refers to the ability of storage services to maintain availability and reliability during the garbage collection process, and is evaluated through operational status data.

[0182] In this solution, at the device level, the fio tool is used to collect key operating indicator data in real time, including the read and write interrupt status set by the --status-interval parameter, the data verification value achieved by the --verify=crc32c parameter, and the operation delay statistics recorded by the lat_percentiles parameter. At the service level, the vdbench tool is used to comprehensively monitor operating status data, covering the process survival status tracked by the process_monitor parameter, the memory usage trend recorded by the memory_log parameter, the response time curve collected by the interval parameter, and the error occurrence record counted by the error_logging parameter. Then, the collected indicator data is automatically detected and analyzed for anomalies using preset thresholds (such as lat_threshold=10ms). This achieves the stability verification of the operating status of the device layer and the service layer.

[0183] This solution achieves intelligent protection of system stability during the garbage collection process through a two-dimensional collaborative monitoring mechanism at the device layer and the service layer: on the one hand, by real-time collection of storage device operating indicators and storage service status data, a full-stack monitoring system covering hardware and software is built, which can quickly and accurately locate the specific level of the fault; on the other hand, a closed-loop verification mechanism based on data checksum comparison and error log analysis ensures the integrity and consistency of data operations; at the same time, with the help of trend prediction analysis of key indicators such as memory usage and response time, an active early warning mechanism is established to identify potential system risks in advance and effectively prevent service interruption accidents, thereby significantly improving the business continuity and service reliability of the storage system during critical operations such as garbage collection.

[0184] Robustness verification may include the following steps: receiving an exception injection instruction sent by the external testing tool; parsing the exception injection instruction to obtain a target exception type and trigger parameters, wherein the target exception type is used to characterize the category of exception scenarios simulated during the garbage collection test, and the trigger parameters refer to configurable variables that control the exception simulation behavior; executing a corresponding exception handling process according to the target exception type and the trigger parameters: resuming the garbage collection operation after the exception is handled, and recording the exception handling results.

[0185] Anomaly injection instructions are structured commands initiated by external testing tools to proactively trigger preset anomaly scenarios during the GC process to verify system robustness. In this application, the storage system's control node receives anomaly injection instructions from the external testing tool through a dedicated interface (such as RPC or REST API).

[0186] The target abnormality type refers to the category of abnormal scenarios simulated during the garbage collection test, including: 1. Restart service: Use the fio tool to restart the storage service during the process of reading and writing to the cloud disk, and verify whether the read and write delay of the cloud disk increases, whether the data is correct, whether the reading and writing are normal, and whether the GC is normal; 2. Machine downtime: The fio tool simulates the downtime of the machine where the storage service is located during the process of reading and writing to the cloud disk, and verify whether the read and write delay of the cloud disk increases, whether the data is correct, whether the reading and writing are normal, and whether the GC is normal; 3. Expansion and reduction: The fio tool simulates the expansion / reduction of the storage service during the process of reading and writing to the cloud disk, and verify whether the read and write delay of the cloud disk increases, whether the data is correct, whether the reading and writing are normal, and whether the GC is normal; 4. Node master switching: The fio tool simulates the failure of the control node master node of the storage service during the process of reading and writing to the cloud disk, causing the system to switch to the master, and verify whether the read and write delay of the cloud disk increases, whether the data is correct, whether the reading and writing are normal, and whether the GC is normal during the master switching process.

[0187] Trigger parameters refer to configurable variables that control the behavior of the exception simulation, such as the delay time (the waiting time before the exception is triggered) and the impact range (the service node or data shard that the exception affects). In this application, the system obtains the target exception type and trigger parameters by parsing the JSON / YAML format parameters in the instruction.

[0188] The exception handling process refers to the system's built-in fault simulation logic, for example: calling kill -9 to forcibly terminate a specified service process (simulating a service crash); triggering network packet loss through virtualization tools (such as ChaosMesh) (simulating a network failure).

[0189] Exception handling results include structured logs of the following key indicators: GC task recovery status (success / failure); data consistency check results; and performance fluctuations (such as the IOPS drop ratio).

[0190] In this solution, after receiving the exception injection instruction, the system parses the target exception type and trigger parameters, and executes the corresponding exception handling process based on the target exception type and trigger parameters. For example, when simulating a node downtime, the service process corresponding to the target node identifier is suspended after the corresponding delay time is reached; when it is a service restart instruction, the corresponding garbage collection status is saved according to the service identifier specified by the parameter and the service is restarted; when it is a resource adjustment instruction, the resource quota of the garbage collection task is modified according to the value in the parameter, and so on. After the exception simulation is completed, the system automatically resumes the interrupted GC task, prioritizes processing of unfinished data blocks, records the exception handling results, and generates a test report.

[0191] By dynamically receiving and parsing external test commands, this solution enables the system to accurately simulate complex exception scenarios such as service restarts and node downtime. After handling the exception, it automatically resumes the GC task and generates a detailed report containing performance metrics and data consistency status. This mechanism significantly improves testing efficiency through automated exception injection and result recording, while ensuring that the system maintains GC functional reliability and data integrity in various failure scenarios. This provides a quantifiable and reproducible exception testing solution for distributed storage systems, significantly enhancing the system's fault tolerance and operational controllability.

[0192] Figure 4 This is a block diagram of an embodiment of a garbage collection test device provided in an embodiment of the present application. Figure 4 As shown, the device includes:

[0193] A receiving module 41 is configured to receive a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected;

[0194] A starting module 42, configured to start a garbage data collection operation on the data space corresponding to the target identifier in response to the garbage collection trigger instruction;

[0195] The return module 43 is configured to return a garbage collection completion signal to the external testing tool after the garbage collection is completed.

[0196] In one possible implementation, the startup module is specifically configured to:

[0197] Determine the data space range to be recovered according to the target identifier;

[0198] Scanning data blocks within the data space, and distinguishing valid data blocks from invalid data blocks based on a preset garbage collection determination rule;

[0199] Migrating the valid data block to a pre-allocated new storage location;

[0200] Release the physical storage space occupied by the data blocks that are judged to be invalid.

[0201] In one possible implementation, the startup module is further configured to:

[0202] For each data block, query the reference count of the data block in the metadata, where the reference count refers to the number of times the data block is effectively referenced;

[0203] When the reference count is zero, determining that the data block is an invalid data block;

[0204] When the reference count is greater than zero, reading the physical storage content of the data block and calculating a check value of the physical storage content;

[0205] comparing the checksum to the expected checksum recorded in the metadata;

[0206] If the check value matches the expected check value, determining that the data block is a valid data block;

[0207] In a case where the check value does not match the expected check value, the data block is determined to be an invalid data block.

[0208] In one possible implementation, the device further includes a verification module configured to:

[0209] During the execution of the garbage data recovery operation, multi-dimensional test verification is performed to obtain a verification result, wherein the multi-dimensional test verification includes one or more of function verification, performance verification, stability verification and robustness verification.

[0210] In one possible implementation, the verification module is specifically configured to:

[0211] Obtaining an actual check value of the data stored in the data space corresponding to the target identifier;

[0212] Reading an expected checksum value of the stored data from system metadata;

[0213] Comparing the actual verification value with the expected verification value for consistency;

[0214] When the actual verification value is consistent with the expected verification value, the verification is successful;

[0215] When the actual verification value is inconsistent with the expected verification value, the verification fails.

[0216] In one possible implementation, the verification module is further configured to:

[0217] Counting the total amount of user data to be released in the data space corresponding to the target identifier;

[0218] Obtain the currently configured redundancy policy parameters from the storage system metadata;

[0219] Calculating the expected freed space size according to the redundancy policy parameters and the total amount of user data;

[0220] After garbage collection is completed, the actual freed space size is obtained;

[0221] The space release effect is verified according to the expected released space size and the actual released space size.

[0222] In one possible implementation, the verification module is further configured to:

[0223] During the execution of garbage collection operations, real-time performance indicators are continuously collected as process monitoring data;

[0224] When the process monitoring data is within a preset range, determining that the performance is normal;

[0225] When the process monitoring data is outside a preset range, it is determined that the performance is abnormal.

[0226] In one possible implementation, the verification module is further configured to:

[0227] Before starting the garbage collection operation, collecting the system initial performance index as the first benchmark data, and after the garbage collection operation is completed, collecting the system steady-state performance index as the second benchmark data;

[0228] comparing the process monitoring data with the first reference data and the second reference data respectively;

[0229] When the difference does not exceed the preset tolerance threshold, it is determined that the performance is normal;

[0230] When the difference exceeds a preset tolerance threshold, it is determined to be a performance abnormality.

[0231] In one possible implementation, the verification module is further configured to:

[0232] Real-time collection of operating indicator data of storage devices, including: interruption status records of read and write operations; comparison values ​​of data content verification results; statistics on delay time of read and write operations; and determination of device stability based on the operating indicator data.

[0233] In addition, real-time collection of operating status data of the storage service, the operating status data including: survival status information of the service process; usage and growth trend of memory resources; response time change curve of service requests; error records of data reading and writing; and judgment of service stability based on the operating status data.

[0234] In one possible implementation, the verification module is further configured to:

[0235] Receiving an exception injection instruction sent by the external testing tool;

[0236] Parsing the exception injection instruction to obtain a target exception type and trigger parameters, wherein the target exception type is used to characterize the category of the exception scenario simulated during the garbage collection test, and the trigger parameters refer to configurable variables that control the exception simulation behavior;

[0237] Execute the corresponding exception handling process according to the target exception type and the trigger parameters:

[0238] Resume garbage collection operations after exception handling and record the exception handling results.

[0239] like Figure 5 As shown, an embodiment of the present application provides a device, including a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0240] Memory 113, for storing computer programs;

[0241] In one embodiment of the present application, the processor 111 is configured to implement the garbage collection testing method provided by any one of the aforementioned method embodiments when executing a program stored in the memory 113, including:

[0242] receiving a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected;

[0243] In response to the garbage collection trigger instruction, starting a garbage data collection operation on the data space corresponding to the target identifier;

[0244] After the garbage collection is completed, a garbage collection completion signal is returned to the external testing tool.

[0245] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the garbage collection testing method provided in any of the aforementioned method embodiments are implemented.

[0246] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0247] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Based on this understanding, the above technical solution, in essence, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiment.

[0248] It should be understood that the terms used herein are for the purpose of describing specific example embodiments only and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "comprise", "include", "contain" and "have" are inclusive and therefore specify the presence of stated features, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring them to be performed in the specific order described or illustrated, unless the order of execution is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0249] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.

Claims

1. A garbage collection testing method, characterized in that: The method comprises: receiving a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected; In response to the garbage collection trigger instruction, starting a garbage data collection operation on the data space corresponding to the target identifier; After the garbage collection is completed, a garbage collection completion signal is returned to the external testing tool.

2. The method according to claim 1, characterized in that The initiating a garbage data collection operation on the data space corresponding to the target identifier includes: Determine the data space range to be recovered according to the target identifier; Scanning data blocks within the data space, and distinguishing valid data blocks from invalid data blocks based on a preset garbage collection determination rule; Migrating the valid data block to a pre-allocated new storage location; Release the physical storage space occupied by the data blocks that are judged to be invalid.

3. The method according to claim 2, characterized in that The distinguishing between valid data blocks and invalid data blocks based on a preset garbage collection determination rule includes: For each data block, query the reference count of the data block in the metadata, where the reference count refers to the number of times the data block is effectively referenced; When the reference count is zero, determining that the data block is an invalid data block; When the reference count is greater than zero, reading the physical storage content of the data block and calculating a check value of the physical storage content; comparing the checksum to the expected checksum recorded in the metadata; If the check value matches the expected check value, determining that the data block is a valid data block; In a case where the check value does not match the expected check value, the data block is determined to be an invalid data block.

4. The method according to claim 1, wherein After the garbage data collection operation is started, the method further includes: During the execution of the garbage data recovery operation, multi-dimensional test verification is performed to obtain a verification result, wherein the multi-dimensional test verification includes one or more of function verification, performance verification, stability verification and robustness verification.

5. The method according to claim 4, characterized in that The functional verification includes: Obtaining an actual check value of the data stored in the data space corresponding to the target identifier; Reading an expected checksum value of the stored data from system metadata; Comparing the actual verification value with the expected verification value for consistency; When the actual verification value is consistent with the expected verification value, the verification is successful; When the actual verification value is inconsistent with the expected verification value, the verification fails.

6. The method according to claim 4, characterized in that The functional verification further includes: Counting the total amount of user data to be released in the data space corresponding to the target identifier; Obtain the currently configured redundancy policy parameters from the storage system metadata; Calculating the expected freed space size according to the redundancy policy parameters and the total amount of user data; After garbage collection is completed, get the actual freed space size; The space release effect is verified according to the expected released space size and the actual released space size.

7. The method according to claim 4, characterized in that The performance verification includes: During the execution of garbage collection operations, real-time performance indicators are continuously collected as process monitoring data; When the process monitoring data is within a preset range, determining that the performance is normal; When the process monitoring data is outside a preset range, it is determined that the performance is abnormal.

8. The method according to claim 7, characterized in that The performance verification also includes: Before starting the garbage collection operation, collecting the system initial performance index as the first benchmark data, and after the garbage collection operation is completed, collecting the system steady-state performance index as the second benchmark data; comparing the process monitoring data with the first reference data and the second reference data respectively; When the difference does not exceed the preset tolerance threshold, it is determined that the performance is normal; When the difference exceeds a preset tolerance threshold, it is determined to be a performance abnormality.

9. The method according to claim 4, characterized in that The stability verification includes: Real-time collection of operating indicator data of storage devices, including: interruption status records of read and write operations; comparison values ​​of data content verification results; statistics on delay time of read and write operations; and determination of device stability based on the operating indicator data. In addition, real-time collection of operating status data of the storage service, the operating status data including: survival status information of the service process; usage and growth trend of memory resources; response time change curve of service requests; error records of data reading and writing; and judgment of service stability based on the operating status data.

10. The method according to claim 4, characterized in that The robustness verification includes: Receiving an exception injection instruction sent by the external testing tool; Parsing the exception injection instruction to obtain a target exception type and trigger parameters, wherein the target exception type is used to characterize the category of the exception scenario simulated during the garbage collection test, and the trigger parameters refer to configurable variables that control the exception simulation behavior; Execute the corresponding exception handling process according to the target exception type and the trigger parameters: Resume garbage collection operations after exception handling and record the exception handling results.

11. A garbage collection testing device, characterized in that: The device comprises: A receiving module, configured to receive a garbage collection trigger instruction from an external testing tool, wherein the garbage collection trigger instruction includes a target identifier of data to be collected; a starting module, configured to start a garbage data collection operation on the data space corresponding to the target identifier in response to the garbage collection trigger instruction; The return module is used to return a garbage collection completion signal to the external testing tool after completing garbage collection.

12. A device, characterized in that include: A processor and a memory, wherein the processor is used to execute a garbage collection test program stored in the memory to implement the garbage collection test method according to any one of claims 1 to 10.

13. A storage medium, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the garbage collection test method according to any one of claims 1 to 10.

Images