A garbage collection mechanism and system based on dirty data statistics for bcache

Abstract

This invention discloses a garbage collection mechanism and system for bcache based on dirty data statistics, belonging to the field of computer storage system caching technology. The method includes: expanding the bucket data structure, adding atomic dirty data counts, and maintaining the clean_buckets and dirty_buckets linked lists; atomically incrementing the count during cache insertion / update and atomically decrementing the count during write-back / invalidation, and dynamically adjusting the bucket's ownership in the doubly linked list; an independent garbage collection thread monitors the clean_buckets linked list, directly collecting buckets when they are not empty, without scanning the B-tree; after a crash and restart, a full scan of the B-tree is performed to rebuild the count and linked list ownership. This invention achieves zero-scan real-time garbage collection of clean buckets, reducing GC overhead and write amplification, improving cache space utilization and response timeliness, and ensuring crash consistency.

Description

Technical Field

[0001] This invention relates to the field of caching technology for computer storage systems, and in particular to a cache management method and system for the Linux kernel bcache (block device cache) module, especially a garbage collection mechanism processing method and system based on dirty data statistics for bcache. Background Technology

[0002] bcache is a block device caching layer in the Linux kernel that allows the use of fast storage devices such as SSDs as caches for slower storage devices such as HDDs. In bcache, data is organized into fixed-size buckets, which are the basic units for cache space allocation and reclamation.

[0003] The existing bcache garbage collection (GC) mechanism works as follows: 1. Passive triggering: When the cache space utilization reaches the threshold, the GC process is started.

[0004] 2. Validity scan: Only after a full scan of the B+ tree index (Btree) is completed can it be determined whether there are valid cached items in the bucket, thus deciding whether the bucket can be reclaimed.

[0005] 3. Bucket selection: Select candidate buckets for recycling based on a certain algorithm (such as LRU).

[0006] 4. Data migration: Migrate valid cached items to other buckets.

[0007] 5. Bucket Recycling: Empty buckets occupied by invalid data and add them to the free list.

[0008] The main problems with existing technologies are: 1. Large garbage collection delay: GC is a periodic / triggered task, which cannot immediately reclaim those buckets that have become completely invalid (clean), resulting in a decrease in cache space utilization.

[0009] 2. High GC overhead: Each GC requires scanning the entire B-tree, consuming a lot of CPU and memory bandwidth, which seriously affects cache performance under high IO pressure.

[0010] 3. Severe write amplification: Migrating valid data leads to additional write operations, reducing the lifespan of SSD cache devices.

[0011] Untimely response: Under sudden write loads, GC may not be able to reclaim space in time, causing the cache to be full and rejecting writes or passing through, thus losing the cache acceleration effect.

[0012] Existing bcache optimizations mainly focus on: 1. GC algorithm optimization: Improve the bucket selection strategy and prioritize buckets with a high proportion of invalid data.

[0013] 2. Background Pipeline: The GC process is broken down into multiple stages to reduce the impact on foreground I / O.

[0014] 3. Prefetch optimization: Prefetch B-tree nodes during GC scan.

[0015] However, these improvements still cannot avoid the overhead of scanning and B-tree queries, nor can they immediately reclaim completely clean buckets.

[0016] Therefore, there is an urgent need in this field for a bcache garbage collection mechanism that can quickly identify and immediately reclaim completely invalid cache buckets without scanning the entire Btree, reduce GC overhead and write amplification, and improve cache space utilization and response timeliness.

[0017] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0018] The purpose of this invention is to provide a bcache garbage collection mechanism that can quickly identify and immediately reclaim completely invalid cache buckets without scanning the entire Btree, thereby reducing GC overhead and write amplification, and improving cache space utilization and response timeliness.

[0019] To achieve the above objectives, the present invention provides the following solution: A garbage collection mechanism for bcache based on dirty data statistics includes the following steps: S1. Metadata Expansion and Memory State Management: Extend the bcache's struct bucket memory data structure, add a dirty data count field for atomic operations; maintain the clean_buckets and dirty_buckets linked lists; dynamically attach each cache bucket to the corresponding linked list based on its current dirty data count; S2. Runtime dirty data tracking: When inserting or updating the cache, the dirty data count of the corresponding cache bucket is atomically incremented. When data is written back or invalidated, the dirty data count of the corresponding cache bucket is atomically decremented. The ownership of the cache bucket between the clean_buckets list and the dirty_buckets list is dynamically adjusted according to the count change. S3. Real-time recycling mechanism: An independent recycling thread monitors the clean_buckets linked list. When the linked list is not empty, the cache bucket is directly retrieved for recycling. The recycling process does not require querying the Btree and completely bypasses the traditional garbage collection process. S4. Crash Recovery and State Reconstruction: After a system crash and restart, a one-time full scan of the Btree is performed to restore the dirty data counts of each cache bucket, and the cache buckets are reattached to the corresponding linked lists based on the reconstructed count values.

