A data management method and system suitable for IMR

Abstract

The application discloses a data management method and system suitable for IMR, wherein when a bottom track is updated, data of an effective top track is actively migrated to other free tracks; in the MFML data update strategy, a zigzag four-stage data management scheme is adopted, in the first stage, data of the bottom track is updated; in the second stage, the MFML strategy is adopted to update data of the bottom track; in the third stage and the fourth stage, data distribution and bottom track data update are continuously performed according to the mode of the second stage, and data management is realized. The application can make the MFML update strategy better play the performance in the four-stage data management scheme, and can also relieve the performance decline problem caused by the too high top track occupation amount of the multi-stage distribution scheme.

Description

Technical Field

[0001] This invention belongs to the field of data management technology, specifically relating to a data management method and system suitable for IMR. Background Technology

[0002] Interlaced magnetic recording (IMR) is a new type of hard disk recording technology. IMR has higher data density and lower write amplification (WA) than conventional magnetic recording (CMR) and shingled magnetic recording (SMR), thus it can provide higher data capacity and alleviate the data write amplification problem currently existing in SMR technology.

[0003] Defects and shortcomings of existing technology:

[0004] 1. Although the Read-Modify-Write (RMW) update strategy used in the existing IMR ensures crash consistency, it is actually a time-consuming process and may seriously degrade write performance.

[0005] 2. While the current design of IMR does reduce track rewriting, it can still generate a certain amount of RMW (Recovery Mapping), requiring significant additional data migration. Therefore, these rewrites can inevitably lead to a significant reduction in write performance, especially when disk space utilization is high. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a data management method and system suitable for IMR in response to the shortcomings of the prior art. By improving the data update strategy and data distribution method in IMR, the data update speed of IMR disk is accelerated, the data write amplification problem is reduced, thereby enhancing the read and write performance of IMR, expanding the application field of IMR disk, and reducing the cost of data center.

[0007] The present invention adopts the following technical solution:

[0008] A data management method applicable to IMR includes the following steps:

[0009] S1. When updating a bottom track, actively migrate the data of the valid top track to some other free tracks;

[0010] S2. In the MFML data update strategy, a zigzag four-stage data management scheme is adopted. In the first stage, the data of the bottom track is updated; in the second stage, the data of the bottom track is updated using the MFML strategy; in the third and fourth stages, the data allocation and bottom track data update are carried out in the same way as the second stage to achieve data management.

[0011] Specifically, step S1 is as follows:

[0012] S101. Calculate the cumulative update count of the bottom track Track_update_sum and calculate their average value Track_update_avg. Then, divide the hot track into hot track and cold track according to the cumulative update count.

[0013] S102. Move the data of the top track adjacent to the bottom track that needs to be updated to other free top tracks;

[0014] S103. After migrating the data from the top track to the found free top track, modify / rewrite the data in the bottom track to update the data.

[0015] Furthermore, in step S101, the number of tracks updated is Track_update_total, and the number of updates per track is Track_update_num. i The bottom magnetic tracks with more than the average number of updates are hot magnetic tracks, and those with less than the average number of updates are cold magnetic tracks.

[0016] Furthermore, the cumulative update count (Track_update_sum) and average value (Track_update_avg) of the bottom track are as follows:

[0017]

[0018]

[0019] Where Track_update_sum is the cumulative number of updates to the bottom track, Track_update_avg is the average number of updates to the bottom track, Track_update_total is the total number of updates to all bottom tracks, i is the track number, and Track_update_num is the total number of updates to the bottom track. i This represents the number of updates for the bottom track i.

[0020] Furthermore, in step S102, a top track is searched from near to far where all adjacent bottom tracks are "cold". If no track with all tracks being "cold" is found, the top track with the smallest cumulative update weight among adjacent bottom tracks is searched. The update count of the track and the time since the last update are calculated as follows:

[0021]

[0022] Where Weigh_update is the update weight of the track, Track_update_num is the number of updates for a certain track, and Track_update_total is the time since the last update for this track.

[0023] Specifically, in step S2, in the first stage, the usage is 0% to 55%, and the data is distributed to the bottom magnetic track in order from the outside to the inside.

[0024] Specifically, in step S2, the second stage, the allocation direction is reversed. This is done to reduce the seek time for writing data across stage boundaries and to better protect data locality. Data is allocated every two tracks until one-third of the top track has been used.

[0025] Specifically, in step S2, in the third stage, the allocation direction is still reversed, and data is still allocated to the top track every two tracks until 2 / 3 of the top track has been used.

