Background
In a personal computer or an enterprise-level data center, SSD (Solid State Drive) is becoming more and more popular because of its superior characteristics of io throughput/command latency. Firmware of a solid state disk needs to maintain an L2P mapping table (Logical to Physical mapping table, mapping table of Logical to Physical addresses in the solid state disk) from LBA (Logical block address, address allocated to each piece of data by host) to PPA (Physical PageAddress, here referring to address in the solid state disk) for address translation of read and write operations.
As the single-disk capacity of the solid state disk is becoming larger and larger, the capacity that L2P needs to represent is also increasing, for example, if a solid state disk with a logical capacity of 2TB is in page base mapping (page mapping manner) of 4K units, each PPA occupies 4 bytes, and then the entire L2P table has a size of 2 GB. Whatever mapping method is adopted: it is becoming more and more difficult how to recover the L2P mapping table in a very fast time when the solid state disk is powered on.
At present, the applications of solid state disk are roughly divided into two types, one is used as a system disk, namely a boot disk which is usually provided with an operating system; the other is a data disk, which is not provided with an operating system and only has application data stored by a host.
For a system disk, no matter whether the system disk is applied to a personal computer or an enterprise storage array, when the system disk is powered on, a corresponding ADMIN command is removed, and mainly a read command is firstly sent to load boot partition information (in a mode of MBR or GPT, etc.) and an operating system (windows/linux, etc.), and with respect to a personal PC environment under a mainstream windows operating system, a main starting process for a SATA solid state disk is as follows:
and 1, starting the BIOS to enter a POST (power on recovery) process, and simultaneously supplying power to the solid state disk.
2. After the initialization of the SATA physical layer and the link layer is completed, the BIOS initializes the solid state disk by sending ATA commands such as Identify/Get feature.
And 3, reading the information such as the boot partition and the like by the BIOS, and confirming the information such as the position of the operating system and the like.
And 4, reading the operating system by the BIOS, and transferring the control right to the operating system after loading.
5. And initializing the operating system and reading internal files of the corresponding operating system.
6. And after the initialization of the operating system is finished, reading information such as system drive and the like, loading the information, and entering a user interface of the operating system.
In the above-listed steps, the data that the host (here, system BIOS and operating system) needs to read during power-up is the fixed LBA, and this part of data is "extremely cold" data for the solid state disk, that is, the number of times of updating is written is very small, for example, the operating system itself, and may be read only when power-up.
For this situation, the SSD firmware needs to "learn" which LBAs are needed for power up, and needs to maintain a bootup reference LBA table (start-up related data management table) to record these LBAs, and may add and replace corresponding LBAs according to specific situations. Meanwhile, the SSD firmware also writes the startup related data management table into the flash memory according to a certain algorithm when necessary, so as to ensure that the table can be found very quickly when powered on.
It is also important that data integrity must be guaranteed. Whether a normal power loss recovery process or an abnormal power loss recovery process, this table must point to the latest and correct LBA location. Because these data are critical data to the system, if lost or data corrupted, it is likely that the system will not boot.
The conventional method for the mapping table of the L2P power-on recovery at present is as follows: according to the requirement, L2P is mapped by SSD firmware to serve as meta data (metadata, which refers to key information recorded in SSD firmware) inside the system, the meta data is written into a flash memory regularly or irregularly, no matter the flash memory is powered on and restored in normal power failure (for SATA solid state disk, PM (power management) commands such as Standby media/Idle media are sent before the system is powered off), or in abnormal power failure (namely, a host does not give a corresponding shutdown signal) for NVME solid state disk, the system can map and read pages of L2P in sequence according to the data writing sequence, the L2P is used for restoring and rebuilding a L2P mapping table, and if the L2P mapping table exists, the SSD can normally respond to any read-write command sent by the host.
As described above, the solid state disk will only respond to the read/write command sent by the host if all recovery (power-on reconstruction) of the entire L2P mapping table is completed. When the recovery process of L2P becomes slow, the time that the solid state disk can respond to the system command becomes longer. Especially for abnormal power failure, the SSD firmware may not write the required recovery L2P mapping information into the flash memory in time, in this case, the SSD firmware needs to scan a large amount of data written by the host, recover the L2P mapping by reading the metadata corresponding to each piece of host data, and remove the data integrity problem, and the problems caused by such method are mainly two:
(1) the power-up time becomes longer. For example, in a solid state disk with a capacity of 2TB, a solid state disk FTL (flash translation Layer, a part of the solid state disk firmware, responsible for maintaining an L2P mapping table) firmware adopts a page mapping environment, and if power is abnormally turned off, 50G of capacity needs to be scanned, and if the bottom Layer read bandwidth is 2GB/s, then the whole scanning process needs at least 25 s.
(2) The power-up recovery time becomes uncertain. Particularly, in the case of abnormal power failure, the time point of the power failure is unpredictable, so the data amount to be scanned by the solid state disk FTL firmware is also unfixed, and the recovery time brought by the data amount is also unfixed.
Some manufacturers, in order to solve this problem, the action frequency of mapping writes to the flash memory is increased to shorten the power-on time, and this refresh method usually writes the mapping corresponding to the hottest data (i.e. the data that is newly written by the host and is likely to be frequently operated) to the flash memory frequently, which brings the following problems:
a. write Amplification (WA) affects the lifetime of the solid state disk, as more metadata is written to the flash memory.
b. Performance impact. Writing the map into the flash memory certainly occupies the bandwidth of the underlying flash memory, and the writing performance of the solid state disk is affected during the period of writing the map into the flash memory.
c. Although the hottest mapping data is written frequently, during the power-on recovery process, the data that the host first operates is not so-called cold data such as the boot partition, the operating system, and the like. These hot data write algorithms can speed up the entire L2P mapping recovery process, but these mappings take a lot of time to recover, and not the data that can be accessed by the host first.
In the existing scheme, no matter how frequently mapping and writing are increased into a flash memory, or other ways such as increasing a log similar to L2P, the whole L2P is required to be recovered, and then the read-write command sent by a host can be normally responded. How to learn by itself, learn and quickly recover the LBA which is actually read first in the power-on process, and adaptively match each power-on process of the host, so as to optimize the FTL algorithm, thereby shortening and fixing the power-on response time of the SSD.
Disclosure of Invention
The present invention is directed to overcome the above-mentioned drawbacks of the background art, and provides a method and a system for shortening a power-on time of a solid state disk as a system disk, which can shorten and fix a power-on response time of an SSD.
The invention provides a method for shortening power-on time of a solid state disk serving as a system disk, which comprises the following steps:
the starting related data management table records the LBA table items read in each power-on process, and when the SSD firmware detects power-on, the starting related data management table is loaded into the SSD memory, and the LBA table items in the starting related data management table are sequentially updated to the L2P table until the L2P is successfully rebuilt;
in the power-on process, if the host reading request hits the LBA table entry in the L2P table, the host reading request is directly responded; if not, wait for L2P to rebuild successfully and then respond.
On the basis of the technical scheme, the method further comprises the following steps:
in the power-on process, if the number of times of hit of the host read request reaches the preset number of times, the SSD firmware accumulates and starts the read times in the related data management table.
On the basis of the technical scheme, the method further comprises the following steps:
in the power-on process, if a certain LBA table entry is not in the startup related data management table, the LBA table entries with the lowest reading times are replaced in sequence.
On the basis of the above technical solution, the specific process of sequentially replacing LBA entries with the lowest read times includes: in the electrifying process, if the maximum value of the reading times of each LBA table entry is a preset value and is a signed number, the LBA table entry is hit each time; if the reading times are smaller than the preset value, accumulating the reading times; if the reading times are equal to the preset value, maintaining the preset value unchanged; if the LBA entry does not hit, the number of reads is reduced by one.
On the basis of the technical scheme, the method further comprises the following steps:
and (3) sorting and establishing a queue according to the reading sequence of the starting related data management table:
the smaller the reading sequence is, the earlier the reading is, after the initialization of the related data management table is started, each LBA table entry in the table is loaded to the L2P table, and other table entries in the L2P table are initialized to a fixed format representing illegal values; after receiving a host reading request, the SSD firmware searches an L2P table, if the LBA table entry is not an illegal value, the LBA table entry is hit by starting a related data management table, and then the SSD firmware searches a well-ordered sequence according to a current reading sequence as an index to find the LBA table entry;
when the host reads the request and does not hit and start the relevant data management table, the LBA table items are replaced according to the order of the reading times; arranging negative LBA entries into a queue from small to large according to the reading times, replacing from the tail part every time, and updating the reading sequence, the reading times and the PPA domain;
finally, when all power-on actions are completed and L2P is completely recovered, the startup related data management tables are sorted again according to the reading sequence and stored in the flash memory for the next use.
The invention also provides a system for shortening the power-on time of the solid state disk as a system disk, which comprises an L2P table reconstruction unit and a response unit, wherein:
L2P table reconstruction unit for: the starting related data management table records the LBA table items read in each power-on process, and when the SSD firmware detects power-on, the starting related data management table is loaded into the SSD memory, and the LBA table items in the starting related data management table are sequentially updated to the L2P table until the L2P table is successfully rebuilt;
the response unit is used for: in the power-on process, if the host reading request hits the LBA table entry in the L2P table, the host reading request is directly responded; if not, wait for L2P to rebuild successfully and then respond.
On the basis of the above technical solution, the system further includes a reading number accumulation unit configured to: in the power-on process, if the number of times of hit of the host read request reaches the preset number of times, the SSD firmware accumulates and starts the read times in the related data management table.
On the basis of the above technical solution, the system further includes an LBA entry replacement unit configured to: in the power-on process, if a certain LBA table entry is not in the startup related data management table, the LBA table entries with the lowest reading times are replaced in sequence.
On the basis of the above technical solution, the specific process of sequentially replacing LBA entries with the lowest read times includes: in the electrifying process, if the maximum value of the reading times of each LBA table entry is a preset value and is a signed number, the LBA table entry is hit each time; if the reading times are smaller than the preset value, accumulating the reading times; if the reading times are equal to the preset value, keeping unchanged; if the LBA entry does not hit, the number of reads is reduced by one.
On the basis of the above technical solution, the system further includes a queue establishing unit, configured to: and (3) sorting and establishing a queue according to the reading sequence of the starting related data management table:
the smaller the reading sequence is, the earlier the reading is, after the initialization of the related data management table is started, each LBA table entry in the table is loaded to the L2P table, and other table entries in the L2P table are initialized to a fixed format representing illegal values; after receiving a host reading request, the SSD firmware searches an L2P table, if the LBA table entry is not an illegal value, the LBA table entry is hit by starting a related data management table, and then the SSD firmware searches a well-ordered sequence according to a current reading sequence as an index to find the LBA table entry;
when the host reads the request and does not hit and start the relevant data management table, the LBA table items are replaced according to the order of the reading times; arranging negative LBA entries into a queue from small to large according to the reading times, replacing from the tail part every time, and updating the reading sequence, the reading times and the PPA domain;
finally, when all power-on actions are completed and L2P is completely recovered, the startup related data management tables are sorted again according to the reading sequence and stored in the flash memory for the next use.
Compared with the prior art, the invention has the following advantages:
the starting related data management table records the LBA table items read in each power-on process, and when the SSD firmware detects power-on, the starting related data management table is loaded into the SSD memory, and the LBA table items in the starting related data management table are sequentially updated to the L2P table until the L2P is successfully rebuilt; in the power-on process, if the host reading request hits the LBA table entry in the L2P table, the host reading request is directly responded; if not, wait for L2P to rebuild successfully and then respond. The invention can obviously improve the starting experience of the high-capacity solid state disk serving as the system disk and shorten and fix the power-on response time of the SSD. The power-on time is greatly shortened and kept stable no matter the power-on recovery after normal power failure or the power-on recovery after abnormal power failure.
Detailed Description
The invention is described in further detail below with reference to the figures and the embodiments.
The embodiment of the invention provides a method for shortening power-on time of a solid state disk serving as a system disk, which comprises the following steps:
the starting related data management table records the LBA table items read in each power-on process, and when the SSD firmware detects power-on, the starting related data management table is loaded into the SSD memory, and the LBA table items in the starting related data management table are sequentially updated to the L2P table until the L2P is successfully rebuilt;
in the power-on process, if the host reading request hits the LBA table entry in the L2P table, the host reading request is directly responded; if not, wait for L2P to rebuild successfully and then respond.
In the power-on process, if the number of times of hit of the host read request reaches the preset number of times, the SSD firmware accumulates and starts the read times in the related data management table.
In the power-on process, if a certain LBA table entry is not in the startup related data management table, the LBA table entry with the lowest reading times is replaced in sequence, and the specific process is as follows: in the electrifying process, if the maximum value of the reading times of each LBA table entry is a preset value and is a signed number, the LBA table entry is hit each time; if the reading times are smaller than the preset value, accumulating the reading times; if the reading times are equal to the preset value, maintaining the preset value unchanged; if the LBA entry does not hit, the number of reads is reduced by one.
And (3) sorting and establishing a queue according to the reading sequence of the starting related data management table:
the smaller the reading sequence is, the earlier the reading is, after the initialization of the related data management table is started, each LBA table entry in the table is loaded to the L2P table, and other table entries in the L2P table are initialized to a fixed format representing illegal values; after receiving a host reading request, the SSD firmware searches an L2P table, if the LBA table entry is not an illegal value, the LBA table entry is hit by starting a related data management table, and then the SSD firmware searches a well-ordered sequence according to a current reading sequence as an index to find the LBA table entry;
when the host reads the request and does not hit and start the relevant data management table, the LBA table items are replaced according to the order of the reading times; arranging negative LBA entries into a queue from small to large according to the reading times, replacing from the tail part every time, and updating the reading sequence, the reading times and the PPA domain;
finally, when all power-on actions are completed and L2P is completely recovered, the startup related data management tables are sorted again according to the reading sequence and stored in the flash memory for the next use.
The embodiment of the present invention further provides a system for shortening power-on time of a solid state disk as a system disk, where the system includes an L2P table rebuilding unit, a response unit, a reading number accumulation unit, an LBA table item replacement unit, and a queue establishing unit, where:
L2P table reconstruction unit for: the startup related data management table records the LBA entries read in each power-on process, and when the SSD firmware detects power-on, the startup related data management table is loaded into the SSD memory, and the LBA entries in the startup related data management table are sequentially updated to the L2P table until the L2P table is successfully rebuilt.
The response unit is used for: in the power-on process, if the host reading request hits the LBA table entry in the L2P table, the host reading request is directly responded; if not, wait for L2P to rebuild successfully and then respond.
A read number accumulation unit configured to: in the power-on process, if the number of times of hit of the host read request reaches the preset number of times, the SSD firmware accumulates and starts the read times in the related data management table.
An LBA entry replacement unit to: in the power-on process, if a certain LBA table entry is not in the startup related data management table, the LBA table entry with the lowest reading times is replaced in sequence, and the specific process is as follows: in the electrifying process, if the maximum value of the reading times of each LBA table entry is a preset value and is a signed number, the LBA table entry is hit each time; if the reading times are smaller than the preset value, accumulating the reading times; if the reading times are equal to the preset value, keeping unchanged; if the LBA entry does not hit, the number of reads is reduced by one.
A queue establishing unit configured to: and (3) sorting and establishing a queue according to the reading sequence of the starting related data management table:
the smaller the reading sequence is, the earlier the reading is, after the initialization of the related data management table is started, each LBA table entry in the table is loaded to the L2P table, and other table entries in the L2P table are initialized to a fixed format representing illegal values; after receiving a host reading request, the SSD firmware searches an L2P table, if the LBA table entry is not an illegal value, the LBA table entry is hit by starting a related data management table, and then the SSD firmware searches a well-ordered sequence according to a current reading sequence as an index to find the LBA table entry;
when the host reads the request and does not hit and start the relevant data management table, the LBA table items are replaced according to the order of the reading times; arranging negative LBA entries into a queue from small to large according to the reading times, replacing from the tail part every time, and updating the reading sequence, the reading times and the PPA domain;
finally, when all power-on actions are completed and L2P is completely recovered, the startup related data management tables are sorted again according to the reading sequence and stored in the flash memory for the next use.
The principles of embodiments of the present invention are explained in detail below.
The boot reference LBA table (boot-related data management table) is maintained by the SSD firmware, and is used to record the LBA read in each power-on process and the like, and when and how many times the LBA is updated, and is read, so as to determine whether to update/replace the LBA therein, which is specifically defined as shown in fig. 1, where the contents are as follows:
byte 0-3: the LBA represents an LBA address accessed by power-on, and the bit width needs to be determined according to the maximum LBA bit width supported by the current SSD firmware, which is represented by 4 bytes;
byte 4-7: PPA, which represents the PPA location to which this LBA is mapped. This mapping must be consistent with the current L2P table. Similarly, the bit width is based on the bit width defined by the current SSD firmware, and is also represented by 4 bytes;
byte 8-15: read Order, which represents the Order in which this LBA is Read during power-up;
byte 16: read Count, the number of times this LBA is Read in the power-on process, the larger the number of times, the more necessary it is in the power-on process;
byte 17: next pointer, which is used as the Next launch-related data management table in the linked list structure.
The conditions of SSD memory usage, SSD capacity and the like are comprehensively considered, the space of each table entry is reasonably distributed, and the reasonable size is customized. As to how many entries there are, how many LBAs can be recorded and replaced, taking 100 as an example, the whole table needs 100 × 18 — 1800 bytes, and if each PPA represents a data space of 4K size, 100 × 4K can represent: data of 4M size can be recorded and very quickly recovered during power up.
And (3) electrifying:
each time the SSD firmware detects the start of power-up, before the entire L2P mapping table is restored, the startup-related data management table needs to be found, and after the start-related data management table is found and loaded into the SSD memory, each LBA table entry in the table is sequentially updated to the L2P table, and at this time, a abbreviated version of the L2P table is successfully rebuilt. In the power-on process, if the host reading request hits the LBA table entries, the host reading request can be directly responded; if not, then the L2P will wait for the response after the reconstruction was successful.
During the power-up process, if the number of times that the host read request is hit reaches a preset value, for example, 50 times, the SSD firmware needs to accumulate the read times in the startup related data management table, and as the power-up times increase, the read times of some LBAs become larger and larger, and naturally, these LBAs are more needed by the system power-up process.
If a certain LBA is not in the startup-related data management table, the entries with the lowest read times need to be replaced sequentially. It is noted here that in most cases, as a system disk, the LBAs in this table are not replaced. LBAs with low read times can be replaced with confidence. However, considering that the operating system changes or the application environment of the solid state disk changes violently, there is a possibility that a great number of entries are not hit, and at this time, if the number of times of reading the entries has been accumulated to a relatively large value, a misjudgment may be caused, which is specifically as follows:
1. assume that the startup-related data management table has 5 entries, which record LBA0-4, respectively, and the number of reads is shown in the following table:
LBA
|
0
|
1
|
2
|
3
|
4
|
number of readings
|
255
|
255
|
255
|
10
|
10 |
Example 1: if the LBA0-4 is not hit at a certain time, if the LBA0-4 is replaced with a new LBA, it is likely that the LBA0-4 still needs to be read in a subsequent power-on process, for example, a user pulls down the SSD used as the system disk, inserts the SSD into another machine as a data disk, puts the disk back to be used as the system disk after copy, and then hits the LBA0-4, which is repeated, not only does not increase the hit probability, but also causes the boot-related data management table to be written into the flash memory too frequently, which affects the write amplification of the solid state disk.
Example 2: still, if the LBA0-4 is not commanded at a certain time, and only the LBA3 and the LBA4 with a small reading number are replaced, if the situation is the same later, that is, the LBA0-4 will not hit any more, then 255 power-up processes are needed at most to replace all the entries, and the acceleration effect is obviously not achieved.
There are of course many other situations that can lead to SSD firmware misjudgment, and the solution takes the following approaches: in the power-on process, if the maximum value of the reading times of each table entry is 10 (or other reasonable values) and is a signed number, the table entry is hit each time; if the reading times are less than 10, accumulating the reading times; if the value is equal to 10, keeping 10 unchanged; if the LBA does not hit, the number of reads is reduced by one, which can be a negative value. If a new LBA entry is added, count accumulation is started from 0, and a negative entry is replaced, so that by increasing and decreasing the number of reads, LBA replacement can be completed substantially 5 times, and meanwhile, the recorded entry in the startup related data management table caused by other operations within 5 times of the user can be prevented from being replaced quickly, which includes the following specific processes:
1. the initial LBA entry is as follows:
LBA2, LBA3, LBA4 miss, the number of reads is reduced by one:
LBA
|
0
|
1
|
2
|
3
|
4
|
|
|
|
|
|
|
number of readings
|
5
|
5
|
4
|
4
|
4
|
|
|
|
|
|
|
LBA2, LBA3, LBA4 miss 4 times, the number of reads is reduced to a negative value:
LBA
|
0
|
1
|
2
|
3
|
4
|
|
|
|
|
|
|
number of readings
|
5
|
5
|
-1
|
-1
|
-1
|
|
|
|
|
|
|
LBA5, LBA6, LBA7 hit continuously, LBA2, LBA3, LBA4 are all replaced.
LBA
|
0
|
1
|
5
|
6
|
7
|
|
|
|
|
|
|
Number of readings
|
5
|
5
|
1
|
1
|
1
|
|
|
|
|
|
|
In order to quickly search the starting related data management table when the power is on, a queue is established according to the reading sequence of the starting related data management table.
1. The smaller the read sequence, the earlier the read sequence is indicated, so that after initialization of the startup-related data management table, each LBA entry therein is loaded into the L2P table, and the other entries in the L2P table are initialized to a fixed format representing illegal values, such as all 0's or all 1's. Firstly, after receiving a host read request, the SSD firmware searches the L2P table, if the entry is not an illegal value, it indicates that the entry is hit by starting the related data management table, and then searches the sorted order according to the current read order as an index to find the LBA entry.
2. The number of times of reading is negative, which indicates that the table entry can be replaced, so that during initialization, the number of times of reading which table entries are to be found is negative and recorded, and when a host reading request does not hit and start the relevant data management table, the table entries are replaced according to the order of the number of times of reading. The entries which are negative numbers can be arranged into a queue from small to large through the number of reading, each replacement is started from the tail, and the reading sequence, the number of reading, the PPA and other fields are updated.
Finally, when all power-on actions are completed and L2P is fully recovered, the startup related data management table needs to be sorted again according to the reading order and stored in the flash memory for the next use.
3. Power-on content update and maintenance
After the power-on action is completed, the LBA entries in the startup-related data management table may be updated at any time, and may be rewritten to a new location by a host write request, or may be moved to a new location as required by internal modules such as a garbel collection (garbage collection mechanism) and a wear leveling (wear leveling algorithm) inside the SSD, so that the SSD firmware must update a new mapping to the startup-related data management table in time. If each host write request is looked up in the startup related data management table, and in the case of a large number of entries, the code overhead may be large, then the PPA location recorded therein may be updated by periodically traversing each LBA of the records to look up L2P in the background or before the table needs to be refreshed and written to the flash memory. If the time for a single update is too long, it can be handled in view of fragmentation.
4. Mechanism for refreshing write flash memory
The related data management table needs to be written into the flash memory for starting, and the SSD firmware needs to find the position quickly and load the position in the power-on process. There may be many options, if the solid state disk is provided with a nor flash (a non-volatile flash memory) as an auxiliary for power-on start, the content may be stored in a fixed position of the nor flash, and it is only necessary to directly read the loading of the nor flash each time power is turned on. For a solid state disk without a nor flash, a startup related data management table needs to be stored in the flash memory.
die is a set of blocks, and there are several die in a flash chip, and the page0 (page 0) of the block (block) in each die0 (block set 0) can be written, and the SSD firmware first finds out which block of die0 is the block that was written most recently before the power failure, then on page0, there is a startup related data management table, but the table is not necessarily the latest, and there may be a recorded update of LBA after writing the startup related data management table, for normal power failure, the last written PPA position before the power failure, and then a startup related data management table is written, so as to find out the last page position, the startup related data management table is directly read, as shown in fig. 2, and as long as the last page table is copied, the complete startup related data management table is read.
For power-up recovery of abnormal power failure, that is, there may be no startup related data management table in the last written location found by power-up, in this case, a table stored in page0 of the die0 block that is written last needs to be read out first, and then patch into the L2P table, and then the L2P table is updated by scanning the metadata of the last written block, so that a mapping table completely containing all LBAs in the startup related data management table is available for subsequent actions. The data in the rectangular frame with the background of the dot matrix in fig. 3 is the area that needs to be scanned to recover the startup of the relevant data management table in the case of abnormal power failure.
Various modifications and variations of the embodiments of the present invention may be made by those skilled in the art, and they are also within the scope of the present invention, provided they are within the scope of the claims of the present invention and their equivalents.
What is not described in detail in the specification is prior art that is well known to those skilled in the art.