A multi-tenant solid state disk superblock management method based on a life cycle domain

Abstract

This invention discloses a multi-tenant solid-state drive (SSD) superblock management method and system based on lifecycle domains. It is applicable to shared SSDs that use superblocks as allocation and garbage collection units. First, within a preset sampling period, write and block status information for each tenant is collected to construct tenant lifecycle samples. Lifecycle indicators are calculated, drift detection is performed, and lifecycle domain mapping is updated. Write leading edges are maintained according to lifecycle domains. Write requests are received and written sequentially by domain. New superblocks are assembled when the currently open superblock is nonexistent or full. The parallel layout of superblocks is determined based on domain load, domain popularity, and recent drift status. When the device's free space is below the garbage collection threshold, a garbage collection candidate set is constructed, and affected superblocks are selected. Valid pages are migrated back to their corresponding lifecycle domains, and physical blocks are reclaimed. This invention can reduce the probability of mixed hot and cold data writes, alleviate cross-tenant write amplification and read tail latency coupling, and reduce the number of garbage collections.

Description

Technical Field

[0001] This invention belongs to the field of solid-state storage resource management technology, and particularly relates to a superblock management method and system for multi-tenant shared solid-state drives. Specifically, it relates to a multi-tenant solid-state drive superblock management method and system based on lifecycle domain partitioning, domain-level parallel width control, and domain-priority garbage collection. Background Technology

[0002] With the development of cloud computing and virtualization infrastructure, multi-tenant shared solid-state drives (SSDs) have become a common deployment method for cloud storage systems. These systems typically provide logical isolation to different tenants on the host side using namespaces, logical volumes, or virtual machine disks, but within the SSD, physical resources such as flash channels, chips, dies, and planes are still shared. To improve SSD parallelism and reduce address mapping overhead, existing SSD controllers generally use superblocks as the basic management unit for write allocation and garbage collection.

[0003] While the superblock mechanism can improve throughput, it can also amplify inter-tenant interference in multi-tenant scenarios. When data from different lifecycles is mixed and written to the same superblock, overwrites from hot tenants will cause the superblock to enter garbage collection earlier, while valid pages from cold tenants will be forced to migrate repeatedly during the garbage collection phase, resulting in cross-tenant write amplification and expansion issues. At the same time, garbage collection requires the internal bandwidth and queue resources of multiple parallel units, which will cause a synchronous increase in tail latency for tenants that have not triggered garbage collection, weakening the service quality isolation capability.

[0004] Existing tenant-based strict isolation schemes reduce block filling efficiency and parallel resource utilization, while static hybrid schemes struggle to adapt to the changing phases of multi-tenant workloads. Especially when tenant write intensity, update locality, and data lifetime drift over time, previously reasonable hybrid rules quickly become ineffective, leading to data with significantly different lifecycles coexisting in the same superblock for extended periods, further increasing garbage collection costs and performance fluctuations. Therefore, how to balance parallel performance, garbage collection efficiency, and multi-tenant isolation without excessively increasing controller implementation complexity has become a key challenge in shared SSD management. Summary of the Invention

[0005] The purpose of this invention is to address the problems existing in existing multi-tenant shared solid-state drives, such as mixed hot and cold data writing, write amplification expansion, tail latency coupling, and the inability of static superblock layout to adapt to workload drift, and to provide a multi-tenant solid-state drive superblock management method based on lifecycle domain.

[0006] To achieve the above objectives, the first aspect of this invention discloses a multi-tenant solid-state drive superblock management method based on a lifecycle domain, applied to a shared solid-state drive that uses a superblock as a write allocation unit and a garbage collection unit. The method includes the following steps:

[0007] S1. Collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant.

[0008] S2, according to , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period;

[0009] S3. Calculate the lifecycle index for each tenant based on the lifecycle sample, generate a lifecycle index sequence based on the lifecycle index, and perform drift detection on the lifecycle index sequence, wherein the lifecycle index is used to characterize the data failure rate of the tenant under a unit global write progress.

[0010] S4. Based on the drift detection results and the lifecycle index distribution of the current active tenant set, update the lifecycle domain mapping of each tenant.

[0011] S5. Maintain the write leading edge of the currently open superblock according to the lifecycle domain;

[0012] S6. When a tenant write request is received, query the lifecycle domain to which the tenant belongs, and sequentially append the newly written data to the currently open superblock that is consistent with the lifecycle domain; if the currently open superblock does not exist or is full, reassemble a new superblock and continue writing;

[0013] S7. Statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, determine the target layout from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy, where full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively.

[0014] S8. When the free space of the solid-state drive is lower than the garbage collection threshold, the lifecycle domain of the tenant that triggered the front-end write is used as the target domain. A garbage collection candidate set is constructed in the target domain, and the victimized superblock is selected based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions in the target domain or the solid-state drive reaches the global emergency free water level, it falls back to the global greedy collection path.

[0015] S9. Migrate the valid pages in the victim superblock to the currently open superblock that matches the original lifecycle field identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle field, reassemble the new superblock according to the target layout and complete the writing; after the valid page migration is completed, perform an erase operation on the victim superblock and return the released physical block to the idle physical block pool.

[0016] This invention discloses a multi-tenant solid-state drive superblock management method based on a lifecycle domain. Without altering the underlying flash memory timing model and page-level mapping correctness, it introduces tenant awareness capabilities only in the two critical paths of superblock allocation and garbage collection. This method follows... Figure 1 The process is as follows: First, within a preset sampling period, the write increment, page failure increment, global write increment of the SSD, and block status information of each SSD tenant are collected, and tenant lifecycle samples are constructed accordingly. Then, lifecycle indicators are calculated based on the lifecycle samples, a lifecycle indicator sequence is generated based on the lifecycle indicators, drift detection is performed on the lifecycle indicator sequence, and the lifecycle domain mapping is updated in combination with the lifecycle indicator distribution of the current active tenant set, thereby continuously merging active tenants into a finite number of lifecycle domains.

[0017] After completing the lifecycle domain partitioning, this invention maintains the write front edge of the open superblock for each lifecycle domain. When a tenant write request is received, the controller first queries the lifecycle domain to which the tenant belongs, and then sequentially appends the newly written data to the currently open superblock of the corresponding lifecycle domain. If there is no writable superblock in the lifecycle domain or the currently open superblock is full, a new superblock is reassembled according to the layout strategy currently used in the lifecycle domain. By binding the write front edge to the lifecycle domain, cross-domain mixed writes can be avoided by the foreground path.

[0018] Furthermore, the lifecycle metric is characterized by the failure rate of each tenant under a unit global write progress. satisfy ;in, Indicates tenant The increment of invalid pages caused by host overwrites during the current sampling period. This represents the global host write increment for all tenants of the solid-state drive within the same time period.

[0019] To address the issue that relying solely on tenant write volume in multi-tenant scenarios cannot determine data lifespan, this embodiment uses the failure rate under a unit global write progress as a lifespan indicator. Tenant write volume only reflects how many new pages a tenant has generated, but it cannot distinguish whether these pages are quickly overwritten; while the number of failed pages reflects overwriting status, it cannot be directly compared between different stress stages without considering the SSD's global write progress. Therefore, this embodiment uses the failure rate under a unit global write progress as a lifespan indicator. Record within one sampling period , and And calculate life cycle metrics .in, Indicates tenant Incremental page faults caused by host overwrites This represents the global host write increment for all tenants of the SSD within the same time period. A larger value indicates that the tenant has generated many invalid pages while the overall write progress of the device is relatively slow, resulting in a short data lifecycle; when A lower value indicates that the tenant's data remains valid for a longer period under the same global write progress. This metric can provide a quantitative basis for separating hot, warm, and cold data without reading application semantics.