[0026] Specifically, in step S2, in the fourth stage, the direction is reversed again, and data is allocated to all remaining top tracks.

[0027] Secondly, embodiments of the present invention provide a data management system suitable for IMR, comprising:

[0028] The update module actively migrates data from valid top tracks to other free tracks when updating a bottom track.

[0029] The management module employs a zigzag four-stage data management scheme in the MFML data update strategy. In the first stage, the data of the bottom track is updated; in the second stage, the data of the bottom track is updated using the MFML strategy; in the third and fourth stages, data allocation and bottom track data updates are carried out in the same manner as in the second stage, thus realizing data management.

[0030] Compared with the prior art, the present invention has at least the following beneficial effects:

[0031] A data management method suitable for IMR, the MFML data update strategy, effectively avoids redundant recovery of valid top tracks, significantly reduces the number of read-modify-write (RMW) operations, and improves the performance of IMR disks. Unlike the RMW strategy, which reads adjacent valid top tracks that need updating into the cache and then rewrites them back to their original positions after the bottom track update is complete, the MFML strategy only needs to move them to other free top tracks. This avoids redundant I / O processes, reducing update latency and write amplification. The zigzag four-stage data management scheme in MFML can improve the speed of finding free top tracks, further reducing data update latency. In the four-stage data management scheme, data is allocated by skipping two tracks when allocating top tracks, thus generating more qualified free top tracks during the data update process. When migrating data from valid top tracks, it is easier to find free top tracks, accelerating the data update speed.

[0032] Furthermore, the purpose of the MFML update strategy is to select bottom tracks that need updating based on their hotness or coldness, and migrate valid data from adjacent top tracks to other idle top tracks, thereby completing the data update of the hot bottom tracks. The hotness or coldness of the bottom tracks is determined by the relationship between their cumulative update count and the average update count of all tracks.

[0033] Furthermore, the purpose of calculating hot and cold tracks is to classify them as hot or cold based on the number of track updates. Typically, frequently updated data is labeled as hot data, and infrequently updated data as cold data. Therefore, the MFML strategy uses the average number of updates for all tracks as the threshold for labeling data as hot or cold. Tracks with an update count greater than this threshold are frequently updated tracks (hot tracks), while tracks with an update count less than this threshold are infrequently updated tracks (cold tracks). The threshold is calculated as: total number of updates for all tracks / number of updated tracks (Track_update_total), where the total number of updates for all tracks is based on the update count of each track (Track_update_num). i The summation is obtained by summing the results.

[0034] Furthermore, the purpose of calculating the cumulative number of updates and the average value of the bottom magnetic tracks is to use the average update value as a threshold for dividing the tracks into hot and cold tracks, thereby selecting the bottom hot tracks that need to be updated. The calculation method for the average update value of the bottom magnetic tracks is described in the previous step and will not be repeated here.

[0035] Furthermore, to minimize the cost of data updates when track utilization is too high, as track utilization increases, the number of top tracks adjacent to the cold bottom track decreases, eventually making it impossible to find a suitable top track for data migration during the update process. The track update weight is obtained by dividing the track's update frequency by the time since the last update. A higher update frequency or a shorter time since the last update indicates a frequently updated track, i.e., a "hot" track. The update weight further reflects the track's "hotness" or "coldness." Therefore, based on the bottom track's update weight, suitable top tracks can be found for data migration and bottom track updates, ensuring the MFML strategy remains effective even with high disk utilization.

[0036] Furthermore, when the utilization rate of an IMR disk is between 0% and 55%, only the bottom track is occupied. The track layout determines that when only the bottom track contains valid data, no write amplification will occur during the track update process. The direction of data reading and writing by the read / write head in the disk is from the outer diameter to the inner diameter. Therefore, allocating data to the bottom track from the outside in is consistent with the read / write direction of the head, reducing seek overhead and thus reducing disk I / O latency.

[0037] Furthermore, reversing the allocation direction across stages aims to reduce seek time and protect data locality, while allocating data with a two-track interval aims to find the suitable top track more quickly. If each allocation stage proceeds from the outside in, the same data might be stored separately on the innermost and outermost tracks, resulting in long seek times during data updates and compromising data locality. Reversing the allocation direction ensures that the same data is allocated to adjacent tracks, thus avoiding excessively long seek times and guaranteeing data locality. Allocating data with a two-track interval generates more free top tracks covering bottom tracks during the allocation stage, thereby improving the efficiency of finding the suitable target top track during top track data migration, reducing I / O latency, and improving disk performance.

