Storage management method, storage device, and storage medium

Abstract

The application discloses a storage management method, a storage device and a storage medium. The method comprises reading the storage medium type and the life state of each logical storage unit through a standard interface protocol of the storage device. The storage device is divided into multiple logical storage units. Each logical storage unit corresponds to a physical storage area belonging to a storage medium type. The storage medium type and the life state of each logical storage unit are predefined in a data structure conforming to the standard interface protocol. In one aspect, in response to a data write request, the data to be written is written into the corresponding logical storage unit based on the storage medium type and the life state of each logical storage unit. In another aspect, a source logical storage unit triggering a migration condition is determined based on the life state of each logical storage unit, and a target logical storage unit is determined based on the storage medium type and the life state, so as to migrate the data in the source logical storage unit to the target logical storage unit.

Description

Technical Field

[0001] This application relates to the field of data storage, and more particularly to a storage management method, storage device, and storage medium. Background Technology

[0002] To achieve a better balance between performance, cost, and capacity, modern storage devices generally adopt a hybrid media architecture, integrating multiple storage media with significant differences in lifespan, access characteristics, and unit cost within the same hardware to meet different levels of data storage needs. However, currently, terminals cannot perceive the status of each storage media. This lack of perception prevents terminals from accurately mapping data to the most suitable media based on its hot / cold characteristics, and also makes it difficult to implement differentiated data scheduling between different logical units. Furthermore, current wear leveling and data management rely entirely on the device firmware for closed-loop execution, with no terminal intervention. This results in frequently accessed hot data often being mistakenly written to short-lifespan media, accelerating its aging, while long-lifespan media remain idle for extended periods due to their inability to handle active workloads. Consequently, the overall lifespan potential and performance advantages of hybrid media cannot be fully realized. Summary of the Invention

[0003] This application proposes a storage management method, a storage device, and a storage medium, aiming to solve the technical problems in the prior art where improper data placement, uneven wear, and limited overall device lifespan are caused by the terminal's inability to perceive the status of each storage medium within the storage device. Accordingly, the technical solution of this application is as follows: In a first aspect, embodiments of this application provide a storage management method applied to an electronic terminal equipped with a storage device, wherein the storage device has at least two types of storage media, and the method includes: In response to a data write request, the storage medium type and lifetime status of each logical storage unit in the storage device are obtained from the record; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type; the record is periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol; In response to a data write request, the data to be written is allocated to the corresponding target logical storage unit for storage based on the storage medium type and lifetime status of each logical storage unit.

[0004] Secondly, embodiments of this application provide a storage management method applied to an electronic terminal equipped with a storage device, wherein the storage device has at least two types of storage media; the method includes: The storage medium type and lifetime status of each logical storage unit in the storage device are obtained from the records; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type; the records are periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol; Based on the lifetime status of each logical storage unit, the logical storage unit that triggers the migration condition is determined, and the logical storage unit that meets the migration condition is determined as the source logical storage unit. Based on the storage medium type and lifetime status of each logical storage unit, at least one target logical storage unit is determined from the storage device as the data migration object of the source logical storage unit; Data is moved from the source logical storage unit to the target logical storage unit.

[0005] Thirdly, embodiments of this application provide a storage device having at least two types of storage media; the storage device is divided into multiple logical storage units, each of which corresponds to a physical storage area in the storage device belonging to a storage media type; the storage device is configured with a standard interface protocol for access by electronic terminals, and defines the storage media type and lifetime status corresponding to each logical storage unit in a local data structure conforming to the standard interface protocol, so that the electronic terminal can read it through the standard interface protocol.

[0006] Fourthly, embodiments of this application provide a computer-readable storage medium for storing one or more computer instructions, which, when executed, implement the storage management method as described in the first aspect.

[0007] This application's embodiments divide the storage device into multiple logical storage units. Each logical storage unit corresponds to a physical storage area within the storage device belonging to a specific storage medium type. The storage medium type and lifetime status of each logical storage unit are predefined in a data structure conforming to a standard interface protocol within the storage device. An electronic terminal can read this data structure by issuing management commands through the standard interface protocol, thereby obtaining the medium type and lifetime status information corresponding to each logical storage unit. Based on this, the electronic terminal reads the storage medium type and lifetime status of each logical storage unit in the storage device through the standard interface protocol, and obtains the status information of its corresponding physical storage area through the logical storage unit. This allows for a comprehensive understanding of the medium distribution and lifetime status of each physical storage area within the storage device, thus establishing a global understanding of the internal state of the storage device. When responding to a data write request, the electronic terminal allocates the data to be written to the corresponding target logical storage unit based on the storage medium type and lifespan of each logical storage unit. For example, frequently accessed hot data is stored in logical storage units corresponding to long-life media, while infrequently accessed cold data is stored in logical storage units corresponding to high-capacity media. This achieves differentiated data placement based on media adaptation during the write phase, preventing short-life media from prematurely wearing down due to carrying hot data. When a logical storage unit that triggers migration conditions is determined based on the lifespan of each logical storage unit, the electronic terminal identifies the logical storage unit that meets the migration conditions as the source logical storage unit. Based on the storage medium type and lifespan of each logical storage unit, it identifies at least one target logical storage unit from the storage device as the data migration object for the source logical storage unit. Subsequently, the data in the source logical storage unit is migrated to the target logical storage unit. For example, hot data in the source logical storage unit can be migrated to a logical storage unit with a more sufficient or suitable lifespan, while cold data from other logical storage units is migrated into the source logical storage unit to fill its storage space, thereby achieving proactive wear leveling across logical storage units. Through the media adaptation placement and migration phases of the above-mentioned writing stage and the cross-logical storage cell balanced scheduling, this application enables electronic terminals to fully utilize the characteristics and advantages of various media, allowing long-life media to undertake high-frequency writing to extend overall durability, and allowing large-capacity media to carry cold data to improve space utilization. This effectively avoids the unbalanced state where some media are over-worn while others are idle, significantly improving the overall lifespan and performance potential of the storage device, thereby overcoming the storage performance bottleneck caused by the passive reliance of electronic terminals on firmware closed-loop management in the prior art. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram illustrating the process of applying the storage management method of this application to data writing.

[0010] Figure 2 This is a schematic diagram illustrating the process of performing lifetime management in the storage management method of this application embodiment.

[0011] Figure 3 This is a schematic diagram illustrating the process of applying the storage management method of this application to data migration.

[0012] Figure 4 This is a schematic diagram illustrating the process of performing wear leveling across logical storage cells in the storage management method of this application embodiment.

[0013] Figure 5 This is a schematic diagram of the architecture of the storage management method of this application applied to an electronic terminal.

[0014] Figure 6 This is a schematic diagram of the structure of a storage device according to an embodiment of this application.

[0015] Figure 7 This is a schematic diagram of the storage management device used for data writing in an embodiment of this application.