[0020] Furthermore, in step S3, drift detection is performed on the lifecycle indicator sequence for each tenant. When the difference between the Page-Hinkley cumulative deviation statistic and its historical minimum value is greater than a preset drift threshold... When the mean of the lifecycle metric changes beyond a specified threshold range, the tenant is determined to have experienced lifecycle drift. The tenant's lifecycle domain affiliation is immediately updated, and the current sample that triggered the drift is used as the new stage baseline to restart the statistics.

[0021] The lifecycle metric is characterized by the failure rate under the global write progress of each tenant, thus simultaneously reflecting the data coverage locality and write intensity of that tenant. Preferably, the drift detection adopts an online detection mechanism at the page sampling boundary. When the difference between the Page-Hinkley cumulative deviation statistic and its historical minimum value exceeds a preset drift threshold... If necessary, immediately reset the baseline statistics for the corresponding tenant to avoid long-term influence of historical data on the current judgment.

[0022] To address the issues of excessively fine sampling increasing controller overhead and excessively coarse sampling delaying the identification of tenant changes, this embodiment adopts a reference sampling capacity. This serves as a condition for forming lifecycle samples. For each tenant, the cumulative writes to the current backend path reach... When processing a host page, the controller records the statistics required for the current sample and performs lifecycle metric updates, quantile boundary recalculation, and drift detection in a background control task. This design allows foreground write requests to only incur simple counting and marking overhead, while control logic such as sorting and drift detection is processed in batches in the background, thus reducing the impact on the host I / O critical path.

[0023] Furthermore, in step S4, multiple quantile boundaries are calculated online based on the distribution of lifecycle indicators of the current active tenant set; when a tenant forms a new lifecycle sample, the tenant is mapped to the corresponding lifecycle domain according to the latest quantile boundary; a default lifecycle domain is first assigned to cold-start tenants, and formal classification is completed after the first complete lifecycle sample is formed.

[0024] The boundary of the lifecycle domain is not a preset fixed threshold, but rather the boundary of the quantile is updated in real time based on the distribution of lifecycle indicators of the current active tenant set, in order to maintain the adaptability of the domain division to different sizes and various tenant combinations. Preferably, garbage collection only falls back to the global greedy collection path when there are no suitable candidates in the target lifecycle domain or when the SSD reaches the emergency idle water level; the global greedy collection path is the path that prioritizes the superblock with the fewest effective pages or the lowest normalized replication cost among the global candidate superblocks of the SSD for collection, in order to balance isolation and security.

[0025] To address the issue that tenant access patterns may transition from a hot update phase to a cold add phase or from a cold background phase to a hot update phase, this embodiment performs online drift detection on the lifecycle metric sequence. Specifically, the controller updates the Page-Hinkley cumulative deviation statistic at the page sampling boundary and compares this statistic with its historical minimum value; when the difference between the two exceeds a preset drift threshold... When this occurs, it indicates that the tenant's lifecycle metric mean has deviated from its historical stable phase, and the controller determines that the tenant has experienced lifecycle drift. Once drift is confirmed, the controller restarts statistics using the current sample that triggered the drift as the new phase baseline and updates the tenant's lifecycle domain affiliation. This process prevents samples from older phases from influencing the current classification for an extended period, ensuring that subsequent writes quickly enter a more suitable new lifecycle domain.

[0026] To address the issue that fixed hot and cold thresholds are insufficient to accommodate different tenant combinations, this embodiment employs online updates of lifecycle domains at quantile boundaries. The controller sorts the lifecycle metrics of currently active tenants from smallest to largest value and then updates them according to the number of lifecycle domains. The sorting results are divided into The lifecycle index values ​​between adjacent intervals are used as quantile boundaries. When a tenant forms a new lifecycle sample, the controller compares the tenant's lifecycle index with the latest quantile boundary and maps the tenant to the corresponding lifecycle domain. In this embodiment, the number of lifecycle domains is preferably set to 4; for cold-start tenants that have just entered the system, a default domain is first assigned to ensure that writes can be executed immediately, and formal classification is completed after the first complete lifecycle sample is formed. This mechanism enables the domain boundaries to adaptively adjust with the current set of active tenants, reducing the domain division imbalance caused by a fixed threshold.

[0027] Furthermore, in step S5, the write front edge of the currently open superblock is maintained according to the lifecycle domain, and the corresponding lifecycle domain identifier, write pointer and writable state are recorded for each currently open superblock; in step S6, when the currently open superblock does not exist or is full, physical blocks are selected from the idle physical block pool according to the superblock layout strategy corresponding to the lifecycle domain to assemble a new superblock and continue writing.

[0028] The main problem with existing global write frontiers is that requests from different tenants that are temporally adjacent may be written to the same superblock, even though temporal proximity does not necessarily mean similar data lifecycles. To address this issue, this embodiment maintains an independent currently open superblock for each lifecycle domain, recording the lifecycle domain identifier, write pointer, and writable status within the currently open superblock. When new write data arrives, the controller first queries the tenant's current lifecycle domain and then appends the data to the currently open superblock of that lifecycle domain. If the domain does not have a writable superblock or the currently open superblock is full, the controller selects physical blocks from the idle physical block pool and assembles a new superblock according to the domain's layout strategy. This approach limits the scope of mixed writes to within the same lifecycle domain, reducing the probability of hot and cold data coexisting in the same superblock for extended periods from the source of the write operation.

[0029] Meanwhile, this embodiment does not employ a one-to-one exclusive superblock allocation method per tenant. This is because, when the number of tenants is large or the traffic per tenant is low, strict exclusive allocation would increase the number of open blocks, decrease filling speed, and fragmentate free blocks. This invention allows multiple tenants within the same lifecycle domain to share currently open superblocks because these tenants have similar lifecycle metrics, and their valid pages are more likely to be retained or expire simultaneously in subsequent garbage collection. This design achieves a trade-off between hot and cold isolation and superblock filling efficiency.

[0030] Furthermore, step S7 is as follows:

[0031] S71. Statistically analyze the domain load, domain heat, and drift status within a specified time threshold of each lifecycle domain, and form a superblock layout strategy based on the current set of active lifecycle domains; wherein, the specified time threshold is preferably the two most recent control cycles, the parallel unit is a flash memory resource unit in the solid-state drive that can perform read, write, or erase operations in parallel, the parallel group is a superblock assembly range composed of multiple parallel units, and the idle physical block pool is a set of idle physical blocks in each parallel unit that can be used to assemble superblocks;

[0032] S72: Allocate full-width superblock layout strategy to high-load, high-heat and stable lifecycle domains to improve internal parallel write capability;

[0033] S73. Allocate a quarter-width superblock layout strategy to lifecycle domains that drift within a specified time threshold or simultaneously meet the conditions of low load and low heat, in order to reduce the impact of subsequent garbage collection.

[0034] S74. Assign a half-width superblock layout strategy to lifecycle domains that do not meet the conditions defined in steps S72 and S73. When the target layout is a half-width superblock layout strategy or a quarter-width superblock layout strategy, select the parallel group with the most available free physical block resources under the corresponding width as the local group binding object of the lifecycle domain, and when opening a new superblock, select physical blocks from the free physical block pool of each parallel unit in the parallel group to assemble a new superblock.