[0038] Furthermore, reversing the data allocation direction in the third stage reduces the seek time for updating data and ensures data locality, based on the same principle as the previous step. Allocating data to every two tracks at the top ensures that some free top tracks are still reserved during the third stage of data allocation, allowing suitable free top tracks to be found during data migration. This makes the MFML strategy effective even when disk utilization is high.

[0039] Furthermore, reversing the data allocation direction in the fourth stage reduces the seek time for updating data and ensures data locality, based on the same principle as the previous step. In this stage, data is allocated to the remaining top tracks to ensure that the disk is fully utilized and to avoid wasting disk storage space.

[0040] It is understandable that the beneficial effects of the second aspect mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0041] In summary, this invention improves upon the data write amplification phenomenon present in current IMR technology. In simulated tests of IMR disks, it reduces disk write latency, decreases additional I / O operations, accelerates data update speed on the disk, and reduces write amplification, thereby significantly improving the performance of IMR disks.

[0042] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0043] Figure 1 This is a diagram of the migration-before-modification (MFML) update strategy of the present invention;

[0044] Figure 2 This is a diagram of the four-stage zigzag scheme of the present invention. Detailed Implementation

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

[0046] In the description of this invention, it should be understood that the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0047] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0048] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this invention generally indicates that the preceding and following objects have an "or" relationship.

[0049] It should be understood that although terms such as first, second, third, etc., may be used in the embodiments of the present invention to describe the preset range, these preset ranges should not be limited to these terms. These terms are only used to distinguish the preset ranges from one another. For example, without departing from the scope of the embodiments of the present invention, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0050] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0051] The accompanying drawings illustrate various structural schematic diagrams according to embodiments disclosed in this invention. These drawings are not to scale, and some details have been enlarged for clarity, and some details may have been omitted. The shapes of the various regions and layers shown in the drawings, as well as their relative sizes and positional relationships, are merely exemplary and may deviate from reality due to manufacturing tolerances or technical limitations. Furthermore, those skilled in the art can design regions / layers with different shapes, sizes, and relative positions as needed.

[0052] This invention provides a data management method suitable for IMR (Integrated Data Retention), which accelerates data update speed of IMR disks and reduces data write amplification while ensuring crash consistency, thereby enhancing its read and write performance. Furthermore, in conjunction with the MFML (Multi-Fold Matrix Allocation) update strategy, a four-stage zigzag data management scheme is proposed. This scheme avoids disrupting data locality in multi-stage allocation while enhancing the advantages of the MFML algorithm, further improving its performance.

[0053] Both the MFML data update strategy and the zigzag four-stage data management scheme can reduce the write amplification problem in IMR to some extent. Combining the characteristics of both allows the MFML update strategy to perform better in the four-stage data management scheme, while also mitigating the performance degradation caused by excessive top track occupancy in the multi-stage allocation scheme.

[0054] This invention discloses a data management method applicable to IMR, comprising the following steps:

[0055] S1. Since all top tracks of the IMR can be freely updated / written with data, the key idea of ​​the MFML update strategy is to actively "migrate" the data of the valid top tracks to some other free tracks (tracks without data) when updating a bottom track, instead of "backing up" and "restoring" the data through the backup area.

[0056] S101. Calculate the cumulative update count (Track_update_sum) of the bottom tracks and their average value (Track_update_avg). Then, classify the bottom tracks into hot and cold tracks based on the cumulative update count. Bottom tracks with an update count greater than the average value are hot tracks, and those with an update count less than the average value are cold tracks.

[0057] The number of tracks updated is Track_update_total, and the number of updates per track is Track_update_num. i Track_update_sum and Track_update_avg can be calculated:

[0058]

[0059]

[0060] S102. Move the data of the top track adjacent to the bottom track that needs to be updated to other idle top tracks: search for top tracks whose adjacent bottom tracks are all cold from near to far. If no track whose adjacent bottom tracks are all cold can be found, search for the top track with the smallest cumulative update weight among the adjacent bottom tracks.

[0061] A higher update weight for the bottom track indicates a more "hot" bias in the data within that track, while a lower weight indicates a more "cold" bias. This weight is calculated based on the number of track updates and the time elapsed since the last update.

[0062]

[0063] S103. After migrating the data from the top track to the found free top track, modify / rewrite the data in the bottom track to update the data.

[0064] S2. Currently, IMR data management schemes include three-stage data management and an improved zigzag three-stage data management scheme. In the MFML data update strategy, it is necessary to find an idle top track as quickly as possible to migrate data, thereby accelerating the data update speed, better mitigating the write amplification problem, and improving disk performance. Therefore, a zigzag four-stage data management scheme was designed for the MFML update strategy.