[0020] Optionally, in S1: The dirty data count field is the dirty_keys field of the atomic operation; The clean_buckets linked list is used to store cache buckets with a dirty data count of zero; The dirty_buckets linked list is used to store cache buckets with a dirty data count greater than zero.

[0021] Optionally, S2 specifically includes: When data is inserted into a bucket or the data in the bucket is updated, the dirty data count of that bucket is atomically incremented. If the count changes from zero to a value greater than zero, the bucket is moved from the clean_buckets list to the dirty_buckets list. When the data in the bucket is written back to the underlying backend device, the dirty data count of the corresponding cache bucket is atomically reduced. If the count is reduced to zero, the cache bucket is immediately moved from the dirty_buckets linked list to the clean_buckets linked list. When cached data becomes invalid due to deletion, overwriting, or eviction, the dirty data count of the corresponding cache bucket is atomically decremented. If the count decreases to zero, the cache bucket is immediately moved from the dirty_buckets list to the clean_buckets list.

[0022] Optionally, the step S3 of directly retrieving cache buckets from the clean_buckets linked list for recycling specifically includes: Mark the retrieved cache bucket as available for allocation; Reset the metadata of the cache bucket, including zeroing out the dirty data count; Add the cache bucket to bcache's free bucket allocator.

[0023] Optionally, the crash recovery and state reconstruction in S4 specifically include: After the system crashes and restarts, initialize the dirty data count of all cache buckets to zero; Traverse the entire B-tree index of bcache; For each valid cache key in the B-tree index, the dirty data count of the corresponding cache bucket is atomically incremented according to the cache bucket address it points to; Based on the reconstructed dirty data count, each cache bucket is reattached to the clean_buckets list or the dirty_buckets list.

[0024] Optionally, both the increase and decrease of the dirty data count are performed using atomic operations to ensure the accuracy and consistency of the count in concurrent input / output scenarios.

[0025] A garbage collection system based on dirty data statistics for bcache includes: The metadata extension module is used to extend the bcache's struct bucket memory data structure, adding a dirty data count field for atomic operations; maintaining the clean_buckets and dirty_buckets linked lists; and dynamically attaching each cache bucket to the corresponding linked list based on its current dirty data count. The runtime tracing module is used to atomically increment the dirty data count of the corresponding cache bucket when inserting or updating the cache, and atomically decrement the dirty data count of the corresponding cache bucket when writing back or invalidating data, and dynamically adjust the ownership of the cache bucket between the clean_buckets linked list and the dirty_buckets linked list based on the count change. The real-time recycling module monitors the clean_buckets linked list through an independent recycling thread. When the linked list is not empty, it directly retrieves the cache bucket for recycling. The recycling process does not require querying the B-tree and completely bypasses the traditional garbage collection process. The crash recovery module is used to perform a one-time full scan of the Btree to restore the dirty data count of each cache bucket after the system crashes and restarts, and to reattach the cache buckets to the corresponding linked lists based on the reconstructed count values.

[0026] Optionally, the runtime tracing module is specifically used for: When data is inserted into a bucket or the data in the bucket is updated, the dirty data count of that bucket is atomically incremented. If the count changes from zero to a value greater than zero, the bucket is moved from the clean_buckets list to the dirty_buckets list. When the data in the bucket is written back to the underlying backend device, the dirty data count of the corresponding cache bucket is atomically reduced. If the count is reduced to zero, the cache bucket is immediately moved from the dirty_buckets linked list to the clean_buckets linked list. When cached data becomes invalid due to deletion, overwriting, or eviction, the dirty data count of the corresponding cache bucket is atomically decremented. If the count decreases to zero, the cache bucket is immediately moved from the dirty_buckets list to the clean_buckets list.