[0035] At the domain-level control layer, this invention performs discrete parallel width control based on the domain load, domain heat, and drift state within a specified time threshold for each lifetime domain. For lifetime domains with high load, high heat, and stable state, a full-width superblock layout strategy is preferentially adopted to fully utilize flash parallelism; for lifetime domains with low load, low heat, or drift within a specified time threshold, a half-width or quarter-width superblock layout strategy is adopted to reduce the impact of subsequent garbage collection. This design balances hot domain throughput and cold domain isolation, enabling lifetime domains under different operating states to obtain a more suitable superblock geometry.

[0036] During the garbage collection phase, this invention prioritizes building a candidate set within the lifecycle domain of the triggering tenant and uses a combination of normalized replication cost and residual mixing degree to determine the victimized superblock. By prioritizing candidate superblocks with lower replication costs and lower residual mixing degree, the passive migration of valid pages from cold tenants can be reduced, gradually absorbing the intra-domain mixed writing left over from previous phases. After identifying the victimized superblock, the valid pages within it are migrated back to the currently open superblock with the same lifecycle domain identifier as its original one, and erasure and physical block reclamation are performed after the migration is completed, thereby suppressing cross-tenant expansion while ensuring collection efficiency.

[0037] Solid-state drives (SSDs) are composed of multiple parallel units, and superblocks can employ three discrete parallel widths: full-width, half-width, and quarter-width. A parallel unit is a flash memory resource unit in an SSD that can perform read, write, or erase operations in parallel; a parallel group is the assembly range of a superblock composed of multiple parallel units; and the free physical block pool is the set of free physical blocks from each parallel unit that can be used to assemble a superblock. A full-width layout offers higher parallel write capabilities, but subsequent garbage collection will simultaneously consume a larger range of parallel resources; a quarter-width layout has lower parallel capabilities, but the impact of garbage collection is smaller; the half-width layout falls in between.

[0038] To address the issue that a single superblock width cannot simultaneously satisfy both high throughput and strong isolation, this embodiment statistically analyzes the domain load, domain heat, and drift status within a specified time threshold for each lifecycle domain during each control cycle. Specifically, domain load characterizes the traffic share of the lifecycle domain in the current global write, domain heat characterizes the typical lifecycle indicator level of the lifecycle domain, and drift status characterizes whether the lifecycle domain exceeds a preset drift threshold. The specified time threshold is preferably the two most recent control cycles. When a lifecycle domain is in a high-load, high-heat, and continuously stable state, it indicates that the domain has continuous write requirements and the classification results are reliable. The controller prioritizes using a full-width layout to improve write parallelism. When a lifecycle domain has recently drifted, or simultaneously falls into a low-load and low-heat range, it indicates that the data behavior of the domain is still unstable or the throughput requirement is low. The controller uses a quarter-width layout to limit the impact radius of subsequent garbage collection. The remaining lifecycle domains use a half-width layout as a trade-off between throughput and isolation capabilities.

[0039] Layout switching only affects newly opened superblocks; existing superblocks retain their original layout until they expire naturally or are reclaimed. This restriction prevents the active migration of existing valid pages for immediate layout switching, thus avoiding additional write amplification. For lifecycle domains using half-width or quarter-width layouts, the controller preferentially selects the parallel group with the most available free physical blocks as the current group binding object. This prevents local layouts from consuming a single group of parallel units for extended periods, reducing the risk of local resource overdraft and subsequent reclamation congestion.

[0040] Furthermore, step S8 is as follows:

[0041] S81. When the free space of the solid-state drive is lower than the garbage collection threshold, the current lifecycle domain of the tenant that triggered the front-end write is used as the target domain, and a garbage collection candidate set is preferentially built only within the target domain.

[0042] S82. When there are no candidate superblocks that meet the reclamation conditions within the target domain, or when the solid-state disk reaches the global emergency idle water level, the process reverts to the global greedy reclamation path. The global greedy reclamation path refers to a path that does not limit the lifecycle domain and prioritizes the superblock with the fewest effective pages or the lowest normalized replication cost among the global candidate superblocks of the solid-state disk for reclamation.

[0043] S83. Calculate the normalized replication cost and residual mixing degree for each superblock in the candidate set, and complete the determination of the victimized superblock based on the normalized replication cost and residual mixing degree.

[0044] Furthermore, step S83 is as follows:

[0045] S831. Calculate the normalized replication cost of the candidate superblock, denoted as... ,satisfy ;in, The identifier representing the candidate superblock. This represents the total number of valid pages in the candidate superblock. This represents the total page capacity of the candidate superblock;

[0046] S832. Calculate the residual mixing degree of the candidate superblock, denoted as... ,satisfy ,in, This represents the total number of valid pages in the candidate superblock. This represents the maximum number of valid pages occupied by a single tenant in the candidate superblock. This represents the total page capacity of the candidate superblock;

[0047] S833, Preferred Selection The candidate superblock with the smallest value is selected as the victim superblock; when multiple candidate superblocks have the same smallest value... When retrieving values, select again. The candidate superblock with the smallest value is selected as the victim superblock.

[0048] When the free space on the SSD falls below the garbage collection threshold, the controller prioritizes building a candidate set within the lifecycle domain of the triggering tenant and performs victim superblock selection within that domain. This design addresses the problem that if the superblock with the fewest valid pages is selected across the entire disk every time there is insufficient capacity, the hot tenant triggering garbage collection might force other cold tenants' superblocks to be reclaimed, thus extending the collection cost to non-triggered tenants. By prioritizing the candidate set within the triggering domain, this invention makes it more likely that garbage collection costs will be borne by data with similar lifecycles, thereby improving the service quality isolation between tenants.

[0049] For each superblock in the candidate set, the following two metrics are preferably calculated:

[0050] ,

[0051] ,

[0052] in, The identifier representing the candidate superblock. This represents the total number of valid pages in the candidate superblock. This indicates the maximum number of valid pages for a single tenant within this candidate superblock. This indicates the total page capacity of the superblock.

[0053] Normalized replication cost This measure indicates the proportion of valid pages that need to be migrated when reclaiming the superblock. A lower value means less data needs to be copied before erasing the superblock, resulting in lower direct reclamation overhead. Residual Mixing This value is used to measure the proportion of valid pages remaining in a candidate superblock besides the dominant tenant. The lower the value, the lower the tenant mixing within the superblock, and the easier it is to maintain the data purity within the lifecycle domain after reclamation.

[0054] The selection of victim superblocks is based on a two-level rule. First, selection is made within the target lifecycle domain. The candidate superblock with the smallest value is selected to ensure that the effective page replication cost of this reclamation is low; if multiple candidate superblocks have the same minimum replication cost, further selection is made from these candidate superblocks. The superblock with the lowest value is prioritized for elimination, as it has a lower degree of residual mixing and can be cleanly reclaimed. Through this two-level determination, the present invention retains the advantage of greedy reclamation in reducing replication, while incorporating cross-tenant residual mixing into the selection criteria, thus gradually reducing the mixed-write coupling formed in historical stages.

[0055] After the valid pages in the affected superblock have been migrated, they are preferably written back to the currently open superblock of their original lifecycle domain, so that the migrated pages inherit the original domain identifier. This process aims to prevent the garbage collection path from writing data already organized by domain to other domains, thereby avoiding disruption of the established lifecycle isolation between domain-based writes during the garbage collection process. The controller only falls back to the global greedy garbage collection path when there are no available candidate superblocks in the target domain, or when the SSD reaches the global emergency idle water level. The global greedy garbage collection path is not limited to any lifecycle domain and prioritizes the superblock with the fewest valid pages or the lowest normalized copy cost among the global candidate superblocks on the SSD for garbage collection, ensuring continued progress even under extreme capacity pressure.