[0065] S201, Phase One

[0066] The amount used is less than the capacity of the bottom track (0% to 55% of the amount used), and the data is allocated to the bottom track in order from the outside to the inside.

[0067] S202, Phase Two

[0068] The allocation direction is reversed to reduce seek time for writing data across stage boundaries and to better protect data locality. Data is allocated every two tracks until one-third of the top track has been used.

[0069] S203, Phase Three

[0070] The allocation direction is still reversed, and data is still allocated to the top track every two tracks until 2 / 3 of the top track has been used.

[0071] S204, Phase Four

[0072] Reverse the direction again and allocate data to all remaining top tracks.

[0073] In the first stage, updating the data on the bottom track will not cause write amplification.

[0074] In the second stage, the bottom track is updated using the MFML strategy. Since the top track is allocated data every two tracks, it is easier to find a free top track that meets the requirements. Therefore, the time to find a free track is reduced to a certain extent, and the performance of the MFML algorithm can be better utilized.

[0075] The third and fourth phases continue to allocate data and update the bottom track data in the same manner as the second phase.

[0076] In another embodiment of the present invention, a data management system suitable for IMR is provided. This system can be used to implement the above-mentioned data management method suitable for IMR. Specifically, the data management system suitable for IMR includes an update module and a management module.

[0077] The update module, when updating a bottom track, actively migrates the data of the valid top track to other free tracks;

[0078] The management module employs a zigzag four-stage data management scheme in the MFML data update strategy. In the first stage, the data of the bottom track is updated; in the second stage, the data of the bottom track is updated using the MFML strategy; in the third and fourth stages, data allocation and bottom track data updates are carried out in the same manner as in the second stage, thus realizing data management.

[0079] In another embodiment of the present invention, a terminal device is provided, comprising a processor and a memory. The memory stores a computer program, the computer program including program instructions, and the processor executes the program instructions stored in the computer storage medium. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to implement a corresponding method flow or corresponding function. The processor described in this embodiment of the present invention can be used for operations applicable to IMR data management methods, including:

[0080] When updating a bottom track, the data of the valid top track is actively migrated to other free tracks. In the MFML data update strategy, a zigzag four-stage data management scheme is adopted. In the first stage, the data of the bottom track is updated. In the second stage, the data of the bottom track is updated using the MFML strategy. In the third and fourth stages, the data allocation and bottom track data update are carried out in the same way as the second stage to achieve data management.

[0081] In another embodiment of the present invention, a storage medium is also provided, specifically a computer-readable storage medium (memory). This computer-readable storage medium is a memory device in a terminal device used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the terminal device and extended storage media supported by the terminal device. The computer-readable storage medium provides storage space that stores the terminal's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device.

[0082] One or more instructions stored in a computer-readable storage medium can be loaded and executed by a processor to implement the corresponding steps of the data management method applicable to IMR in the above embodiments; one or more instructions in the computer-readable storage medium are loaded and executed by the processor to perform the following steps:

[0083] When updating a bottom track, the data of the valid top track is actively migrated to other free tracks. In the MFML data update strategy, a zigzag four-stage data management scheme is adopted. In the first stage, the data of the bottom track is updated. In the second stage, the data of the bottom track is updated using the MFML strategy. In the third and fourth stages, the data allocation and bottom track data update are carried out in the same way as the second stage to achieve data management.

[0084] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0085] Table 1. Performance Comparison of RMW and MFML in IMR Disks

[0086]

[0087] The data in the table shows that MFML significantly reduces the write latency of the IMR disk compared to RMW, reduces the number of additional I / O operations, thereby effectively alleviating the write amplification problem and improving the performance of the IMR disk.