[0027] Optionally, the real-time recycling module directly retrieves cache buckets from the clean_buckets linked list for recycling, including: marking the retrieved cache bucket as allocable; resetting the metadata of the cache bucket, including clearing the dirty data count to zero; and adding the cache bucket to bcache's free bucket allocator.

[0028] Optionally, the crash recovery module is specifically used for: After the system crashes and restarts, initialize the dirty data count of all cache buckets to zero; Traverse the entire B-tree index of bcache; For each valid cache key in the B-tree index, the dirty data count of the corresponding cache bucket is atomically incremented according to the cache bucket address it points to; Based on the reconstructed dirty data count, each cache bucket is reattached to the clean_buckets list or the dirty_buckets list.

[0029] Compared with the prior art, the present invention has the following beneficial effects: By maintaining an accurate count of dirty data for each cache bucket in memory and classifying it in real time based on a doubly linked list, there is no need to scan the B-tree index when reclaiming a completely clean cache bucket. The reclamation latency is reduced from milliseconds to microseconds, significantly reducing CPU and memory bandwidth consumption.

[0030] Once a bucket becomes clean (dirty data count is zero) due to data write-back or invalidation, it is immediately moved into the clean list and reclaimed by an independent recycling thread in a timely manner. This avoids the periodic waiting of traditional GC, significantly improves cache space utilization, and reduces cache full events.

[0031] Because clean buckets are reclaimed in real time, there is no need to migrate valid data as in traditional GC, which reduces additional write operations to the SSD caching device and extends the lifespan of the SSD.

[0032] After the system crashes and restarts, a one-time full scan of the Btree is used to reconstruct the dirty data counts and linked list ownership of each bucket. This approach achieves maximum performance during normal operation with minimal runtime overhead, ensuring data consistency and system reliability.

[0033] This invention only requires adding an atomic counting field and maintaining a doubly linked list to the original data structure of bcache, without changing the core architecture of bcache, and is easy to integrate into the existing Linux kernel bcache module. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the 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.

[0035] Figure 1 This is a schematic diagram of the original GC process.

[0036] Figure 2 This is a schematic diagram of the GC optimization process provided in an embodiment of the present invention. Detailed Implementation

[0037] 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 skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] The purpose of this invention is to provide a bcache garbage collection mechanism that can quickly identify and immediately reclaim completely invalid cache buckets without scanning the entire Btree, thereby reducing GC overhead and write amplification, and improving cache space utilization and response timeliness.

[0039] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0040] Example 1: This embodiment provides a real-time recycling method for bcache cache buckets based on dirty data counting.

[0041] First, see Figure 1 This illustrates the original garbage collection (GC) process of existing bcache. When triggered, the existing technology requires a full scan of the B+ tree index (Btree). Only after the entire Btree scan is completed can it determine which buckets can be reclaimed, followed by data migration and bucket reclamation. This process suffers from problems such as high reclamation latency, high GC overhead, severe write amplification, and untimely response.

[0042] See Figure 2 This illustrates the GC optimization process provided by an embodiment of the present invention. The present invention achieves zero-scanning, real-time reclamation of clean buckets by directly maintaining the dirty state of buckets in memory. Specifically, it includes the following steps: S1: Metadata extension and memory state management.

[0043] This step aims to establish the foundation for an in-memory data structure for real-time tracking of the dirty data status of each cache bucket.

[0044] First, the `struct bucket` data structure used to describe each cache bucket in the bcache kernel module is extended. A new field named `dirty_keys` is added to this data structure. This field is defined using an atomic type (such as `atomic_t` in the Linux kernel) to accurately record the number of dirty keys in the cached items of the current bucket. Using atomic operations ensures that updating this count is thread-safe when multiple CPU cores concurrently execute input / output (I / O) requests.

[0045] Secondly, two global doubly linked lists are maintained in memory: the clean_buckets list and the dirty_buckets list. The clean_buckets list is specifically used to link all cache buckets with a dirty_keys count of zero; the dirty_buckets list is used to link all cache buckets with a dirty_keys count greater than zero.

[0046] Finally, a dynamic mapping relationship between bucket states and linked lists is established. Each cache bucket is attached to the corresponding linked list based on its current dirty_kdys count value. When the count value is zero, the bucket belongs to the clean_buckets linked list; when the count value is greater than zero, the bucket belongs to the dirty_buckets linked list. This mapping relationship is dynamically adjusted as the count value changes throughout the bucket's lifecycle.

[0047] S2: Runtime dirty data tracking.