[0016] Figure 8 This is a schematic diagram of the storage management device used for data migration according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] Constrained by the inherent limitations of existing storage device standard interface protocols (such as NVMe (Non-Volatile Memory Fast Channel), SATA (Serial Advanced Technology Accessories), and UFS (Universal Flash Storage), terminal operating systems and upper-layer applications can only obtain a unified Logical Block Address (LBA) view, completely unable to perceive the physical media type bound to each underlying logical storage unit (e.g., storage areas with different durability and performance levels), let alone obtain its dynamic lifespan and health status information. This fundamental lack of perception capability exposes serious defects on two levels against the backdrop of the increasing prevalence of hybrid media storage architectures.

[0019] First, at the data placement strategy level, since the terminal is completely unaware of the physical properties of the underlying medium, it cannot accurately map frequently updated hot data to high-durability, low-latency fast media based on the hot and cold characteristics of the data, such as access frequency, modification frequency, read-write ratio, and expected lifespan. Nor can it reasonably divert infrequently accessed cold data to large-capacity, low-cost, slow media. As a result, data storage becomes completely randomized by the black-box algorithm inside the firmware, and it is impossible to achieve the optimal matching between application-level semantics and physical resources.

[0020] Secondly, regarding wear leveling and lifespan management, current wear leveling mechanisms rely entirely on the device firmware to execute independently within a closed loop. The firmware distributes write operations evenly across physical blocks using static rotation or dynamic migration algorithms to delay overall failure. However, this closed-loop process completely excludes the terminal from the decision-making chain. The operating system has no way of knowing which physical blocks are under excessive write pressure, nor does it have the authority to actively intervene in the firmware's scheduling strategy. The direct consequence is that high-frequency hot data at the business level, after being randomly allocated by the firmware, is often frequently written to short-lifespan, low-endurance media. This causes such media to quickly exhaust their write / erase allowances before reaching their designed lifespan, resulting in premature bad blocks or even complete disk failure. Meanwhile, high-endurance, long-lifespan media, due to the firmware's conservative load-distribution strategy, remain under low load or even completely idle for extended periods. Their superior write performance and lifespan potential, several times greater than that of low-end media, cannot handle any active data, resulting in a severe waste of valuable hardware resources. Ultimately, the peak performance, total bytes written, and unit cost advantages promised by hybrid storage devices at the time of design were greatly diminished due to the irrational state of "blind writing" and "idleness" coexisting. The service life of the entire system was forced to be shortened, maintenance and replacement costs increased significantly, and the expected balance between performance, cost, and capacity was completely lost.

[0021] In view of this, this application proposes a storage management method, storage device, and storage medium. This solution can be applied to various electronic terminals equipped with storage devices, such as server hosts, personal computers, and smartphones. The storage devices include, but are not limited to, solid-state drives (SSDs) and universal flash memory (UFS) using hybrid media architectures. The core concept of this application is to break the closed model of traditional storage management. By extending the data structure in the standard protocol of storage devices, the media type and lifetime status information corresponding to each logical storage unit are made available to the electronic terminal at the protocol level. This allows the electronic terminal to obtain the above information through standard protocol commands, thereby establishing a global understanding of the media distribution and lifetime status of each physical storage area within the storage device. Based on this understanding, the electronic terminal can differentiate data placement according to the media type and remaining lifetime of each logical storage unit during the data writing phase, directing data with different access frequencies to the most suitable medium. Simultaneously, when the lifetime status of each logical storage unit triggers migration conditions, the electronic terminal can proactively initiate cross-logical storage unit data migration, achieving wear-leveling scheduling from a global perspective. The technical solutions of various embodiments of this application will be described in detail below with reference to the accompanying drawings. Specific implementation examples will be given for different types of media characteristics and typical service load scenarios to facilitate understanding.

[0022] On the one hand, one embodiment of this application provides a storage management method applied to the electronic terminal side, which mainly involves storage control and management during the data writing process. Figure 1 The flowchart of this storage management method includes the following steps: S101, in response to a data write request, retrieves the storage medium type and lifetime status of each logical storage unit in the storage device from the record; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type; the record is periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol.

[0023] In this embodiment, the standard interface protocol refers to the interface specification followed by the electronic terminal and the storage device for communication. Its specific type depends on the hardware type of the storage device. For example, when the storage device is a SolidState Drive (SSD), the standard interface protocol can be the Non-Volatile Memory Fast Channel (NVMe) protocol; when the storage device is a Universal Flash Storage (UFS) device, the standard interface protocol can be the UFS protocol. A logical storage unit is a logical address space divided within the storage device. Each logical storage unit has an independent identifier (which is the namespace ID, or NSID, under the NVMe protocol), allowing the electronic terminal to address and access it through the standard interface protocol. In the NVMe protocol system, each namespace corresponds to an independent logical storage unit, and both maintain consistency in the granularity of the logical address space division. In the UFS protocol system, a logical storage unit corresponds to an independently addressable logical unit in a universal flash storage device. For consistency, this application refers to the addressable logical address space under both protocol systems as a logical storage unit. A physical storage area is the physical medium space in a storage device that is actually used to store data. Multiple physical blocks belonging to the same type of storage medium together constitute a physical storage area. This physical storage area corresponds to a logical storage unit, so that electronic terminals can indirectly operate the physical storage area behind it by accessing the logical storage unit.

[0024] Storage medium type refers to the type of storage medium used in the physical storage area. Different types of storage media differ significantly in terms of the number of bits carried per unit storage cell, the maximum number of erase / write cycles, read / write speed, storage density, and cost. Examples include Single-Level Cell (SLC) storage media, Multi-Level Cell (MLC) storage media, Triple-Level Cell (TLC) storage media, and Quad-Level Cell (QLC) storage media. The storage device in this application may include at least two of the above-mentioned storage medium types. Lifetime status is used to characterize the remaining lifespan of the physical storage area corresponding to the logical storage cell. In this embodiment, lifetime status specifically includes a normalized remaining lifetime percentage, as well as auxiliary information such as the maximum number of erase / write cycles, the current average number of erase / write cycles, and lifetime status flags. This information together constitutes a complete description of the lifetime status of the logical storage cell. The normalized remaining lifetime percentage eliminates the incomparability of values ​​caused by differences in the maximum number of erase / write cycles for different media types. This allows electronic terminals to quantify the wear and tear of each logical storage unit on a uniform percentage scale. The specific calculation method and meaning are explained in the formula section of the lifetime table below. The data structure of a standard interface protocol refers to the data organization form defined in the standard interface protocol, used to transmit specific information between the electronic terminal and the storage device. For example, the Identify Namespace data structure in the NVMe protocol and the descriptor data structure in the UFS protocol are data structures that perform information transmission functions under their respective protocol systems. In this embodiment, the storage media type and lifetime status of each logical storage unit are predefined in the above data structure, allowing the electronic terminal to obtain this information simply by issuing standard management commands through the standard interface protocol, without relying on any vendor-defined proprietary interfaces or out-of-band management channels.

[0025] In the specific implementation process, this embodiment adopts the corresponding read path according to the different standard interface protocols followed by the storage device.

[0026] When the storage device is a solid-state drive (SSD) and the standard interface protocol is NVMe, the electronic terminal obtains the storage media type and lifetime status of each logical storage unit by issuing an "Identify Namespace" command to the storage device. This command is a standard management command defined in the NVMe protocol. The electronic terminal submits this command to the storage device through the Admin Submission Queue. After processing the command, the storage device returns the requested "Identify Namespace" data structure through the Admin Completion Queue. This data structure defines fields corresponding to the storage media type and lifetime status of each logical storage unit. The electronic terminal can obtain the storage media type and lifetime status of each logical storage unit by reading the corresponding fields from this data structure. Taking the NVMe protocol as an example, this embodiment extends the Identify Namespace data structure by adding the following key information to the Vendor Specific and Reserved fields: Media Type, which indicates the type of media bound to the underlying logical storage unit, such as 0x01 for SLC, 0x02 for TLC, and 0x03 for QLC; Normalized Lifetime Remaining, which uses a value from 0 to 100 to represent the remaining lifespan, where 100 represents a brand new state and 0 represents the lifespan exhausted. This normalized remaining lifetime percentage is the core quantitative indicator of the aforementioned lifespan status; Maximum PE Cycle for the media; Current Average PE; and Lifetime Status Flag, which indicates whether the logical storage unit has exceeded various preset thresholds.

[0027] When the storage device is a general-purpose flash memory storage device and the standard interface protocol is the UFS protocol, the electronic terminal reads the descriptor data structure of the storage device through the UFS protocol. This descriptor data structure also defines fields corresponding to the storage medium type and lifespan status of each logical storage unit. For example, the DeviceHealth Descriptor in the UFS protocol contains multiple fields used to indicate the storage device's lifespan warning status and the percentage of its lifespan already used. The electronic terminal can read this descriptor data structure through a query request in the UFS protocol and parse out the storage medium type and lifespan status information of each logical storage unit from it.

[0028] After issuing management commands via standard interface protocols (such as the IdentifyNamespace command for NVMe or a query request for UFS), the electronic terminal parses the aforementioned extended fields from the returned data structure to obtain the complete media attributes and real-time lifetime information of the logical storage unit. The entire acquisition process has extremely low overhead and can be executed frequently without affecting the normal read and write performance of the storage device. It should be noted that the electronic terminal periodically performs the above acquisition operation according to a preset cycle and records the storage media type and lifetime status of each logical storage unit in a locally maintained record. This allows the electronic terminal to directly obtain the required information from this record instead of issuing temporary management commands to the storage device when responding to subsequent data write requests. This avoids introducing additional protocol interaction overhead in the critical path of each write operation, ensuring the processing efficiency of write requests.

[0029] After obtaining the storage medium type and lifetime status of each logical storage unit through the above method, this embodiment maintains a lifetime table on the electronic terminal side to record the above information. This lifetime table is a specific implementation of the aforementioned "record". As an example, the lifetime table may include fields such as the identifier (NSID) of each logical storage unit, its media type, maximum number of erase / write cycles (PE_max), current average number of erase / write cycles (PE_cur), normalized remaining lifetime percentage (R), lifetime status flag, and last update time (update_time). Table 1 below shows an example of the lifetime table maintained by the electronic terminal at a certain moment: Table 1: Electronic Terminal Lifespan Table

[0030] Wherein, the normalized remaining lifetime R is determined according to the formula: The calculation is obtained. In this formula, This indicates the maximum number of erase / write cycles for the storage medium type corresponding to the logical storage unit. The value is filled in by the storage device firmware according to the chip specifications. For example, the maximum number of erase / write cycles for SLC media is about 100,000, for TLC media it is about 3,000, and for QLC media it is about 1,000. This indicates the average number of erase / write cycles for each physical block within the logical storage unit, calculated in real-time by the storage device firmware. R represents the normalized remaining lifetime percentage, ranging from 0 to 100, where 100 indicates the logical storage unit is brand new and unwritten, and 0 indicates its lifetime is completely exhausted. Through this normalization process, the incomparability caused by differences in the maximum number of erase / write cycles for different media types is effectively eliminated, allowing electronic terminals to quantify the wear and tear of each logical storage unit on a uniform percentage scale, thus providing a consistent comparison benchmark for subsequent scheduling decisions. Each bit of the lifetime status flag corresponds to a trigger state for different alert levels. For example, bit 0 set to 1 indicates the remaining lifetime of the logical storage unit has fallen below the warning threshold, bit 1 set to 1 indicates it has fallen below the migration threshold, and bit 2 set to 1 indicates it has fallen below the read-only threshold. Since the wear and tear of each physical storage area inside the storage device changes continuously with the ongoing write operations, the electronic terminal needs to periodically reread the storage medium type and lifespan status of each logical storage unit through the standard interface protocol according to a preset cycle, and update the corresponding records in the lifespan table. This ensures that the maintained lifespan information is consistent with the actual situation inside the storage device, providing an accurate data basis for subsequent data placement and wear leveling decisions.

[0031] Furthermore, the electronic terminal in this embodiment can also predict the remaining lifetime trend of each logical memory unit based on historical data, so as to identify logical memory units that may be about to trigger migration conditions in advance, thereby transforming passive response into proactive prevention and reserving a more sufficient time window for wear leveling operations. For example, the electronic terminal can calculate the lifetime reduction of the unit in each acquisition cycle based on the normalized remaining lifetime percentage historical data recorded in the most recent N acquisition cycles, and then calculate its average reduction rate, i.e., the reduction in the normalized remaining lifetime percentage per unit time. Based on the latest normalized remaining lifetime percentage and the above-mentioned average reduction rate, the expected remaining lifetime of the logical memory unit at a future point in time can be calculated as follows: ; in, This represents the normalized percentage of remaining lifetime at the current moment. It represents the rate of decrease of the normalized remaining lifetime percentage over the most recent N acquisition cycles (i.e., the amount of remaining lifetime reduction per unit time). Indicates the current moment. Indicates a predicted time in the future. This represents the time span between the current moment and the predicted moment. Indicates the predicted future Normalized percentage of remaining lifetime at any given time. When this predicted value... When the actual remaining lifespan of the logical storage unit falls below a preset migration threshold, the electronic terminal can trigger a preventative data migration operation before the actual remaining lifespan of the logical storage unit reaches the migration threshold. This avoids intervention delays caused by waiting for the actual lifespan to fall below the threshold before triggering a response. It is understood that the above prediction method based on the average decline rate is only one exemplary implementation, and this embodiment is not limited to it. Other prediction algorithms that can estimate future lifespan trends based on historical lifespan data are also applicable to this embodiment. Through the above prediction mechanism, this embodiment can identify risks and initiate intervention measures in advance before the actual lifespan of the logical storage unit reaches a critical state, thereby further improving the overall reliability and availability of the storage device.

[0032] S102, based on the storage medium type and lifespan status of each logical storage unit, allocates the data to be written to the corresponding target logical storage unit for storage.

[0033] This embodiment, building upon the aforementioned information acquisition and maintenance, further executes intelligent data write scheduling. Considering the significant differences in write endurance, read / write speed, and unit storage cost among different storage media types, this embodiment pre-defines a suitable access level for each storage media type in the storage device. This access level characterizes the range of data access frequencies suitable for the corresponding storage media type—storage media types with higher access levels are suitable for handling frequently accessed "hot" data, while those with lower access levels are suitable for handling less frequently accessed "cold" data. For example, SLC has the highest write endurance and the fastest read / write speed, and can be set to a high access level to suit hot data; TLC has moderate endurance and speed, and can be set to a medium access level to suit warm data; QLC has the lowest unit storage cost and the highest storage density, and can be set to a low access level to suit cold data. By establishing the correspondence between storage media types and access levels, this embodiment can match the most suitable physical storage location for the data to be written based on its own access frequency characteristics during subsequent data writing, thereby achieving precise alignment between data heat and media capabilities at the system level.

[0034] Based on the aforementioned access level settings, this embodiment, upon receiving a data write request, first determines the target access level corresponding to the data to be written based on its access frequency. Data with higher access frequencies corresponds to a higher target access level, meaning that the data should be stored on a storage medium with better performance and faster response. As an example, this embodiment can set two access frequency thresholds to classify data into three levels: hot data, warm data, and cold data. Data with access frequencies higher than the first threshold is classified as hot data and preferentially stored in the logical storage unit corresponding to SLC; data with access frequencies between the first and second thresholds is classified as warm data and stored in the logical storage unit corresponding to TLC; data with access frequencies lower than the second threshold is classified as cold data and stored in the logical storage unit corresponding to QLC.

[0035] After determining the target access level required for the data to be written, this embodiment uses the correspondence between storage medium type and access level to filter out one or more types of storage media that can meet the access level requirements, thereby determining the target storage medium type that matches the target access level. Subsequently, based on the lifetime status information of each logical storage cell, this embodiment selects target logical storage cells whose remaining lifetime meets the preset health standard from the logical storage cells corresponding to the target storage medium type. The necessity of introducing lifetime status as a filtering condition is that even if two logical storage cells belong to the same storage medium type, their wear levels and remaining lifetimes may differ significantly. If data is continuously written to a logical storage cell with a low remaining lifetime without distinction, it will accelerate the failure process of that cell, thereby affecting the reliability and service life of the entire storage device. Therefore, after determining the target storage medium type, this embodiment further filters out cells whose remaining lifetime meets the preset health standard from multiple logical storage cells corresponding to that type as the actual writing targets. Finally, the data to be written is written to the target logical storage cell, thereby completing a complete media-aware data placement process.

[0036] Furthermore, based on the aforementioned media adaptation write mechanism based on access level, from a larger system perspective, this embodiment can further optimize the write load balancing among each logical storage unit to delay the emergence of overall lifespan bottlenecks.

[0037] Specifically, this embodiment determines the write quota weight for each logical storage unit based on its lifetime status. This write quota weight is a relative coefficient used to measure the share of each logical storage unit in subsequent write task allocation. Its value is positively correlated with the remaining lifetime (and may also be positively correlated with the physical storage capacity). That is, logical storage units with longer remaining lifetimes and larger capacities are assigned higher weights, while units with shorter remaining lifetimes and smaller capacities are assigned lower weights. The consideration behind this design is that, when allocating subsequent write tasks, units with ample lifetimes and sufficient capacity should bear a relatively larger write load, while units with limited lifetimes or smaller capacities should have their write burden reduced. This allows the wear and tear process of each unit to become more synchronized, delaying the emergence of an overall lifetime bottleneck.

[0038] Based on this, this embodiment configures a corresponding write quota for each logical storage unit according to the write quota weight of each logical storage unit. Specifically, the write quota is the product of the proportion of each logical storage unit's weight in the total weight and the overall write capacity of the system, that is, the total amount of writable data is allocated among all logical storage units according to their weight proportions. The write quota is used to indicate the upper limit of the amount of data allowed to be written to the corresponding logical storage unit. Units with higher weights are configured with higher write quotas, and vice versa.

[0039] After introducing the write quota mechanism, the aforementioned operation of selecting target logical storage units whose remaining lifespan meets the preset health standard from logical storage units corresponding to the target storage medium type can be further refined as follows: selecting target logical storage units whose remaining lifespan meets the preset health standard and whose current write quota has not been exhausted from logical storage units corresponding to the target storage medium type. This means that even if the remaining lifespan of a certain logical storage unit meets the health standard, if its write quota has been exhausted, this embodiment will not continue to write data to that unit, thereby ensuring that the write load of each unit strictly follows the preset quota constraint and avoiding premature aging of some units due to excessive writing.

[0040] Furthermore, for logic storage cells whose remaining lifetime has decreased to different warning levels, this embodiment can also implement differentiated graded protection measures. Specifically, this embodiment presets three progressively stricter thresholds: a first threshold, a second threshold, and a third threshold, with the first threshold being greater than the second threshold, and the second threshold being greater than the third threshold. The specific values ​​of these thresholds are configured differently depending on the media type: for QLCs with shorter lifetimes, stricter thresholds are set to intervene in protection earlier, for example, the first threshold is set to 50%, the second threshold to 30%, and the third threshold to 10%; for TLCs with medium lifetimes, the threshold levels are moderate, for example, the first threshold is set to 40%, the second threshold to 20%, and the third threshold to 8%; for SLCs with the longest lifetimes, relatively lenient thresholds are set to fully utilize their high durability characteristics, for example, the first threshold is set to 30%, the second threshold to 15%, and the third threshold to 5%. For ease of understanding, the specific implementation of the three-level protection is explained below using TLC and QLC as examples.

[0041] When the remaining lifetime of a logical storage cell is less than or equal to a first threshold, this embodiment performs a write degradation operation on the logical storage cell, that is, restricts the new data types and / or data volume that the cell receives to slow down its wear rate, but still allows it to undertake some write tasks to maintain basic storage functions. Taking the logical storage cell corresponding to TLC as an example, when its remaining lifetime drops to 40% (i.e., the first threshold of TLC), this embodiment marks the cell as a lifetime warning state, no longer writes new hot data to it, and only allows cold data to be written. The hot data that should have been written to this cell is rerouted to other logical storage cells with more sufficient lifetime.

[0042] When the remaining lifetime of a logical storage unit is less than or equal to the second threshold, this embodiment performs a write-prohibition operation on that logical storage unit, meaning that no new data is allowed to be written to that unit, only the read capability of the stored data is retained. At the same time, a data migration process is triggered to migrate the valid data to other healthy logical storage units. Taking the logical storage unit corresponding to a QLC as an example, when its remaining lifetime drops to 30% (i.e., the second threshold of the QLC), this embodiment marks the unit as needing migration, stops all new write requests, and initiates cross-logical storage unit data migration.

[0043] When the remaining lifetime of a logical storage unit is less than or equal to the third threshold, this embodiment performs a read-only operation on the logical storage unit. That is, the unit only provides data reading services, and neither new data writing nor modification or deletion of existing data is allowed. At the same time, the migration process of all data in the unit is forcibly initiated. After the migration is completed, the logical storage unit is taken offline from the system. Regardless of the media type, once its remaining lifetime drops below the third threshold for the corresponding media type, the unit is set to a read-only state, and all write requests are rejected.

[0044] Through the aforementioned hierarchical protection mechanism, this embodiment can gradually tighten write permissions as the lifespan of a logical storage unit approaches its end. This avoids data write failures caused by sudden write restrictions and maximizes the effective service life of each unit, thereby improving the reliability and availability of the entire storage device.

[0045] On the other hand, another embodiment of this application provides a storage management method applied to the electronic terminal side, which mainly involves storage control and management during the data migration process. Figure 3 The flowchart of this storage management method includes the following steps: S201, retrieve the storage medium type and lifetime status of each logical storage unit in the storage device from the records; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device that belongs to a storage medium type; the records are periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol.

[0046] It should be noted that the specific implementation method of this step is the same as that described above. Figure 1 The steps S101 in the illustrated embodiment are consistent. Specifically, this embodiment also reads the storage medium type and lifetime status information of each logical storage unit from the predefined data structure in the standard interface protocol followed by the storage device, and maintains a corresponding lifetime table on the electronic terminal side to record the real-time lifetime status of each logical storage unit. The information reading process, data structure expansion method, and lifetime table maintenance and update mechanism have been described in detail in the description of step S101 above, and will not be repeated here.

[0047] S202, based on the lifetime status of each logical storage unit, determine the logical storage unit that triggers the migration condition, and determine the logical storage unit that meets the migration condition as the source logical storage unit.

[0048] After acquiring and maintaining the storage medium type and lifetime status of each logical storage unit through the aforementioned steps, as write operations continue, the physical blocks in the physical storage area corresponding to each logical storage unit will continuously undergo erase and reprogramming operations. The number of erase / write operations accumulates gradually, and the remaining lifetime of each logical storage unit will decrease to varying degrees. Although the data placement strategy based on access level and lifetime status in the aforementioned embodiments can slow down the wear rate of each logical storage unit to some extent, the wear rate of some logical storage units may be significantly faster than that of others due to differences in the amount and frequency of data written to different logical storage units. This leads to a widening difference in the remaining lifetime between logical storage units, resulting in an uneven lifetime. If this is not addressed, some logical storage units with shorter lifetimes will prematurely exhaust their lifetime due to continuous write requests, causing a decrease in the overall effective capacity of the storage device. This also means that the storage capacity of other logical storage units with longer lifetimes is not fully utilized. Therefore, this embodiment needs to continuously monitor the lifetime status of each logical storage unit during operation and identify those requiring proactive wear leveling intervention. This is the operation to be performed in this step.

[0049] In this step, the source logical storage unit refers to a logical storage unit that, after a comprehensive evaluation of the lifetime status of each logical storage unit, is determined to require the migration of its existing data to reduce write pressure and slow down wear. The trigger migration condition refers to the specific criteria used to determine whether a logical storage unit should be identified as a source logical storage unit; this condition is based on the lifetime status information of the logical storage unit. In this embodiment, the trigger migration condition includes at least one of the following situations.

[0050] The first scenario is when the remaining lifetime of the current logical storage unit does not meet the preset health standard. The preset health standard refers to a pre-defined minimum acceptable value for the remaining lifetime. When the normalized remaining lifetime percentage of a logical storage unit falls below this value, it is considered that the logical storage unit's lifespan is no longer healthy, and continuing to bear write loads will risk premature failure. For example, if the preset health standard is set to a normalized remaining lifetime percentage of no less than 20%, then when the remaining lifetime of a logical storage unit drops below 20%, the migration condition is triggered, and that logical storage unit is identified as the source logical storage unit. The purpose of setting this condition is to directly use the absolute value of the remaining lifetime as the judgment criterion, ensuring that logical storage units nearing the end of their lifespan can be identified in a timely manner and protective measures can be triggered.

[0051] The second scenario is as follows: the rate of increase in the number of erase / write cycles of the current logical storage cell over the most recent N acquisition cycles exceeds a preset multiple of the average rate of increase in the number of erase / write cycles of other logical storage cells of the same storage medium type in the storage device, where N is a positive integer. Here, the 'rate of increase in the number of erase / write cycles' refers to the increase in the number of erase / write cycles per unit time. Specifically, it can be calculated by dividing the difference in the average number of erase / write cycles between adjacent acquisition cycles by the cycle duration, and is used to characterize the wear rate of each logical storage cell. The acquisition cycle corresponds to the cycle in which the electronic terminal periodically reads the lifespan status of each logical storage cell in the aforementioned steps. Within each cycle, the electronic terminal obtains the current average number of erase / write cycles for each cell and records it in the lifespan table. Based on the difference between adjacent cycles, the rate of increase in the number of erase / write cycles for that cycle can be calculated. By comparing the rate of increase of a certain logical storage cell with the average rate of increase of other cells of the same medium type, cells with significantly high write loads can be identified. Even if the absolute value of a cell's current remaining lifespan has not yet fallen below the health standard, if its rate of increase is much higher than that of similar cells, it indicates that the cell is under excessive write pressure, and its remaining lifespan will rapidly decline in the future. If no intervention is taken in advance, the cell will soon approach the end of its lifespan. As an example, this preset multiplier can be set to 1.5 times, meaning that when the growth rate exceeds 1.5 times the average growth rate of the same media type, it is considered to have an abnormal wear risk and triggers the migration condition. The purpose of setting this condition is to identify wear at an early stage from the perspective of wear rate, avoiding the intervention lag that may occur when relying solely on the absolute value of remaining life.

[0052] The third scenario involves using a linear extrapolation prediction algorithm to predict that the remaining lifespan of a logical storage unit within a future time window will be lower than a preset health standard, based on the changing trend of the current logical storage unit's lifespan status. The prediction method used in this scenario is the linear extrapolation prediction mechanism based on historical data, as described in the previous section on lifespan management. It fits the lifespan change trend using normalized remaining lifespan historical data from multiple recent acquisition cycles, and then estimates the expected remaining lifespan at a future point in time. Unlike the second scenario, which focuses on the actual growth rate of the current cycle, this scenario focuses on predicting the future state based on historical trends. Specifically, it uses historical data from multiple acquisition cycles recorded in the lifespan table by the electronic terminal to calculate the predicted value of the unit within the future time window. If this predicted value is lower than the preset health standard (which is a remaining lifespan threshold set to determine whether wear leveling intervention is needed; as a feasible implementation method, it can be configured with reference to the migration threshold defined earlier), it means that even if the current remaining lifespan is still within an acceptable range, at the current wear rate, the unit will enter a migration-required state in the near future, thus triggering the migration condition. The purpose of setting this condition is to use predictive algorithms to transform passive response into proactive prevention, identify risks and trigger migration in advance before logical storage units reach a critical state, thereby reserving a more sufficient time window for data migration operations.

[0053] The three trigger migration scenarios described above are for illustrative purposes only and can be flexibly configured according to specific usage requirements in actual applications. For example, in addition to the three trigger migration conditions based on lifetime status information mentioned above, trigger migration conditions can further include the following scenario: when the difference in remaining lifetime between logical storage units exceeds a preset imbalance threshold, the wear leveling process is triggered. The electronic terminal calculates the difference between the maximum and minimum values ​​of the normalized remaining lifetime percentage of all logical storage units in the lifetime table to obtain the lifetime range between each unit. When this range exceeds the preset imbalance threshold (e.g., the default value is 20%), it indicates that the wear degree of each logical storage unit in the storage device has significantly differentiated, with some units having a remaining lifetime far above the average level while others are nearing the end of their lifespan. If this imbalance continues to develop, the effective capacity of the entire disk will prematurely decrease due to the premature scrapping of some units. At this time, the electronic terminal identifies the logical storage unit with the lowest remaining lifetime as the source logical storage unit and initiates cross-logical storage unit data migration to reduce the lifetime gap between units and make the wear process of each logical storage unit tend to be balanced.

[0054] Furthermore, when the storage device proactively reports a lifetime warning signal for a logical storage unit to the electronic terminal via an asynchronous event notification mechanism, the electronic terminal can directly identify that logical storage unit as the source logical storage unit. The storage device's internal firmware monitors the wear and tear of each physical storage area in real time. When the physical storage area corresponding to a logical storage unit reaches a preset internal alarm threshold at the firmware level, the storage device can send a warning message to the electronic terminal via an asynchronous event notification mechanism defined by a standard interface protocol. This warning message is independent of the periodic lifetime acquisition process initiated by the electronic terminal and is considered an abnormal event proactively reported by the storage device to the electronic terminal. Upon receiving this warning message, the electronic terminal can immediately identify the logical storage unit indicated by the alarm as the source logical storage unit without waiting for the lifetime acquisition results of the next cycle, thereby accelerating the response speed and promptly initiating subsequent protection measures.

[0055] By comprehensively assessing the wear and tear risks of each logical storage unit through the aforementioned multi-factor migration triggering conditions, this embodiment can comprehensively evaluate the wear and tear risks of each logical storage unit from different dimensions. This includes direct assessment based on the absolute value of remaining lifetime, trend assessment based on relative wear rate comparisons, forward-looking assessment based on predictive algorithms, and immediate response assessment based on proactive alarms from storage devices. These conditions complement each other, ensuring that the determination of the source logical storage unit integrates multi-dimensional assessment results of the current state, historical trends, and future predictions. This improves the accuracy and robustness of the assessment, providing a reliable decision-making basis for subsequent data migration operations.

[0056] S203, based on the storage medium type and lifetime status of each logical storage unit, determine at least one target logical storage unit from the storage device as the data migration object of the source logical storage unit.

[0057] After identifying the source logical storage unit through the aforementioned steps, this step further requires determining a suitable destination for the data to be migrated from that source logical storage unit, i.e., the target logical storage unit. Simply identifying the source logical storage unit that needs reduced write pressure is insufficient to complete the closed-loop operation of wear leveling. Only when the data in the source logical storage unit is successfully migrated to other suitable storage locations can the write pressure of the source logical storage unit be truly relieved, and its wear rate effectively slowed down. Therefore, the selection of the target logical storage unit directly affects the actual effect of the wear leveling operation. If the target is not selected properly, such as migrating hot data to a logical storage unit with similarly short lifespan or incompatible media characteristics, it will not only fail to alleviate the wear pressure of the source logical storage unit, but may also spread the wear risk to other logical storage units, or even exacerbate the overall lifespan imbalance. Based on this, this step needs to comprehensively consider two core dimensions: storage media type and lifespan status, to select the most suitable target logical storage unit for the data to be migrated.

[0058] As defined in the preceding embodiments, this embodiment pre-defines a corresponding access level for each type of storage medium in the storage device to characterize the range of data access frequencies suitable for the corresponding storage medium type. Specifically, storage medium types with higher access levels, such as SLC, have higher write endurance and faster read / write speeds, making them suitable for carrying frequently accessed hot data; storage medium types with lower access levels, such as QLC, have larger storage capacity and lower unit cost, making them suitable for carrying less frequently accessed cold data; and storage medium types with access levels between the two, such as TLC, are suitable for carrying warm data with access frequencies between hot and cold data. Through the above correspondence between storage medium types and access levels, this embodiment can quickly filter out suitable storage medium types based on the access level of the data to be migrated when determining the target logical storage unit, thereby matching a suitable target storage location for data migration.

[0059] Based on this, when determining the target logical storage unit, this step first determines the access level of each data based on the access frequency of each data in the source logical storage unit. The source logical storage unit, as the logical address space carrying data storage, typically stores data with different access frequencies, including frequently accessed "hot" data, long-inaccessible "cold" data, and possibly "warm" data with access frequencies in between. As mentioned earlier, the electronic terminal continuously counts the access frequency within each logical address range during normal operation and records this statistical information in a heat statistics table. Therefore, when a migration operation needs to be performed, this embodiment can query this heat statistics table to obtain the specific access frequency of each data block or each logical address range in the source logical storage unit, and then determine its corresponding access level based on the access frequency.

[0060] Based on the access energy level of each data, this embodiment identifies data in the source logical storage unit whose access energy level meets the first preset access energy level standard as data to be migrated out. Here, the first preset access energy level standard is used to define which data should be migrated out of the source logical storage unit. When this step is applied to a hot data migration scenario, i.e., when the source logical storage unit is a unit with a short lifespan and its hot data needs to be migrated out to reduce its write pressure, the first preset access energy level standard can be set to identify data with a higher access energy level (i.e., hot data) as data to be migrated out. This is because the core reason for the short lifespan of the source logical storage unit is that it bears too many high-frequency write operations, and high-frequency write operations mainly come from the continuous updating of hot data. Therefore, migrating out hot data can most directly and effectively reduce the rate of increase in the number of erase / write cycles of this unit. As an example, when the source logical storage unit is the logical storage unit corresponding to QLC and its remaining lifespan is lower than the migration threshold, the first preset access energy level standard can be set to identify all data with an access frequency higher than the hot data threshold as data to be migrated out and migrated to a logical storage unit with a higher access energy level and a longer lifespan.

[0061] Of course, in certain scenarios, such as when the access frequency distribution of data blocks in the source logical storage unit is relatively uniform and there is no obvious high-frequency hot data, the first preset access level standard can also be set to include some warm data in the range of data to be migrated. However, in general, prioritizing the migration of hot data is the most efficient approach, because migrating a small amount of hot data can significantly reduce the write frequency of the source logical storage unit, while migrating a large amount of cold data has limited contribution to reducing the write frequency and only increases migration overhead.

[0062] After determining the data to be migrated from the source logical storage unit, this embodiment further determines the target logical storage unit from the storage device as the migration target. This embodiment provides two parallel implementation methods to determine the target logical storage unit: one is a query method based on access level, and the other is a method based on preset storage medium mapping rules. Both can be used individually or in combination.

[0063] Method 1: Query method based on access level This embodiment selects at least one logical storage unit from among those logical storage units whose remaining lifespan meets a preset health standard and whose remaining physical storage capacity is sufficient to accommodate the data to be migrated, based on the storage medium type and lifetime status of each logical storage unit. Specifically, this selection process includes three screening dimensions.

[0064] The first screening dimension is access level compatibility, meaning the access level of the storage medium type corresponding to the target logical storage unit should match the access level of the data to be migrated. In other words, the data to be migrated should be moved to a storage medium type that matches its access frequency characteristics. For example, if the data to be migrated is hot data with a high access level, then a logical storage unit corresponding to a storage medium type with an equally high access level should be selected as a candidate, such as a logical storage unit corresponding to SLC or TLC, rather than migrating it to a logical storage unit corresponding to QLC with a lower access level. Otherwise, even if the physical location of the data changes after migration, it will still put high-frequency write pressure on the target logical storage unit, essentially transferring the wear risk from one unit to another unit that is also unsuitable for carrying hot data, without truly solving the problem.

[0065] The second screening dimension is the lifespan health standard, which requires the normalized remaining lifespan percentage of the target logical storage unit to meet a preset health standard, such as not falling below a migration threshold or warning threshold. The necessity of setting this screening condition lies in the fact that if data to be migrated out is migrated into a logical storage unit with an equally strained lifespan, that unit will experience accelerated wear after accepting the migrated data and will soon reach a state requiring migration. This not only fails to achieve wear leveling but may also trigger a chain reaction of migrations, unnecessarily increasing system overhead. Therefore, this embodiment requires the remaining lifespan of the target logical storage unit to meet the preset health standard, ensuring that the unit still has sufficient lifespan margin to handle the increased write load after the data is migrated in.

[0066] The third screening dimension is the remaining physical storage capacity, meaning the remaining available storage space of the target logical storage unit should be sufficient to accommodate the amount of data to be migrated. This is a basic physical constraint; if the capacity is insufficient, the migration operation cannot be completed. In actual execution, if multiple candidate logical storage units satisfy the above three screening conditions, this embodiment can select the logical storage unit with the highest remaining lifetime as the target logical storage unit, or select the logical storage unit with the largest remaining physical storage capacity as the target logical storage unit, or combine the above two factors and perform a weighted score to select the candidate unit with the highest score. The specific selection strategy can be flexibly configured according to the actual application scenario, and this embodiment does not limit it.

[0067] Method 2: Based on preset storage medium mapping rules As an alternative implementation method parallel to the above, this embodiment can also directly determine the target logical storage unit according to a preset storage medium mapping rule, without needing to query the access level step by step. Specifically, the mapping rule predefines the data hotness and coldness and write priority adapted to each storage medium type. For example, data with high access frequency is preferentially stored in the logical storage unit corresponding to SLC, data with medium access frequency is stored in the logical storage unit corresponding to TLC, and data with low access frequency or that has not been accessed for a long time is stored in the logical storage unit corresponding to QLC.

[0068] In scenarios requiring data migration to reduce write pressure on the source logical storage unit, this embodiment selects the target logical storage unit according to the storage medium type of the source logical storage unit, following these rules: When the source logical storage unit is QLC, the target logical storage unit is preferentially selected as SLC, followed by TLC; when the source logical storage unit is TLC, the target logical storage unit is selected as SLC; and when the source logical storage unit is SLC, the target logical storage unit is selected as TLC. Based on the above mapping rules, this embodiment also requires that the remaining lifetime of the selected target logical storage unit meets a preset health standard, and that the remaining physical storage capacity is sufficient to accommodate the data to be migrated. If the preferentially selected target logical storage unit does not meet the above conditions, the next best option is tried, and so on, until a candidate unit that meets the conditions is found or it is determined that no usable target is available. The above rules ensure that the data to be migrated is always migrated to a storage unit with a longer lifetime or more suitable media characteristics, thereby effectively reducing the write pressure on the source logical storage unit and avoiding transferring the risk of wear and tear to other vulnerable storage units.

[0069] S204, move the data from the source logical storage unit to the target logical storage unit.

[0070] After identifying the source and target logical storage units through the aforementioned steps, this step further executes the actual data migration operation, that is, moving the data from the source logical storage unit to the target logical storage unit. The previous steps completed the decisions on "what to migrate" and "where to migrate," while this step is the crucial link in putting these decisions into practice. Without the actual execution of this step, the data identified as needing migration in the source logical storage unit will remain in its original location, the high-frequency write load on the source logical storage unit will not be alleviated in any way, its wear rate will remain at its original level, and the entire wear leveling decision chain will not be able to form a closed loop. Therefore, this step is the execution layer operation that translates decisions into action, and it is also the key link in the entire wear leveling process to achieve physical data movement.

[0071] In the specific implementation of this step, this embodiment first generates a migration operation to move data from the source logical storage unit to the target logical storage unit. This migration operation is a logical data transfer task, and its content includes at least the identifier of the source logical storage unit, the identifier of the target logical storage unit, the logical address range of the data to be migrated, and the amount of data to be migrated. After generating the migration operation, this embodiment submits the migration operation to the execution queue of the electronic terminal for execution. The execution queue is a scheduling mechanism within the electronic terminal used to manage various input / output operation requests. Read and write operations of the storage device are submitted to the storage device for execution through this queue. By submitting the migration operation to the execution queue, this embodiment enables the data migration operation to share the same underlying input / output channel with normal business input / output operations, without the need to establish an additional dedicated channel for the migration operation or rely on private migration instructions within the storage device, thereby maintaining compatibility with standard interface protocols.

[0072] During the migration operation, this embodiment controls the input / output bandwidth consumed by the migration operation to avoid impacting normal business input / output. Specifically, this embodiment limits the input / output bandwidth utilization of the migration operation to no more than a predetermined percentage of the total bandwidth of the electronic terminal. For example, this predetermined percentage can be set to 20%, meaning that the input / output bandwidth occupied by the migration operation during execution must not exceed 20% of the total bandwidth of the electronic terminal. The significance of this setting is that the migration operation is essentially a background maintenance task, and its priority should be lower than normal business input / output requests. If its bandwidth utilization is not limited, the migration operation may consume a large amount of input / output channel resources, resulting in a significant increase in the response latency of business input / output, thereby affecting the performance and stability of the electronic terminal in providing services. By controlling the bandwidth utilization of the migration operation within a certain percentage of the total bandwidth, this embodiment can ensure that the input / output performance of normal services is not significantly affected while performing wear-leveling migration.

[0073] Furthermore, this embodiment dynamically controls the execution and suspension of the migration operation based on the load status of the electronic terminal. Specifically, the migration operation is configured to: suspend execution when the load of the electronic terminal exceeds a first load threshold, and resume execution when the load of the electronic terminal drops from the first load threshold to below a second load threshold, wherein the first load threshold is greater than the second load threshold. The load of the electronic terminal can refer to quantitative indicators that reflect the current busy level of the terminal, such as processor utilization, input / output queue depth, or input / output throughput of storage devices; this embodiment does not specifically limit this. The first load threshold is used to determine whether the terminal is currently in a high-load state. When the load exceeds this threshold, it indicates that the terminal is processing a large number of service requests. If the migration operation continues at this time, it will consume the already strained input / output resources and affect service performance; therefore, the migration operation needs to be suspended. The second load threshold is used to determine whether the terminal has recovered from a high-load state to a low-load state. When the load drops from above the first load threshold to below the second load threshold, it indicates that the resource pressure on the terminal has been relieved, and the execution of the migration operation can be safely resumed at this time. The introduction of two different load threshold values ​​(first and second) aims to prevent the migration operation from frequently switching between execution and pause states near the load threshold. If only a single threshold is set, the migration operation will repeatedly execute and pause when the load fluctuates slightly around that threshold, causing unnecessary overhead and jitter. By setting a hysteresis interval where the first load threshold is greater than the second load threshold, this embodiment provides a buffer zone for the execution state switching of the migration operation, effectively avoiding frequent state oscillations and improving the stability of the migration process.

[0074] After migrating hot data from the source logical storage unit to the target logical storage unit, the storage space occupied by the migrated data in the source logical storage unit is released, forming a certain amount of free capacity. To prevent subsequent hot data from being written back to the source logical storage unit and negating the effect of this migration, this embodiment can perform an optional supplementary operation: from all logical storage units other than the source logical storage unit, determine data whose access energy level does not meet the second preset access energy level standard as the data to be migrated in, and migrate this data to the source logical storage unit. The second preset access energy level standard is used to define the data types suitable for migration into the source logical storage unit. Considering that the source logical storage unit has been determined to be a unit with a short lifespan and should not carry high-frequency access data in the future, the standard can be set to only allow data with a low access energy level (i.e., cold data) to be migrated in. Through this supplementary operation, the original hot data in the source logical storage unit is replaced with cold data from other logical storage units. The stored content changes from frequently updated data to infrequently accessed data, significantly reducing write pressure and effectively slowing the rate of increase in erase / write cycles. Simultaneously, the other logical storage units that have had their cold data moved out also release corresponding storage space, which can be used to receive new write requests. This combination of hot data migration out and cold data migration in achieves data swapping across logical storage units, ensuring that the data activity of each logical storage unit is matched again with its media characteristics and lifespan.

[0075] After the migration is completed, this embodiment can also evaluate the migration effect and decide whether to perform iterative optimization based on the evaluation results. Specifically, the electronic terminal continues to collect the lifetime status information of each logical storage unit according to a preset cycle, compares the lifetime status after migration with that before migration, and evaluates the migration effect from the following dimensions: whether the rate of increase of erase / write cycles of the source logical storage unit decreases, whether the range of normalized remaining lifetimes between each logical storage unit converges to within a preset imbalance threshold, and whether the effective available capacity of the entire disk is improved. If the above indicators all meet expectations, the current wear leveling process ends; if they do not meet expectations, the aforementioned steps of hot data identification, target logical storage unit selection, hot data migration out, and cold data migration in are repeated to enter the next round of migration iteration. To control the impact of migration operations on system performance, the amount of data migrated in each round does not exceed the preset upper limit of the amount of data migrated in a single round (e.g., 10% of the capacity of each logical storage unit), and after each round of migration is completed, a preset observation period (e.g., 5 minutes) is waited for. After the change in erase / write cycles observed within this period tends to stabilize, the next round of migration is decided based on the evaluation results. Through the above-mentioned effect evaluation and iterative execution mechanism, this embodiment can ensure that the actual effect of wear leveling operation continues to converge, avoid the repeated occurrence of unbalanced state caused by insufficient single-round migration, and thus further improve the overall lifespan and reliability of storage devices.

[0076] in, Figure 4 This is a schematic diagram of the cross-logical memory cell wear leveling process provided in an embodiment of this application. The diagram shows the complete execution path from trigger condition judgment to migration completion and effect evaluation: This embodiment first determines whether the conditions for triggering the wear leveling process are met, specifically including four scenarios: Condition 1, the normalized remaining lifetime R of a certain logical memory cell has dropped to the migration threshold. The following conditions apply: Condition 2: The write / erase cycle growth rate of a certain logical memory cell exceeds a preset multiple (e.g., 1.5 times) of the average write / erase cycle growth rate of other logical memory cells of the same storage medium type; Condition 3: The remaining lifetime difference between logical memory cells exceeds a preset imbalance threshold. Condition four: The electronic terminal receives a lifespan warning signal reported by the storage device through an asynchronous event notification mechanism. The wear leveling process is triggered when any one of the above four triggering conditions is met.

[0077] After wear leveling is triggered, this embodiment first identifies the logical memory cell with the smallest normalized remaining lifetime R and the highest erase / write cycle growth rate as the source logical memory cell. Then, it identifies the source logical memory cell whose access frequency is higher than a preset hot data threshold or whose write timestamp is within a preset time window. The system retrieves the hot data within the specified range and obtains its logical address range set. Next, it selects the target logical storage unit based on the storage medium type of the source logical storage unit: if the source logical storage unit is QLC, the target logical storage unit is preferentially selected as SLC, followed by TLC; if the source logical storage unit is TLC, the target logical storage unit is selected as SLC; if the source logical storage unit is SLC, the target logical storage unit is selected as TLC. The normalized remaining lifetime R of the selected target logical storage unit must be higher than the warning threshold. Furthermore, there is sufficient remaining physical storage capacity. Subsequently, a hot data migration operation is performed, which involves reading hot data from the source logical storage unit to the host buffer of the electronic terminal, then writing it to the target logical storage unit, updating the logical address mapping table, and performing a de-allocation operation on the old logical address range of the source logical storage unit.

[0078] After the hot data is migrated out, this embodiment further identifies other logical storage units whose access frequency is lower than the preset cold data threshold and whose write timestamp is earlier than the preset time window. The cold data is read and written to the source logical storage unit. Similarly, the logical address mapping table is updated and the old logical address range of other logical storage units is allocated, thereby realizing the swapping of hot and cold data across logical storage units.

[0079] After the migration is completed, this embodiment evaluates the migration effect, namely, whether the rate of increase of erase / write cycles of the source logical memory cells decreases and whether the difference in normalized remaining lifetime between the logical memory cells converges to the imbalance threshold. The wear leveling process will be completed if the expected results are achieved, including whether the overall available capacity of the disk is increased. If the expected results are achieved, the current wear leveling process will end; otherwise, it will be observed for a preset period. Then repeat the above steps of hot data identification, target logical storage unit selection, hot data migration out and cold data migration in until the wear leveling effect meets expectations or the maximum number of retries is reached.

[0080] After introducing the differentiated data placement process during the aforementioned data writing phase and the wear leveling migration process across logical storage units, the following section combines... Figure 5 The modular architecture of the electronic terminal side is explained.

[0081] Figure 5 This is a schematic diagram of the electronic terminal architecture provided in this embodiment. The electronic terminal internally operates multiple functional modules, including a lifetime management module, a wear leveling decision module, a lifetime table maintenance module, and a data access level identification module. The lifetime management module is responsible for issuing management commands via standard interface protocols to the storage device through the storage device driver, and for reading the storage medium type and lifetime status information of each predefined logical storage unit within the data structure of the storage device. Its specific workflow can be found in [reference needed]. Figure 2 The lifespan maintenance module is used to maintain and update the lifespan tables of each logical storage unit in real time on the terminal side. The wear leveling decision module is used to determine the source logical storage unit that triggers the migration condition and the target logical storage unit as the migration target based on the lifespan status of each logical storage unit. For its specific workflow, please refer to [link / reference]. Figure 4 The data access level identification module is used to identify the target access level corresponding to the access frequency of the data to be written during the data writing phase, thereby determining the target storage medium type that is compatible with it. All of the above functional modules communicate with the storage device via a locally installed storage device driver and a standard interface protocol, jointly realizing storage device lifetime awareness, data placement, and wear leveling scheduling across logical storage units.

[0082] It should be noted that the various specific implementation methods described in the above embodiments are for illustrative purposes only and do not constitute a limitation on the scope of protection of this application. Based on the same inventive concept, those skilled in the art can make appropriate adjustments or substitutions to the above specific implementation methods according to the actual hardware environment, system load characteristics and management requirements when implementing the solution of this application, without departing from the core concept of this application.

[0083] For example: In terms of how to obtain lifetime information, in addition to exposing media type and lifetime information through the Identify Namespace extended field, the lifetime information of each logical storage unit can also be obtained by adding a Vendor Specific Log Page (such as Log Identifier 0xC0) and having the host issue a Get Log Page command, or by reading through the out-of-band channel via the NVMe-MI management interface. Regarding the representation of remaining lifetime, in addition to the aforementioned method of calculating the normalized remaining lifetime percentage based on the ratio of the maximum number of erase / write cycles to the current average number of erase / write cycles, this application can also use a normalized calculation method based on the ratio of the amount of data already written to the media's rated total write bytes. Specifically, each type of storage medium has a corresponding rated total write bytes at the time of manufacture, which represents the maximum cumulative amount of data written that the medium of that type promises within its design lifetime. The electronic terminal obtains the total amount of data written to each logical storage unit since it has been put into use through a standard interface protocol, then subtracts the current cumulative amount of data written from the rated total write bytes of the medium type, and divides it by the rated total write bytes to obtain the normalized remaining lifetime percentage based on the amount of writes. This method can also unify the lifetime status of different medium types onto a dimensionless percentage scale of 0 to 100%, complementing the aforementioned normalization method based on the number of erase / write cycles. In the main body of data migration across logical storage units, in addition to the host completing the migration through the standard NVMe Read / Write / Deallocate command, the host can also issue a migration strategy (such as specifying the source NS and the target NS), and the SSD firmware can execute the actual data migration through Vendor Specific commands. In terms of identifying hot and cold data, in addition to the access frequency statistics table maintained by the host side, the SSD's internal FTL can also complete the hot and cold data marking through access frequency statistics. The host executes migration decisions by reading the hot and cold marking information reported by the SSD. In terms of threshold configuration strategy, in addition to using fixed thresholds (such as warning threshold 40%, migration threshold 20%, and read-only threshold 5%), the threshold can also be dynamically adjusted according to the overall disk life distribution and load characteristics. For example, when the overall disk life is sufficient, the threshold can be relaxed to reduce the migration frequency, and when the overall disk life is tight, the threshold can be tightened to accelerate wear leveling convergence. In terms of storage media type, in addition to SLC, TLC and QLC, it can also be expanded to multi-level cell (MLC). The lifespan and performance of MLC are between SLC and TLC, and it is suitable for carrying warm data with access frequency between hot data and cold data.

[0084] The aforementioned alternative implementations are all based on the core concept of this application, namely, exposing the storage medium type and lifespan status of each logical storage unit to the electronic terminal through the standard interface protocol of the storage device, and having the electronic terminal perform differentiated data placement and wear leveling scheduling across logical storage units based on this information. Therefore, they should all fall within the protection scope of this application.

[0085] Furthermore, another embodiment of this application provides a storage device having at least two types of storage media. Figure 6 This is a schematic diagram of the structure of the storage device provided in an embodiment of this application. Figure 6 As shown, the storage device is divided into multiple logical storage units at the logical layer, namely logical storage unit 1 to logical storage unit n. Each logical storage unit has an independent identifier, which can be addressed and accessed by electronic terminals through standard interface protocols. At the physical layer, the storage device includes physical storage areas belonging to different storage media types. For example, physical storage areas A1, A2… corresponding to storage media type A, and physical storage areas B1, B2… corresponding to storage media type B. Each storage media type has significant differences in the number of bits carried per unit storage cell, the maximum number of erase / write cycles, read / write speed, storage density, and cost. Examples include single-level cell storage media, multi-level cell storage media, three-level cell storage media, and four-level cell storage media. Each logical storage unit corresponds to a physical storage area belonging to a specific storage media type within the storage device. That is, each type of physical storage area is divided into one or more logical storage units, allowing electronic terminals to access the corresponding physical storage area by accessing the logical storage unit. The storage device is configured with a data structure conforming to a standard interface protocol at the data layer. This data structure defines the storage medium type and lifespan status corresponding to each logical storage unit. For example, in the table at the data layer, logical storage unit 1 corresponds to storage medium type A and its lifespan status, logical storage unit 2 corresponds to storage medium type B and its lifespan status, and so on. Through this configuration, the storage device provides electronic terminals with an information channel to obtain the storage medium type and lifespan status of each logical storage unit at the data structure level of the standard interface protocol. This allows electronic terminals to read the predefined information in the data structure by issuing management commands through the standard interface protocol, thereby establishing a global understanding of the media distribution and lifespan status of each physical storage area within the storage device.

[0086] Corresponding to the above storage device configurations, when the storage device is a solid-state drive (SSD), the standard interface protocol is the NVMe protocol. The storage media type and lifetime status of each logical storage unit are defined in the IdentifyNamespace data structure under the NVMe protocol. The electronic terminal can obtain this data structure by issuing the IdentifyNamespace command and parse out the storage media type and lifetime status information of each logical storage unit. When the storage device is a general-purpose flash storage device, the standard interface protocol is the UFS protocol. The storage media type and lifetime status of each logical storage unit are defined in the descriptor data structure of the UFS protocol. The electronic terminal can obtain the storage media type and lifetime status information of each logical storage unit by reading this descriptor data structure through the UFS protocol. By pre-defining the above information in the data structure of the standard interface protocol on the storage device side, this embodiment enables the electronic terminal to obtain the media characteristics and lifespan status of each logical storage unit inside the storage device through standard protocol commands without relying on any manufacturer-defined private interface or out-of-band management channel. This provides the necessary information foundation for the storage management methods in the aforementioned embodiments, enabling the electronic terminal to make globally optimal storage scheduling decisions in operations such as data writing and data migration across logical storage units.

[0087] In addition, corresponding to Figure 1 The method shown in this application, in another embodiment, also provides a storage management device. Wherein, Figure 7 This is a schematic diagram of the storage management device 700, including: The first reading module 710 reads the storage medium type and lifetime status of each logical storage unit in the storage device through the standard interface protocol of the storage device; wherein, the storage device is divided into multiple logical storage units, each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol.

[0088] The write execution module 720, in response to a data write request, allocates the data to be written to the corresponding target logical storage unit for storage based on the storage medium type and lifetime status of each logical storage unit.

[0089] It should be noted that the storage management device in this embodiment can be used as... Figure 1 The execution body of the method shown is therefore able to achieve... Figure 1 The steps and functions of the method shown are illustrated.

[0090] In addition, corresponding to Figure 3The method shown in this application, in another embodiment, also provides a storage management device. Wherein, Figure 8 This is a schematic diagram of the storage management device 800, including: The second reading module 810 reads the storage medium type and lifetime status of each logical storage unit in the storage device through the standard interface protocol of the storage device; wherein, the storage device is divided into multiple logical storage units, each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol.

[0091] The migration object determination module 820 determines the logical storage unit that triggers the migration condition based on the lifetime status of each logical storage unit, and determines the logical storage unit that meets the migration condition as the source logical storage unit.

[0092] The migration target determination module 830 determines at least one target logical storage unit from the storage device as the data migration target of the source logical storage unit, based on the storage medium type and lifetime status of each logical storage unit.

[0093] The migration execution module 840 migrates the data from the source logical storage unit to the target logical storage unit.

[0094] It should be noted that the storage management device in this embodiment can be used as... Figure 3 The execution body of the method shown is therefore able to achieve... Figure 3 The steps and functions of the method shown are illustrated.

[0095] Furthermore, embodiments of this disclosure also provide a computer-readable storage medium storing one or more computer programs, the one or more computer programs including instructions. These instructions, when executed by a portable electronic device including multiple applications, enable the portable electronic device to perform... Figure 1 or Figure 3 The steps in the method shown.

[0096] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0097] The above are merely embodiments of this specification and are not intended to limit the scope of this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification. Furthermore, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of this document.