[0056] To achieve the above objectives, a second aspect of the present invention discloses a multi-tenant solid-state drive superblock management system based on a lifecycle domain, applied to the aforementioned multi-tenant solid-state drive superblock management method based on a lifecycle domain, the system comprising:

[0057] The incremental acquisition module is used to collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant.

[0058] Lifecycle sample construction module, based on , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period;

[0059] The lifecycle metric calculation module calculates the lifecycle metric for each tenant based on the lifecycle sample, generates a lifecycle metric sequence based on the lifecycle metric, and performs drift detection on the lifecycle metric sequence, wherein the lifecycle metric is used to characterize the data failure rate of the tenant under a unit global write progress.

[0060] The lifecycle domain mapping update module updates the lifecycle domain mapping of each tenant based on the drift detection results and the lifecycle index distribution of the current active tenant set.

[0061] The first maintenance module of the superblock is used to maintain the write leading edge of the currently open superblock according to the lifecycle domain;

[0062] The second maintenance module of the superblock, when receiving a write request from a tenant, queries the lifecycle field to which the tenant belongs, and sequentially appends the newly written data to the currently open superblock that is consistent with the lifecycle field; when the currently open superblock does not exist or is full, it reassembles a new superblock and continues writing.

[0063] The superblock layout strategy determination module is used to statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, the target layout is determined from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy. Here, full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively.

[0064] The target domain selection and determination module is used to select the lifecycle domain of the tenant to which the front-end write is triggered when the free space of the solid-state disk is lower than the garbage collection threshold. The module constructs a garbage collection candidate set within the target domain and selects the victim superblock based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions within the target domain or the solid-state disk reaches the global emergency free water level, the module falls back to the global greedy collection path.

[0065] The superblock migration management module is used to migrate valid pages in the victim superblock to the currently open superblock that is consistent with the original lifecycle domain identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle domain, the new superblock is reassembled according to the target layout and the writing is completed; after the valid page migration is completed, the victim superblock is erased and the released physical block is returned to the idle physical block pool.

[0066] Compared with the prior art, the present invention has the following beneficial effects:

[0067] 1. This invention maps tenants to lifecycle domains through lifecycle metrics and quantile boundaries, and updates domain affiliation in a timely manner when lifecycle metrics are detected to exceed a specified threshold range. This ensures that data with similar lifecycles are preferentially written to the same type of superblock, thereby reducing the probability of hot and cold data being mixed together for a long time from the source.

[0068] 2. This invention binds the write front edge of the currently open superblock to the lifecycle domain, so that newly written data can only enter the currently open superblock corresponding to its lifecycle domain; when the currently open superblock does not exist or is full, a new superblock is assembled according to the corresponding superblock layout strategy. Therefore, the foreground write path will not actively introduce cross-domain mixed writing.

[0069] 3. This invention adjusts the number of parallel units involved in assembly through three superblock layout strategies: full-width, half-width, and quarter-width. High-load and stable lifetime domains can maintain high parallel write capability, while lifetime domains that drift under low load or within a specified time threshold can reduce the impact of garbage collection, thereby reducing the risk of tail latency coupling.

[0070] 4. This invention uses domain-priority garbage collection, normalized replication cost, and residual mixing degree to jointly determine the victim superblock, and writes the migrated valid pages back to the original lifecycle domain of the victim superblock. This can reduce the passive migration of valid pages of cold tenants, improve garbage collection efficiency, and reduce write amplification and expansion in multi-tenant scenarios.

[0071] 5. Through the verification of the embodiments, the present invention can reduce the maximum write amplification on the tenant side by about 8% to 12%, reduce the write amplification dispersion by about 13.6% to 19.0%, reduce the read request P99 latency of read-sensitive tenants by about 9.2% to 18.9%, and increase the aggregate throughput by about 1.6% to 2.2% while reducing the number of garbage collections. Attached Figure Description

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

[0073] Figure 1 This is a flowchart of a multi-tenant solid-state drive superblock management method based on lifecycle domain disclosed in this invention;

[0074] Figure 2 This is a schematic diagram of the core technology process in an embodiment of the present invention, wherein, Figure 2 Part (a) is a schematic diagram of lifecycle sample construction and drift detection. Figure 2 Part (b) is a schematic diagram of maintaining the write frontier by lifecycle domain. Figure 2 The middle (c) section is a schematic diagram of the layout of the full-width, half-width, and quarter-width superblocks. Figure 2 The middle (d) section is a schematic diagram of domain-priority garbage collection and effective page migration.

[0075] Figure 3 This is a simulation diagram comparing write amplification under active multi-tenant load in Embodiment 1 of the present invention.

[0076] Figure 4 This is a simulation diagram of the improved read tail latency under read-sensitive multi-tenant load in Embodiment 2 of the present invention.

[0077] Figure 5 These are simulation diagrams of system cost changes in Embodiments 1 and 2 of the present invention, wherein... Figure 5 Part (a) shows the simulation graph of throughput changes. Figure 5 Part (b) is a simulation diagram of the change in the number of waste collections. Detailed Implementation

[0078] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative effort are within the scope of protection of the present application.

[0079] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0080] Example 1

[0081] like Figure 1 As shown, Figure 1 The method for managing multi-tenant solid-state drives (SSDs) superblocks based on lifecycle domains includes steps S1 to S9. In each of the following embodiments, tenant lifecycle sample construction, lifecycle domain mapping, domain-based writing, domain-level parallel width control, and domain-priority garbage collection are sequentially implemented within the same multi-tenant shared SSD controller. These steps together constitute a complete superblock management method.

[0082] This embodiment discloses a multi-tenant solid-state drive superblock management method based on lifecycle domains, applied to a shared solid-state drive that uses superblocks as write allocation units and garbage collection units. The steps are as follows:

[0083] S1. Collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant.

[0084] S2, according to , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period;

[0085] S3. Calculate the lifecycle metrics for each tenant based on the lifecycle samples, generate a lifecycle metric sequence based on the lifecycle metrics, and perform drift detection on the lifecycle metric sequence. The lifecycle metrics are used to characterize the data failure rate of a tenant under a unit global write progress.

[0086] S4. Based on the drift detection results and the lifecycle index distribution of the current active tenant set, update the lifecycle domain mapping of each tenant.

[0087] S5. Maintain the write leading edge of the currently open superblock according to the lifecycle domain;

[0088] S6. When a write request is received from a tenant, query the lifecycle domain to which the tenant belongs, and sequentially append the newly written data to the currently open superblock that matches the lifecycle domain; if the currently open superblock does not exist or is full, reassemble a new superblock and continue writing;

[0089] S7. Statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, determine the target layout from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy, where full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively.

[0090] S8. When the free space of the SSD is lower than the garbage collection threshold, the lifecycle domain of the tenant that triggered the front-end write is used as the target domain. A garbage collection candidate set is built in the target domain, and the victimized superblock is selected based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions in the target domain or the SSD reaches the global emergency free water level, it falls back to the global greedy collection path.

[0091] S9. Migrate the valid pages in the victim superblock to the currently open superblock that matches the original lifecycle field identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle field, reassemble the new superblock according to the target layout and complete the write; after the valid page migration is completed, perform an erase operation on the victim superblock and return the released physical block to the free physical block pool.

[0092] This embodiment considers a scenario where multiple SSD tenants share the same SSD; hereinafter, SSD tenants are referred to as tenants. Each host I / O request carries a tenant identifier, and the mapping key uses... In this format, the controller maintains the write increment for each tenant. Increment of expired pages Lifecycle indicators, operational statistics, and current lifecycle domain identifier.

[0093] First, we introduce the construction of tenant lifecycle samples and the division of lifecycle domains (corresponding to steps S1 to S4).