[0088] In summary, this invention provides a data management method and system suitable for IMR (Integrated Data Retention), which improves upon the data write amplification problem existing in current IMR technology. In simulated tests of IMR disks, it accelerates data update speed and reduces write amplification, thereby improving IMR disk performance. In practical applications, this invention allows IMR disks to mitigate problems such as data write amplification during data updates while maintaining high data storage density, thus expanding the application areas of IMR disks and reducing data center costs.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0090] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0091] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0092] In the embodiments provided by this invention, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0093] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0094] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0096] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0097] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0098] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0099] The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made to the technical solution based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A data management method suitable for IMR, characterized in that, Includes the following steps: S1. When updating a bottom track, the data from the valid top track is actively migrated to other free tracks. IMR is an interleaved magnetic recording, specifically: S101. Calculate the cumulative number of updates for the bottom track. Track_update_sum And calculate their average value. Track_ update_avg Then, based on the cumulative number of updates, hot magnetic tracks and cold magnetic tracks are divided; S102. Move the top track data adjacent to the bottom track that needs to be updated to other idle top tracks, and search for adjacent bottom tracks from near to far. cold The top magnetic track, if not found, is all cold The track is found by identifying the top track with the smallest cumulative update weight among adjacent bottom tracks. The update count and the time since the last update are used to calculate the track's value. in, Weigh_update The updated weights for the tracks. Track_update_num This represents the number of times a certain track has been updated. Track_update_total This is the time since the last update of the track; S103. After migrating the data from the top track to the found free top track, modify / rewrite the data in the bottom track to update the data. S2. In the MFML data update strategy, a zigzag four-stage data management scheme is adopted. In the first stage, the data of the bottom track is updated; in the second stage, the data of the bottom track is updated using the MFML strategy; in the third and fourth stages, the data allocation and bottom track data update are carried out in the same way as the second stage to achieve data management. In the first stage, the usage is 0%~55%, and the data is allocated to the bottom track in order from the outside to the inside. In the second stage, the allocation direction is reversed, and data is allocated to every two tracks until 1 / 3 of the top track is used. In the third stage, the allocation direction is still reversed, and data is allocated to the top track every two tracks until 2 / 3 of the top track is used. In the fourth stage, the direction is reversed again, and data is allocated to all remaining top tracks.

2. The data management method for IMR according to claim 1, characterized in that, In step S101, the number of updated tracks is: Track_update_total The number of updates per track is Track_update_num i The bottom magnetic tracks with more than the average number of updates are hot magnetic tracks, and those with less than the average number of updates are cold magnetic tracks.

3. The data management method for IMR according to claim 2, characterized in that, Cumulative update count of bottom track Track_update_sum and average Track_update_avg Specifically: in, Track_update_sum This represents the cumulative number of updates to the bottom track. Track_update_avg This represents the average number of updates for the bottom track. Track_update_total To update the total number of bottom tracks, i For track number, Track_ update_num i Bottom track i The number of times it is updated.

4. A data management system suitable for IMR, characterized in that, include: The update module, when updating a bottom track, actively migrates data from valid top tracks to other free tracks. Specifically: Calculate the cumulative number of updates for the bottom track. Track_update_sum And calculate their average value. Track_ update_avg Then, based on the cumulative number of updates, hot magnetic tracks and cold magnetic tracks are divided; Migrate the top track data adjacent to the bottom track that needs updating to other free top tracks, and search for adjacent bottom tracks from near to far. cold The top magnetic track, if not found, is all cold The track is found by identifying the top track with the smallest cumulative update weight among adjacent bottom tracks. The update count and the time since the last update are used to calculate the track's value. in, Weigh_update The updated weights for the tracks. Track_update_num This represents the number of times a certain track has been updated. Track_update_total This is the time since the last update of the track; After migrating the data from the top track to the found free top track, the data in the bottom track is modified / rewritten to update the data. The management module adopts a zigzag four-stage data management scheme in the MFML data update strategy. In the first stage, the data of the bottom track is updated; in the second stage, the data of the bottom track is updated using the MFML strategy; in the third and fourth stages, the data allocation and bottom track data update are carried out in the same way as the second stage to achieve data management. In the first stage, the usage is 0%~55%, and the data is allocated to the bottom track in order from the outside to the inside. In the second stage, the allocation direction is reversed, and data is allocated to every two tracks until 1 / 3 of the top track is used. In the third stage, the allocation direction is still reversed, and data is allocated to the top track every two tracks until 2 / 3 of the top track is used. In the fourth stage, the direction is reversed again, and data is allocated to all remaining top tracks.

5. The data management system for IMR according to claim 4, characterized in that, In step S101, the number of updated tracks is: Track_update_total The number of updates per track is Track_update_num i The bottom magnetic tracks with more than the average number of updates are hot magnetic tracks, and those with less than the average number of updates are cold magnetic tracks.

6. The data management system for IMR according to claim 5, characterized in that, Cumulative update count of bottom track Track_update_sum and average Track_update_avg Specifically: in, Track_update_sum This represents the cumulative number of updates to the bottom track. Track_update_avg This represents the average number of updates for the bottom track. Track_update_total To update the total number of bottom tracks, i For track number, Track_ update_num i Bottom track i The number of times it is updated.

7. A computer-readable storage medium for storing one or more programs, characterized in that, The one or more programs include instructions that, when executed by a computing device, cause the computing device to perform the method of claim 1, 2, or 3.

8. A computing device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including steps for performing the method of claim 1, 2, or 3.

Images