Claims

1. A storage management method applied to an electronic terminal equipped with a storage device, said storage device having at least two types of storage media; characterized in that, The method includes: In response to a data write request, the storage medium type and lifetime status of each logical storage unit in the storage device are obtained from the record; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type; the record is periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol; Based on the storage medium type and lifetime status of each logical storage unit, the data to be written is allocated to the corresponding target logical storage unit for storage.

2. The method according to claim 1, characterized in that, Each type of storage medium in the storage device corresponds to a suitable access level, which characterizes the range of data access frequencies suitable for the corresponding storage medium type; the allocation of data to be written to the corresponding target logical storage unit for storage based on the storage medium type and lifetime status of each logical storage unit includes: Based on the access frequency of the data to be written, determine the target access level corresponding to the data to be written; Based on the correspondence between the storage medium type and the access level, determine the target storage medium type that is compatible with the target access level; Based on the lifetime status of each logical storage unit, target logical storage units whose remaining lifetime meets the preset health standard are selected from logical storage units corresponding to the target storage medium type. The data to be written is written to the target logical storage unit.

3. The method according to claim 2, characterized in that, Also includes: Based on the lifetime status of each logical storage unit, the write quota weight of each logical storage unit is determined. The write volume quota weight is positively correlated with the remaining lifetime; Based on the estimated total write volume of the storage device, the write volume quota weight of each logical storage unit, and the physical storage capacity of each logical storage unit, a write volume quota is configured for each logical storage unit. The write quota is used to indicate the upper limit of the amount of data that can be written to the corresponding logical storage unit; The step of selecting target logical storage units whose remaining lifetime meets the preset health standard from logical storage units corresponding to the target storage medium type includes: Select target logical storage cells from the logical storage cells corresponding to the target storage medium type, whose remaining lifetime meets the preset health standard and whose current write quota has not been exhausted.