[0094] like Figure 2 As shown in section (a), the controller acquires the tenant's local write increment, the tenant's local failed page increment, and the SSD's global write increment during the sampling period, and forms a lifecycle sample accordingly. The attached figures in this section are only for illustrating the process of the three statistics entering the lifecycle index calculation, and the calculation results further entering the drift detection and quantile boundary update process. The specific calculation rules are subject to the following text and formulas.

[0095] To simultaneously reflect local overwrite behavior and overall SSD write pressure, this embodiment uses the failure rate per unit of global write progress as a lifecycle metric. Among these, tenants... Completed within one sampling period After the secondary host page is written, record the corresponding invalid page increment for this stage. and global write increment Then calculate life cycle indicators. .when A larger value indicates that the tenant's data becomes invalid faster within the unit's global write progress, belonging to a hotter update stream; when... A smaller value indicates that the tenant's data has a longer lifespan and is closer to a cold data stream.

[0096] In this embodiment, the controller preferably uses a fixed reference sampling capacity. This serves as a condition for forming lifecycle samples. For each tenant, the cumulative writes to the current backend path reach... When processing individual host pages, only the statistics required for the sample are recorded, while lifecycle metric updates, quantile boundary recalculation, and drift determination are performed in background control tasks, thereby avoiding the execution of sorting and complex control logic on the critical request path.

[0097] To adapt to the phased changes in multi-tenant workloads, this embodiment performs drift detection on the lifecycle metric sequence. Drift detection occurs when the difference between the Page-Hinkley cumulative deviation statistic and its historical minimum exceeds a preset drift threshold. When a tenant's lifecycle has drifted, the controller immediately updates the tenant's lifecycle domain affiliation based on the current sample and resets the corresponding detection status so that subsequent decisions only reflect the behavior of the new stage. The controller also preferably sets a short-term protection flag for tenants that have drifted within the last two control cycles for subsequent domain-level layout control.

[0098] In this embodiment, the number of lifecycle domains is preferably set to four, and the domain boundaries are updated online based on the quantiles of the lifecycle metrics of all active tenants. For cold-start tenants that have just entered the system, a default domain is first assigned to them; after the first complete sample is formed, the formal classification is completed based on the quantile boundaries at that time. This avoids frequent jitter at the request level and allows the domain division to continuously adapt to the current cross-sectional distribution of tenants.

[0099] Next, we will introduce foreground writing and superblock assembly by lifecycle domain (corresponding to steps S5 to S6).

[0100] like Figure 2 As shown in section (b), after completing the lifecycle domain mapping, the tenant does not directly share the same global write frontier. Instead, it first maps to the corresponding lifecycle domain, and then the lifecycle domain points to its currently open superblock. Figure 2 Part (b) also illustrates the process by which the controller reassembles a new superblock and continues writing when the currently open superblock is full or does not exist.

[0101] After lifecycle domain partitioning is completed, the controller maintains a currently open superblock for each lifecycle domain. New data to be written first queries the tenant's current lifecycle domain, and then appends it to the currently open superblock of that lifecycle domain. If there is no writable superblock in the lifecycle domain, or if the currently open superblock is full, a new superblock is reassembled according to the current superblock layout strategy, and sequential writing continues. In this way, cross-domain mixed writes will not actively occur between different lifecycle domains on the foreground write path, while multiple tenants with similar lifecycles within the same lifecycle domain are still allowed to share the same superblock, thus avoiding the decrease in fill efficiency caused by excessive isolation.

[0102] Next, we will introduce domain-level parallel width control (corresponding to step S7).

[0103] like Figure 2 As shown in section (c), this embodiment abstracts the superblock layout into three discrete states: full width, half width, and quarter width. Solid lines in the figure represent parallel units participating in this superblock assembly, while dotted lines represent parallel units not participating in this superblock assembly under this layout strategy. This line type difference is only used to indicate participation relationships and does not represent color, grayscale, or performance magnitude.

[0104] In this embodiment, the solid-state drive (SSD) is composed of multiple parallel units, and the superblock can adopt three discrete parallel widths: full-width layout, half-width layout, and quarter-width layout. The parallel unit is a flash memory resource unit in the SSD that can perform read, write, or erase operations in parallel; the parallel group is the superblock assembly range composed of multiple parallel units; and the free physical block pool is the set of free physical blocks in each parallel unit that can be used to assemble the superblock. The three layouts correspond to all parallel units, half of the parallel units, and one-quarter of the parallel units forming a superblock, respectively. In the partial layout, the controller maintains the corresponding parallel group division and selects physical blocks from the free block pools of each parallel unit within the target parallel group for assembly when opening a new superblock.

[0105] Within each control cycle, the controller statistically analyzes the domain load, domain heat, and drift status within a specified time threshold for each lifecycle domain. Domain load characterizes the proportion of traffic generated by that lifecycle domain in the current global write operation; domain heat characterizes the typical lifecycle indicator level of that lifecycle domain; and drift status characterizes whether the lifecycle domain exceeds a preset drift threshold. The behavior changes are defined by the specified time threshold, which is preferably the two most recent control cycles. When a lifetime domain is under high load, high heat, and a stable state, the controller prioritizes increasing its layout to full width to improve internal parallel write capabilities. When a lifetime domain drifts within the specified time threshold, or simultaneously falls into a low load and low heat range, the controller shrinks it to a quarter width to reduce the impact radius of subsequent garbage collection. The remaining lifetime domains adopt a half-width layout as a trade-off between throughput and isolation.

[0106] It should be noted that layout switching only applies to newly opened superblocks. Existing superblocks retain their original layout until they naturally expire or are reclaimed. This avoids introducing additional data migration overhead for layout switching. For lifecycle domains using half-width or quarter-width layouts, the controller preferably selects the parallel group with the most available free physical blocks as the current group binding object to avoid long-term overdraft of local group resources.

[0107] Finally, we will introduce domain-priority garbage collection and valid page migration (corresponding to steps S8 to S9).

[0108] like Figure 2 As shown in section (d), when garbage collection is triggered in the target lifecycle domain, the controller first constructs a candidate set within that target domain. After calculating the normalized replication cost and residual mixing degree of the candidate superblocks, it selects the victim superblock. Only when there are no candidate superblocks in the target domain or the solid-state disk reaches the emergency idle water level does it backtrack to global greedy collection along the path shown by the dashed line. After selecting the victim superblock, its valid pages are migrated back to the original lifecycle domain, and then the victim superblock is erased and the physical blocks are released.

[0109] When the free space on the SSD falls below the garbage collection threshold, the controller prioritizes building a candidate set within the lifecycle domain of the triggering tenant and performs victim superblock selection within that domain. Each superblock in the candidate set preferably calculates the following two metrics:

[0110] ,

[0111] ,

[0112] in, The identifier representing the candidate superblock. This represents the total number of valid pages in the candidate superblock. This indicates the maximum number of valid pages for a single tenant within this candidate superblock. This indicates the total page capacity of the superblock.

[0113] The victim superblock is preferably determined in the following manner.

[0114] First, within the target lifecycle domain, select the candidate superblock with the lowest replication cost, i.e., select... The one with the lowest residual mixing value is selected. If multiple candidate superblocks have the same minimum replication cost, then the one with the lowest residual mixing value is further selected from these candidate superblocks. The value with the smallest value is selected. Through this two-level judgment, while maintaining the main logic of greedy garbage collection, priority can be given to collecting superblocks with low residual write content within the domain, thereby gradually reducing cross-tenant coupling left over from the historical stage.