[0048] This step describes how, during normal system operation, the dirty data count of the cache bucket is updated in real time and accurately according to the type of IO operation, and its ownership in the doubly linked list is dynamically maintained.

[0049] (1) Cache insert or update operations.

[0050] When an upper-layer application initiates a write request, data is inserted into a cache bucket that was previously empty, or data in an existing cache bucket is updated, this method first locates the target cache bucket. Then, it uses an atomic operation (such as atomic_inc()) to increment the value of the dirty_keys field of that bucket by 1.

[0051] After performing the increment operation, it is necessary to determine whether the count change has triggered the linked list migration condition: if the dirty_kdys count of the bucket was 0 before the increment operation, and became greater than 0 (usually 1) after the increment operation, it indicates that the bucket has changed from a "clean" state to a "dirty" state. At this time, this method automatically removes the bucket from the clean_buckets linked list and adds it to the tail of the dirty_buckets linked list or other predetermined position.

[0052] (2) Data write-back operation.

[0053] For caches employing a "writeback" strategy, this method locates the corresponding cache bucket after a background thread successfully writes dirty data from the cache bucket back to the underlying slow storage device (such as an HDD). Then, it uses an atomic operation (such as atomic_dec()) to decrement the value of the bucket's dirty_keys field by 1.

[0054] After performing the reduction operation, determine whether migration is needed: if the dirty_keys count of the bucket becomes 0 after the reduction operation, it indicates that all dirty data in the bucket has been written back and the bucket has become "clean". At this time, this method immediately removes the cache bucket from the dirty_buckets linked list and adds it to the tail of the clean_buckets linked list.

[0055] (3) Data invalidation operation.

[0056] When data in a cache bucket becomes invalid due to explicit deletion, being overwritten by new data, or being evicted by a cache eviction algorithm (such as LRU), that cached data becomes invalid. This method also locates the corresponding cache bucket and uses an atomic operation to decrement the dirty_keys count of that bucket by 1.

[0057] Similar to the data write-back operation, if the count becomes 0 after the decrement operation is completed, the bucket is immediately moved from the dirty_buckets list to the clean_buckets list.

[0058] By tracking these three scenarios in real time, this invention ensures that the dirty_keys count and doubly linked list ownership of each cache bucket in memory accurately reflect its true state at any given time.

[0059] S3: Real-time recycling mechanism.

[0060] This step describes how to achieve efficient, zero-scan cache space reclamation using an existing doubly linked list.

[0061] The system starts a separate, low-priority kernel recycling thread. The core task of this thread is to continuously monitor the clean_buckets linked list.

[0062] Once the clean_buckets list is not empty (i.e., there is at least one clean bucket), the recycling thread immediately retrieves a cache bucket from the list (usually from the head of the list). Since the clean_buckets list has already ensured that the dirty_keys count of the bucket is zero, meaning there is no valid or dirty data in the bucket, the recycling process does not require querying or scanning the B-tree index, nor does it require performing any validity checks.

[0063] The recycling thread performs the following recycling operations directly on the clean buckets that have been retrieved: (1) Mark the cache bucket as “allocatable” in the metadata.

[0064] (2) Reset the metadata of the bucket, including clearing the dirty_keys count and clearing other flags.

[0065] (3) Add the bucket number (or pointer) to bcache’s free bucket allocator so that it can be reallocated and used by subsequent cache write requests.

[0066] The entire recycling process was completely bypassed. Figure 1 The traditional GC process shown avoids expensive B-tree scanning and data migration, achieving real-time, low-overhead release of cache space.

[0067] S4: Crash recovery and state reconstruction.

[0068] This step describes how to recover lost dirty data statistics from memory after a system crash and reboot.

[0069] Since the dirty_keys count and doubly linked list exist only in memory, this information will be lost after a system crash. When the system restarts and the bcache module reloads and mounts the cache device, the following recovery process is performed: (1) Initialization: Allocate a struct bucket structure in memory for all buckets and initialize the dirty_kets counter of each bucket to 0. At this time, all buckets are logically considered as "clean" buckets.

[0070] (2) Full scan: In order to reconstruct the real state, a one-time full scan needs to be performed. Traverse the entire B-tree index of bcache, which is persisted on the cache device and records all valid cache keys and the cache bucket addresses they point to.

[0071] (3) Rebuild the counter: For each valid cache key traversed in the B-tree index, parse out the target cache bucket ID it points to. Then, perform an atomic increment operation on the dirty_kets counter of the target bucket.