4. The method according to claim 1, characterized in that, The remaining lifetime indicated by the lifetime status refers to a percentage value calculated based on the maximum number of erase / write cycles for the storage medium type corresponding to the logical storage unit and the average number of erase / write cycles for each physical block within the logical storage unit; the method further includes: In response to a logical storage cell having a remaining lifetime less than or equal to a first threshold, a write degradation operation is performed on the logical storage cell to limit the new data types and / or data volume that the logical storage cell can receive. In response to a logical memory cell having a remaining lifetime less than or equal to a second threshold, a write-prohibition operation is performed on that logical memory cell. In response to a logical memory cell having a remaining lifetime less than or equal to a third threshold, a read-only operation is performed on that logical memory cell. Wherein, the first threshold is greater than the second threshold, and the second threshold is greater than the third threshold.

5. The method according to claim 1, characterized in that, The step of reading the storage medium type and lifetime status of each logical storage unit in the storage device through the standard interface protocol of the storage device includes: When the storage device is a solid-state drive, an IdentifyNamespace command is sent to the storage device via the NVMe protocol to receive the IdentifyNamespace data structure from the storage device and to obtain the storage medium type and lifetime status of each logical storage unit from the IdentifyNamespace data structure; wherein, the storage medium type and lifetime status are defined in the IdentifyNamespace data structure; or, When the storage device is a general-purpose flash memory storage device, the descriptor data structure of the storage device is read through the UFS protocol to obtain the storage medium type and lifetime status of each logical storage unit from the descriptor data structure; wherein, the storage medium type and lifetime status are defined in the descriptor data structure.