[0115] After the valid pages in the affected superblock have been migrated, they are preferably written back to the currently open superblock of their original lifecycle domain. This ensures that the migrated pages inherit the original domain identifier, preventing the garbage collection path from actively introducing new cross-domain mixed writes. The controller only falls back to the global greedy garbage collection path when there are no available candidate superblocks in the target domain, or when the SSD reaches the global emergency idle water level. The global greedy garbage collection path is not limited to the lifecycle domain and prioritizes the superblock with the fewest valid pages or the lowest normalized copy cost among the global candidate superblocks of the SSD for garbage collection, ensuring that the system can still proceed under extreme capacity pressure.

[0116] In this embodiment 1, for a write-active multi-tenant load scenario, the method of the present invention is implemented in a shared solid-state drive simulation environment. The underlying solid-state drive parameters are shown in Table 1.

[0117] Table 1. Solid State Drive Parameter Configuration Table in this Embodiment

[0118]

[0119] In this embodiment, the total number of parallel units is 128, preferably using 4 lifetime domains; reference sampling capacity The preferred page capacity for a half-width superblock layout strategy is 16384 pages; Page-Hinkley slack. Preferred selection Drift threshold Preferred selection .in, Determined by the half-width superblock page capacity, it is not used as an independent tuning parameter; number of lifetime domains. and drift threshold The implementation results of the parameters are shown in Examples 3 and 4, respectively. The comparison schemes include the baseline greedy superblock management schemes BL, SRFTL, EddySuperblock, and the corresponding D1 and D2 two-level strategies of this invention. The synthetic load template used to generate multi-tenant scenarios is shown in Table 2, the real workload candidate pool is shown in Table 3, and the generation rules for write-active tenant scenario W1 and read-sensitive tenant scenario W2 are shown in Table 4.

[0120] Table 2. Synthetic Load Template Table in this Embodiment

[0121]

[0122] Wherein, WS represents the percentage of logical address ranges actually repeatedly accessed by the tenant relative to the tenant's allocated capacity, Hot represents the proportion of hot zones under the Hot-Cold distribution, Read represents the read request ratio, Req represents the request size, and BW-A and BW-B correspond to the two stress points of Mix-A and Mix-B, respectively. Mix-B only increases the write bandwidth of HU and WM, while CA remains unchanged.

[0123] Table 3. Real-world workload characteristics in this embodiment.

[0124]

[0125] Table 4. Multi-tenant scenario generation rule table in this embodiment

[0126]

[0127] The HU slots are selected from HU-A, HU-B, and HU-C; the WM slots are selected from WM-A, WM-B, and WM-C; and the CA slots are preferentially selected from ali_206, ali_215, and ali_188. When the number of CA slots required for an 8T or 10T scenario exceeds the capacity of the primary pool, they are supplemented from mds_0, stg_0, and prxy_0.

[0128] To verify the technical effects of Embodiments 1 and 2, the following embodiments compare the baseline greedy superblock management schemes BL, SRFTL, EddySuperblock, the D1 strategy of the present invention, and the D2 strategy of the present invention. SRFTL adaptively adjusts the superblock organization and reclamation strategy based on runtime load, while EddySuperblock dynamically reorganizes superblocks based on block durability status; neither performs multi-tenant lifecycle domain separation. Table 5 presents the overall comparison results of each scheme in terms of write amplification, read tail latency, and system cost.

[0129] Table 5. Experimental Results of Different Superblock Management Schemes

[0130]

[0131] In Example 1, the active tenant scenario W1 from Table 4 is selected as the input load. This scenario consists of hot update tenant HU, warm update tenant WM, and cold append tenant CA, and four tenant scales of 4T, 6T, 8T, and 10T are constructed respectively. The controller executes on each tenant. Figure 1 Steps S1 to S9, as shown, involve maintaining currently open superblocks according to lifecycle domains during the foreground write phase, selecting superblock layout strategies based on domain load, domain popularity, and drift status during the background control phase, and prioritizing the selection of affected superblocks within the lifecycle domain of the triggering tenant during the garbage collection phase. This embodiment primarily illustrates the implementation of the present invention in suppressing mixed hot and cold data writing and write amplification expansion under active multi-tenant write loads.

[0132] In the steady-state write amplification experiment of Example 1, 10 random configurations were constructed for four scale points: 4T, 6T, 8T, and 10T, and the write amplification results were statistically analyzed per tenant pairing. For each running instance, the write amplification of each tenant was first paired with the results of the corresponding tenant in the baseline scheme BL of the same group, and then the median of all pairing ratios and the percentage of tenants that achieved improvement were calculated. See Table 5 and... Figure 3 As shown, SRFTL and EddySuperblock offer only limited improvements over BL, with median per-run pairings of 0.975–0.977 and 0.959–0.965, respectively. D1 and D2 more consistently reduce the SSD write costs caused by multi-tenant mixed writes, with D1's median per-run pairing of 0.915–0.921 and D2 further decreasing to 0.870–0.880, achieving 100% tenant improvement across all 40 runs. These results demonstrate that the present invention not only reduces write overhead for the most severely affected tenants but also stably covers all write-active tenants across different scales and configurations.

[0133] Example 2

[0134] In Example 2, for read-sensitive multi-tenant load scenarios, while keeping the W1 write-side background unchanged in Example 1, a cold background tenant CA is replaced with a real read-sensitive tenant RM to form the W2 read-sensitive scenario in Table 4; when the 8T or 10T scenario needs to supplement cold background tenants, they are still supplemented from the CA secondary pool in Table 3.

[0135] In this embodiment, under the same tenant vector and address distribution, the bandwidth of HU and WM is switched from BW-A in Table 2 to BW-B to form a high-pressure read-sensitive scenario W2-B, so as to amplify the background garbage collection pressure.

[0136] In this embodiment, read-sensitive tenants (RMs) share the same solid-state drive controller and the same pool of free physical blocks with other write-active tenants. The controller still performs... Figure 1 Steps S1 to S9 are shown as follows: Write increments, failed page increments, and global SSD write increments are collected for the RM and other tenants, and mapped to their corresponding lifecycle domains based on lifecycle metrics; write requests are only appended to the currently open superblock within their respective lifecycle domains; when the background garbage collection pressure in W2-B increases, a candidate set is preferentially constructed within the trigger domain, and valid pages are migrated. This embodiment mainly illustrates the implementation method of the present invention to mitigate the impact of garbage collection activities on read tail latency coupling when read-sensitive tenants exist.

[0137] In the tail delay isolation experiment of Example 2, the high-pressure scenario W2-B was used to observe the correspondence between the garbage collection activity window and the read tail delay spike in the time dimension, and the improvement rate of read request P99 relative to BL for read-sensitive tenants RM was statistically analyzed. (See Table 5 and...) Figure 4 As shown, when garbage collection occurs frequently, the read tail latency of the baseline scheme BL deteriorates significantly. Although SRFTL and EddySuperblock can bring some improvement, their improvement is limited due to the lack of multi-tenant lifecycle domain separation. This invention can more effectively offset this deterioration through lifecycle domain separation and domain-priority collection. Across eight combinations formed by Mix-A, Mix-B, and 4T, 6T, 8T, and 10T, the RM read request P99 improvement rate of D2 relative to BL is 9.2%–18.9%, while that of D1 is 7.5%–16.7%. Under high-pressure Mix-B, the improvement rate of D2 increases from approximately 9.8% for 4T to approximately 18.9% for 10T, indicating that this invention can still stably reduce cross-tenant tail latency coupling under high GC pressure.