[0072] (4) Rebuild the linked list: After the B-tree scan is completed, the dirty_keys of all buckets that should have a non-zero count due to containing valid cache items have been correctly accumulated. At this time, according to the final dirty_kets value of each bucket, they are respectively attached to the clean_buckets (count is 0) or dirty_buckets (count is > 0) linked list.

[0073] Through the steps in S4 described above, this method, at the cost of a single scan, correctly recovers memory statistics after a crash, ensuring system consistency and the correct operation of subsequent real-time garbage collection mechanisms.

[0074] In this embodiment, all increment and decrement operations on the dirty_keys count use atomic operations (such as atomic_inc() and atomic_dec()), which is a key implementation detail to ensure the accuracy and consistency of the count in high-concurrency I / O scenarios.

[0075] Example 2: This embodiment provides a bcache garbage collection mechanism processing system based on dirty data statistics for implementing the above method.

[0076] See Figure 2 The system logically includes the following core modules: Metadata Extension Module: This module is responsible for performing the functions described in step S1 of Example 1. Specifically, it modifies the struct bucket data structure during bcache initialization, adding an atomic type dirty_kets field; and is responsible for initializing and managing the clean_buckets linked list and dirty_buckets linked list in memory, as well as implementing the dynamic migration logic of cache buckets between different linked lists.

[0077] Runtime tracing module: This module is responsible for executing the function described in step S2 of Example 1. It modifies the critical paths in the bcache kernel code that handle IO requests (such as cache insertion, update, write-back completion, cache invalidation, etc.), inserts atomic increment and decrement operations on the target bucket dirty_keys count on these paths, and calls the linked list migration interface provided by the metadata extension module according to the count change.

[0078] Real-time recycling module: This module is responsible for performing the function described in step S3 of Example 1. It is implemented as an independent kernel thread that continuously monitors the clean_buckets linked list. Once the linked list is found to be non-empty, a bucket is retrieved from the list, and the standard kernel interface is called to mark it as allocable, reset its metadata, and finally add it to the free bucket allocator. This module does not trigger any B-tree scans or queries during its operation.

[0079] Crash Recovery Module: This module is responsible for performing the function described in step S4 of Example 1. It is triggered when the bcache module loads and attempts to recover an existing cache device. This module first clears the counters of all buckets, then traverses the B-tree indexes on the device, incrementing the counter of the bucket pointed to by each valid cache key encountered. After the traversal is complete, it calls the metadata extension module to rebuild the doubly linked list based on the final count value.

[0080] The working process and principle of each module in this embodiment correspond to the steps described in Embodiment 1, and will not be repeated here. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments.

[0081] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0082] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A garbage collection mechanism based on dirty data statistics in bcache, characterized in that, Includes the following steps: S1. Metadata Expansion and Memory State Management: Extend the bcache's struct bucket memory data structure, add a dirty data count field for atomic operations; maintain the clean_buckets and dirty_buckets linked lists; dynamically attach each cache bucket to the corresponding linked list based on its current dirty data count; S2. Runtime dirty data tracking: When inserting or updating the cache, the dirty data count of the corresponding cache bucket is atomically incremented. When data is written back or invalidated, the dirty data count of the corresponding cache bucket is atomically decremented. The ownership of the cache bucket between the clean_buckets list and the dirty_buckets list is dynamically adjusted according to the count change. S3. Real-time recycling mechanism: An independent recycling thread monitors the clean_buckets linked list. When the linked list is not empty, the cache bucket is directly retrieved for recycling. The recycling process does not require querying the Btree and completely bypasses the traditional garbage collection process. S4. Crash Recovery and State Reconstruction: After the system crashes and restarts, a one-time full scan of the Btree is performed to restore the dirty data count of each cache bucket, and the cache buckets are reattached to the corresponding linked lists based on the reconstructed count values. S2 specifically includes: When data is inserted into a bucket or the data in the bucket is updated, the dirty data count of that bucket is atomically incremented. If the count changes from zero to a value greater than zero, the bucket is moved from the clean_buckets list to the dirty_buckets list. When the data in the bucket is written back to the underlying backend device, the dirty data count of the corresponding cache bucket is atomically reduced. If the count is reduced to zero, the cache bucket is immediately moved from the dirty_buckets linked list to the clean_buckets linked list. When cached data becomes invalid due to deletion, overwriting, or eviction, the dirty data count of the corresponding cache bucket is atomically decremented. If the count decreases to zero, the cache bucket is immediately moved from the dirty_buckets list to the clean_buckets list.