6. A storage management method applied to an electronic terminal equipped with a storage device, said storage device having at least two types of storage media; characterized in that, The method includes: The storage medium type and lifetime status of each logical storage unit in the storage device are obtained from the records; wherein, the storage device is divided into multiple logical storage units, and each logical storage unit corresponds to a physical storage area in the storage device belonging to a certain storage medium type; the records are periodically read from the storage device through the standard interface protocol of the storage device, and the storage medium type and lifetime status of each logical storage unit are predefined in the data structure of the storage device that conforms to the standard interface protocol; Based on the lifetime status of each logical storage unit, the logical storage unit that triggers the migration condition is determined, and the logical storage unit that meets the migration condition is determined as the source logical storage unit. Based on the storage medium type and lifetime status of each logical storage unit, at least one target logical storage unit is determined from the storage device as the data migration object of the source logical storage unit; Data is moved from the source logical storage unit to the target logical storage unit.

7. The method according to claim 6, characterized in that, Each storage medium type in the storage device corresponds to a suitable access level, and the access level is used to characterize the data access frequency range adapted to the corresponding storage medium type; determining at least one target logical storage unit from the storage device as the data migration object of the source logical storage unit based on the storage medium type and lifetime status of each logical storage unit includes: Based on the access frequency of each data in the source logical storage unit, the access energy level of each data in the source logical storage unit is determined, and the data in the source logical storage unit whose access energy level meets the first preset access energy level standard is determined as data to be migrated out. Based on the storage medium type and lifetime status of each logical storage unit, at least one logical storage unit with a remaining lifetime that meets a preset health standard and a remaining physical storage capacity sufficient to accommodate the data to be migrated is selected from logical storage units that are compatible with the access level of the data to be migrated, and is used as the corresponding target logical storage unit.