[0138] In the system cost experiments of Examples 1 and 2, the combined results of aggregated throughput, GC count, and aggregated foreground write request P99 relative to BL were statistically analyzed. The results show that the present invention does not significantly sacrifice SSD efficiency for isolation. (See Table 5 and...) Figure 5 As shown, in scenario W1, D2 can improve median normalized throughput by 1.9%–2.2% and reduce GC counts by 7.6%–8.3%; D1 can improve throughput by 1.4%–1.5% and reduce GC counts by 3.8%–4.7%. In scenario W2-B, D2 can improve throughput by 1.6%–1.8% and reduce GC counts by 5.5%–6.3%; D1 improves throughput by 1.3%–1.5% and reduces GC counts by 3.4%–4.1%, respectively. Meanwhile, D1 and D2 introduce only about 1%–2% of the aggregate write path P99 cost, demonstrating that this invention can achieve higher throughput and lower background garbage collection workload while maintaining lower write path overhead.

[0139] Example 3

[0140] In this embodiment 3, the parameter for changing the number of lifecycle domains is executed by referring to the solid-state disk parameters, load configuration method, and steps S1 to S9 in embodiment 1, except that the number of lifecycle domains is changed in step S4. and keep Page, And other control conditions remain unchanged. By changing This allows us to verify the impact of lifetime domain partitioning granularity on hot and cold data separation, write amplification, and read tail latency. Specific simulation results are shown in Table 6.

[0141] Table 6. Number of Lifecycle Domains Parameter Implementation Results Table

[0142]

[0143] As can be seen from Table 6, when When the number of lifecycle domains was increased from 2 to 4, the median write amplification ratio per tenant in the W1 scenario decreased from 0.894 to 0.875, and the read request P99 ratio for read-sensitive tenants (RMs) decreased from 0.872 to 0.829, indicating that increasing the number of lifecycle domains can enhance the separation of hot and cold data. Further increasing... The subsequent benefits are no longer obvious, and Both indicators are relatively A slight rebound indicates that too many lifetime domains increase the overhead of maintaining domain-level metadata, open superblocks, and candidate sets. Therefore, this invention preferably adopts... A compromise is reached between the separation effect and the control complexity.

[0144] Example 4

[0145] In this embodiment 4, the drift threshold parameter is changed. The method of the present invention is executed with reference to the solid-state disk parameters, load structure and steps S1 to S9 in embodiment 1, except that the Page-Hinkley drift threshold in step S3 is changed. and maintain the number of lifecycle domains , The page and other control conditions remain unchanged. By changing... This allows us to verify the impact of drift detection sensitivity on the timeliness of lifecycle domain reclassification and placement stability. Specific simulation results are shown in Table 7.

[0146] Table 7. Drift Threshold Parameter Implementation Results Table

[0147]

[0148] As shown in Table 7, when the drift threshold is too small, the lifetime domain affiliation is easily affected by short-term sampling noise and frequently resets; when the drift threshold is too large, tenants may remain in the old lifetime domain even after their behavior has undergone a phase change, thus prolonging the duration of historical mixed writes. This invention preferably adopts... It can achieve a good trade-off between response speed and classification stability.

[0149] In summary, as illustrated in Examples 1 to 4 and Tables 5 to 7, this invention not only effectively suppresses write amplification and tail latency coupling in multi-tenant shared solid-state drives (SSDs) but also does so without sacrificing aggregate throughput. Conversely, by reducing mixed hot and cold data writes and invalid page migrations, this invention maintains a lightweight design while reducing garbage collection frequency and improving overall SSD operating efficiency. Furthermore, the parameter examples demonstrate that the number of lifetime domains S=4 and the drift threshold... It represents a relatively stable value among separation effect, response speed, and control complexity.

[0150] In summary, by organically combining lifecycle domain partitioning, domain-level discrete parallel width control, and domain-priority garbage collection mechanism, this invention can simultaneously ensure isolation, throughput performance, and garbage collection efficiency in multi-tenant shared solid-state drive scenarios, and has high engineering application value.

[0151] Example 5

[0152] This embodiment is based on the lifecycle-domain-based multi-tenant SSD superblock management method disclosed in the above embodiments, and is applied to the above-mentioned lifecycle-domain-based multi-tenant SSD superblock management method, including:

[0153] The incremental acquisition module is used to collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant.

[0154] Lifecycle sample construction module, based on , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period;

[0155] The lifecycle metric calculation module calculates the lifecycle metric for each tenant based on the lifecycle sample, generates a lifecycle metric sequence based on the lifecycle metric, and performs drift detection on the lifecycle metric sequence, wherein the lifecycle metric is used to characterize the data failure rate of the tenant under a unit global write progress.

[0156] The lifecycle domain mapping update module updates the lifecycle domain mapping of each tenant based on the drift detection results and the lifecycle index distribution of the current active tenant set.

[0157] The first maintenance module of the superblock is used to maintain the write leading edge of the currently open superblock according to the lifecycle domain;

[0158] The second maintenance module of the superblock, when receiving a write request from a tenant, queries the lifecycle field to which the tenant belongs, and sequentially appends the newly written data to the currently open superblock that is consistent with the lifecycle field; when the currently open superblock does not exist or is full, it reassembles a new superblock and continues writing.

[0159] The superblock layout strategy determination module is used to statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, the target layout is determined from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy. Here, full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively.

[0160] The target domain selection and determination module is used to select the lifecycle domain of the tenant to which the front-end write is triggered when the free space of the solid-state disk is lower than the garbage collection threshold. The module constructs a garbage collection candidate set within the target domain and selects the victim superblock based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions within the target domain or the solid-state disk reaches the global emergency free water level, the module falls back to the global greedy collection path.

[0161] The superblock migration management module is used to migrate valid pages in the victim superblock to the currently open superblock that is consistent with the original lifecycle domain identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle domain, the new superblock is reassembled according to the target layout and the writing is completed; after the valid page migration is completed, the victim superblock is erased and the released physical block is returned to the idle physical block pool.

[0162] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0163] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. A multi-tenant solid-state drive superblock management method based on lifecycle domain, characterized in that, Applied to shared solid-state drives that use superblocks as write allocation units and garbage collection units, the method includes the following steps: S1. Collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant. S2, according to , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period; S3. Calculate the lifecycle index for each tenant based on the lifecycle sample, generate a lifecycle index sequence based on the lifecycle index, and perform drift detection on the lifecycle index sequence, wherein the lifecycle index is used to characterize the data failure rate of the tenant under a unit global write progress. S4. Based on the drift detection results and the lifecycle index distribution of the current active tenant set, update the lifecycle domain mapping of each tenant. S5. Maintain the write leading edge of the currently open superblock according to the lifecycle domain; S6. When a tenant write request is received, query the lifecycle domain to which the tenant belongs, and sequentially append the newly written data to the currently open superblock that is consistent with the lifecycle domain; if the currently open superblock does not exist or is full, reassemble a new superblock and continue writing; S7. Statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, determine the target layout from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy, where full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively. S8. When the free space of the solid-state drive is lower than the garbage collection threshold, the lifecycle domain of the tenant that triggered the front-end write is used as the target domain. A garbage collection candidate set is constructed in the target domain, and the victimized superblock is selected based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions in the target domain or the solid-state drive reaches the global emergency free water level, it falls back to the global greedy collection path. S9. Migrate the valid pages in the victim superblock to the currently open superblock that matches the original lifecycle field identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle field, reassemble the new superblock according to the target layout and complete the writing; after the valid page migration is completed, perform an erase operation on the victim superblock and return the released physical block to the idle physical block pool.

2. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, The lifecycle metric is characterized by the failure rate of each tenant under the unit global write progress. satisfy ;in, Indicates tenant The increment of invalid pages caused by host overwrites during the current sampling period. This represents the global host write increment for all tenants of the solid-state drive within the same time period.

3. The method for managing multi-tenant solid-state disk superblocks based on lifecycle domains according to claim 2, characterized in that, In step S3, drift detection is performed on the lifecycle indicator sequence for each tenant. When the difference between the Page-Hinkley cumulative deviation statistic and its historical minimum value is greater than a preset drift threshold... When the mean of the lifecycle metric changes beyond a specified threshold range, the tenant is determined to have experienced lifecycle drift. The tenant's lifecycle domain affiliation is immediately updated, and the current sample that triggered the drift is used as the new stage baseline to restart the statistics.

4. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, In step S4, multiple quantile boundaries are calculated online based on the lifecycle index distribution of the current active tenant set; when a tenant forms a new lifecycle sample, the tenant is mapped to the corresponding lifecycle domain according to the latest quantile boundary. For cold-start tenants, a default lifecycle domain is first assigned, and formal classification is completed after the first complete lifecycle sample is formed.

5. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, In step S5, the write front edge of the currently open superblock is maintained according to the lifecycle domain, and the corresponding lifecycle domain identifier, write pointer and writable state are recorded for each currently open superblock; in step S6, when the currently open superblock does not exist or is full, physical blocks are selected from the idle physical block pool according to the superblock layout strategy corresponding to the lifecycle domain to assemble a new superblock and continue writing.

6. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, The process of step S7 is as follows: S71. Statistically analyze the domain load, domain heat, and drift status within a specified time threshold of each lifecycle domain, and form a superblock layout strategy based on the current set of active lifecycle domains; wherein, the specified time threshold is preferably the two most recent control cycles, the parallel unit is a flash memory resource unit in the solid-state drive that can perform read, write, or erase operations in parallel, the parallel group is a superblock assembly range composed of multiple parallel units, and the idle physical block pool is a set of idle physical blocks in each parallel unit that can be used to assemble superblocks; S72: Allocate full-width superblock layout strategy to high-load, high-heat and stable lifecycle domains to improve internal parallel write capability; S73. Allocate a quarter-width superblock layout strategy to lifecycle domains that drift within a specified time threshold or simultaneously meet the conditions of low load and low heat, in order to reduce the impact of subsequent garbage collection. S74. Assign a half-width superblock layout strategy to lifecycle domains that do not meet the conditions defined in steps S72 and S73. When the target layout is a half-width superblock layout strategy or a quarter-width superblock layout strategy, select the parallel group with the most available free physical block resources under the corresponding width as the local group binding object of the lifecycle domain, and when opening a new superblock, select physical blocks from the free physical block pool of each parallel unit in the parallel group to assemble a new superblock.

7. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, The process of step S8 is as follows: S81. When the free space of the solid-state drive is lower than the garbage collection threshold, the current lifecycle domain of the tenant that triggered the front-end write is used as the target domain, and a garbage collection candidate set is preferentially built only within the target domain. S82. When there are no candidate superblocks that meet the reclamation conditions within the target domain, or when the solid-state disk reaches the global emergency idle water level, the process reverts to the global greedy reclamation path. The global greedy reclamation path refers to a path that does not limit the lifecycle domain and prioritizes the superblock with the fewest effective pages or the lowest normalized replication cost among the global candidate superblocks of the solid-state disk for reclamation. S83. Calculate the normalized replication cost and residual mixing degree for each superblock in the candidate set, and complete the determination of the victimized superblock based on the normalized replication cost and residual mixing degree.

8. The method for managing multi-tenant solid-state disk superblocks based on lifecycle domains according to claim 7, characterized in that, The process of step S83 is as follows: S831. Calculate the normalized replication cost of the candidate superblock, denoted as... ,satisfy ;in, The identifier representing the candidate superblock. This represents the total number of valid pages in the candidate superblock. This represents the total page capacity of the candidate superblock; S832. Calculate the residual mixing degree of the candidate superblock, denoted as... ,satisfy ,in, This represents the total number of valid pages in the candidate superblock. This represents the maximum number of valid pages occupied by a single tenant in the candidate superblock. This represents the total page capacity of the candidate superblock; S833, Preferred Selection The candidate superblock with the smallest value is selected as the victim superblock; when multiple candidate superblocks have the same smallest value... When retrieving values, select again. The candidate superblock with the smallest value is selected as the victim superblock.

9. The multi-tenant solid-state drive superblock management method based on lifecycle domain as described in claim 1, characterized in that, The number of lifecycle domains is preferably set to 4, based on the reference sampling capacity. The number of pages written is used as a threshold for forming a lifecycle sample, and The preferred page capacity is the half-width superblock layout strategy; when the tenant's cumulative writes in the current sampling period reach Each host page forms a lifecycle sample; the width state switch only applies to newly opened superblocks, while existing superblocks in the SSD maintain their original parallel width until they naturally fail or are reclaimed.

10. A multi-tenant solid-state drive superblock management system based on a lifecycle domain, characterized in that, A multi-tenant solid-state drive superblock management method based on lifecycle domain, applicable to any one of claims 1-9, wherein the system comprises: The incremental acquisition module is used to collect the local write increments of each SSD tenant within a preset sampling period. Local expired page increment and the global write increment of the solid-state drive within the same time period It also records the tenant identifier, the current open superblock status, and the status of free physical block resources. The following solid-state drive tenant is referred to as tenant. Lifecycle sample construction module, based on , , And the current open superblock state, construct the lifecycle samples of each tenant in the current sampling period; The lifecycle metric calculation module calculates the lifecycle metric for each tenant based on the lifecycle sample, generates a lifecycle metric sequence based on the lifecycle metric, and performs drift detection on the lifecycle metric sequence, wherein the lifecycle metric is used to characterize the data failure rate of the tenant under a unit global write progress. The lifecycle domain mapping update module updates the lifecycle domain mapping of each tenant based on the drift detection results and the lifecycle index distribution of the current active tenant set. The first maintenance module of the superblock is used to maintain the write leading edge of the currently open superblock according to the lifecycle domain; The second maintenance module of the superblock, when receiving a write request from a tenant, queries the lifecycle field to which the tenant belongs, and sequentially appends the newly written data to the currently open superblock that is consistent with the lifecycle field; when the currently open superblock does not exist or is full, it reassembles a new superblock and continues writing. The superblock layout strategy determination module is used to statistically analyze the domain load, domain heat, and drift state within a specified time threshold for each lifecycle domain. Based on the statistically obtained domain load, domain heat, and drift state, the target layout is determined from the full-width superblock layout strategy, half-width superblock layout strategy, and quarter-width superblock layout strategy. Here, full-width, half-width, and quarter-width represent the number of parallel units involved in assembling the superblock as all parallel units, half parallel units, and quarter parallel units, respectively. The target domain selection and determination module is used to select the lifecycle domain of the tenant to which the front-end write is triggered when the free space of the solid-state disk is lower than the garbage collection threshold. The module constructs a garbage collection candidate set within the target domain and selects the victim superblock based on the normalized replication cost and residual mixing degree. When there is no candidate superblock that meets the collection conditions within the target domain or the solid-state disk reaches the global emergency free water level, the module falls back to the global greedy collection path. The superblock migration management module is used to migrate valid pages in the victim superblock to the currently open superblock that is consistent with the original lifecycle domain identifier of the victim superblock; when there is no writable currently open superblock in the corresponding lifecycle domain, the new superblock is reassembled according to the target layout and the writing is completed; after the valid page migration is completed, the victim superblock is erased and the released physical block is returned to the idle physical block pool.

Images