2. The garbage collection mechanism based on dirty data statistics in bcache according to claim 1, characterized in that, In S1: The dirty data count field is the dirty_keys field of the atomic operation; The clean_buckets linked list is used to store cache buckets with a dirty data count of zero; The dirty_buckets linked list is used to store cache buckets with a dirty data count greater than zero.

3. The garbage collection mechanism based on dirty data statistics in bcache according to claim 1, characterized in that, The S3 step of directly retrieving cache buckets from the clean_buckets linked list for recycling specifically includes: Mark the retrieved cache bucket as available for allocation; Reset the metadata of the cache bucket, including zeroing out the dirty data count; Add the cache bucket to bcache's free bucket allocator.

4. The garbage collection mechanism based on dirty data statistics in bcache according to claim 1, characterized in that, The crash recovery and state reconstruction in S4 specifically include: After the system crashes and restarts, initialize the dirty data count of all cache buckets to zero; Traverse the entire B-tree index of bcache; For each valid cache key in the B-tree index, the dirty data count of the corresponding cache bucket is atomically incremented according to the cache bucket address it points to; Based on the reconstructed dirty data count, each cache bucket is reattached to the clean_buckets list or the dirty_buckets list.

5. The garbage collection mechanism based on dirty data statistics in bcache according to claim 1, characterized in that, The increase and decrease of the dirty data count are both performed using atomic operations to ensure the accuracy and consistency of the count in concurrent input / output scenarios.

6. A garbage collection mechanism system based on dirty data statistics using bcache, characterized in that, include: The metadata extension module is used to extend the bcache's struct bucket memory data structure, adding a dirty data count field for atomic operations; maintaining the clean_buckets and dirty_buckets linked lists; and dynamically attaching each cache bucket to the corresponding linked list based on its current dirty data count. The runtime tracing module is used to atomically increment the dirty data count of the corresponding cache bucket when inserting or updating the cache, and atomically decrement the dirty data count of the corresponding cache bucket when writing back or invalidating data, and dynamically adjust the ownership of the cache bucket between the clean_buckets linked list and the dirty_buckets linked list based on the count change. The real-time recycling module monitors the clean_buckets linked list through an independent recycling thread. When the linked list is not empty, it directly retrieves the cache bucket for recycling. The recycling process does not require querying the B-tree and completely bypasses the traditional garbage collection process. The crash recovery module is used to perform a one-time full scan of the Btree to restore the dirty data count of each cache bucket after the system crashes and restarts, and to reattach the cache buckets to the corresponding linked lists based on the reconstructed count values. The runtime tracing module is specifically used for: When data is inserted into a bucket or the data in the bucket is updated, the dirty data count of that bucket is atomically incremented. If the count changes from zero to a value greater than zero, the bucket is moved from the clean_buckets list to the dirty_buckets list. When the data in the bucket is written back to the underlying backend device, the dirty data count of the corresponding cache bucket is atomically reduced. If the count is reduced to zero, the cache bucket is immediately moved from the dirty_buckets linked list to the clean_buckets linked list. When cached data becomes invalid due to deletion, overwriting, or eviction, the dirty data count of the corresponding cache bucket is atomically decremented. If the count decreases to zero, the cache bucket is immediately moved from the dirty_buckets list to the clean_buckets list.

7. The bcache garbage collection mechanism processing system based on dirty data statistics according to claim 6, characterized in that, The real-time recycling module directly retrieves cache buckets from the clean_buckets linked list for recycling, including: marking the retrieved cache bucket as allocable; resetting the metadata of the cache bucket, including clearing the dirty data count to zero; and adding the cache bucket to bcache's free bucket allocator.

8. The bcache garbage collection mechanism processing system based on dirty data statistics according to claim 6, characterized in that, The crash recovery module is specifically used for: After the system crashes and restarts, initialize the dirty data count of all cache buckets to zero; Traverse the entire B-tree index of bcache; For each valid cache key in the B-tree index, the dirty data count of the corresponding cache bucket is atomically incremented according to the cache bucket address it points to; Based on the reconstructed dirty data count, each cache bucket is reattached to the clean_buckets list or the dirty_buckets list.

Images