8. The method according to claim 7, characterized in that, After migrating the data from the source logical storage unit to the target logical storage unit, the method further includes: From all logical storage units other than the source logical storage unit, determine the data whose access level does not meet the second preset access level standard, and use it as the data to be migrated in; The data to be migrated is migrated into the source logical storage unit.

9. The method according to claim 6, characterized in that, The migration triggering conditions include at least one of the following: The remaining lifespan of the current logical storage unit does not meet the preset health standard; The rate of increase in the number of erase / write cycles of the current logical storage unit in the most recent N collection cycles exceeds a preset multiple of the average rate of increase in the number of erase / write cycles of other logical storage units of the same storage medium type in the storage device; where N is a positive integer; Based on the changing trend of the current logical storage unit's lifetime status, a linear extrapolation prediction algorithm is used to predict that the remaining lifetime of the current logical storage unit in a future time window will be lower than the preset health standard.

10. The method according to claim 6, characterized in that, The step of migrating data from the source logical storage unit to the target logical storage unit includes: Generate a migration operation to move data from the source logical storage unit to the target logical storage unit, and submit the migration operation to the execution queue of the electronic terminal for execution; Wherein, the I / O bandwidth utilization of the migration operation does not exceed a predetermined proportion of the total bandwidth of the electronic terminal; the migration operation is configured to: suspend execution when the load of the electronic terminal exceeds a first load threshold, and resume execution when the load of the electronic terminal drops from the first load threshold to below a second load threshold, wherein the first load threshold is greater than the second load threshold.

11. A storage device having at least two types of storage media; characterized in that, The storage device is divided into multiple logical storage units, each of which corresponds to a physical storage area in the storage device belonging to a storage medium type. The storage device is configured with a standard interface protocol for electronic terminals to access, and defines the storage medium type and lifetime status corresponding to each logical storage unit in a local data structure that conforms to the standard interface protocol, so that the electronic terminal can read it through the standard interface protocol.

12. The storage device according to claim 11, characterized in that, The storage device is a solid-state drive, the standard interface protocol is the NVMe protocol, and the storage medium type and lifespan status of each logical storage unit are defined in the Identify Namespace data structure under the NVMe protocol; or, The storage device is a general-purpose flash memory storage device, the standard interface protocol is the UFS protocol, and the storage medium type and lifetime status of each logical storage unit are defined in the descriptor data structure of the UFS protocol.

13. A computer-readable storage medium for storing one or more computer instructions, characterized in that, When the computer instructions are executed, the storage management method as described in any one of claims 1 to 10 is implemented.

Images