Record Gain. Part 2

In the previous article, we discussed recording enhancement, discussing where it comes from and what is bad for your SSD. We also began to consider the factors affecting Write Amplification. Today we will continue this discussion.



Data redundancy

The next factor affecting the recording gain is data overheading (overprovisioning). Redundancy shows the difference between the actual capacity of the device and the amount available for the operating system, and is calculated by the formula:



( - ) /



During garbage collection, leveling wear, and remapping bad blocks, the SSD controller uses this “extra” space to reduce write gain. Therefore, this factor is variable (that is, the WA level depends on its value) and inverse (the higher its value, the lower the WA level).

')





The first level of redundancy to SSD developers was “presented” by the habit of traditional HDD manufacturers to measure the volume in “decimal” gigabytes, instead of the usual “binary” gibibytes. SSD memory cells store single bits organized into bytes, then into cybits and so on until gibbytes, although the capacity of the finished product is declared in gigabytes. The difference between these values ​​in reality is 7.37%, and usually this volume is used for official needs, although it is not considered to be the traditional volume of “redundancy”.



The second level of redundancy is laid by the manufacturer, and is usually 0%, 7%, or 22%. For example, based on chips with a capacity of 128 Gb, a manufacturer can produce SSDs with a capacity of 100 Gb, 120 Gb and 128 Gb, which gives us 22%, 7% or 0%, respectively.



The third level of redundancy is due to the user, allowing him to gain in speed and reliability by sacrificing part of the disk. This can be done either using the configuration utility, which bites off the disk for internal use, or simply by leaving unallocated space on the disk. It is worth noting that this method is still a thing of the past, since the development of modern SSD controllers (including SandForce solutions from LSI) makes it possible to do without it, using the redundancy provided by the manufacturer.







TRIM

The presence of the TRIM command is a binary factor, and its presence is a factor that has the opposite effect on recording gain (in other words, it reduces WA).



Much has been written about TRIM, but just in case, I will repeat it briefly. TRIM is an ATA interface command (in SCSI there are similar TRIM commands UNMAP and WRITE SAME), with the help of which the operating system can inform the drive about which blocks are no longer used due to the fact that the files contained in them are deleted or the partition is generally formatted . Having received this useful information from the OS, the SSD marks the indicated sectors as being in the “incorrect” state and does not attempt to preserve its content during further garbage collection operations.



As a result of using the TRIM command, SSD can sometimes significantly reduce the amount of data rewritable during garbage collection, and thus reduce WA.



At the moment, almost all modern operating systems support this command in one way or another, although previously it was sometimes necessary to use special utilities that collected information about free blocks by operating system methods and transferred it to the disk using the TRIM command sequence.



Of course, the team should support the disk itself, but nowadays SSDs without TRIM support are already infrequent exotic.



Free place

As I wrote in the section on data redundancy, the free space also affects WA, so I’ll just note this factor again, it is variable and is also inversely proportional to the recording gain.



Safe erase

A separate ATA command is designed for complete safe disk cleaning. If the SSD does not use hardware encryption, after this command, the disk actually returns to the same state as the factory one. This increases its performance to the maximum possible level, and the recording gain reduces it to a minimum. Of course, as these indicators are filled, they deviate from their ideal states.



On-the-fly encryption drives can perform a secure erase command differently. It is enough for them to reset the current encryption key and generate a new one, after which the data will become unreadable. In this case, to restore maximum performance, a TRIM command is also needed, which will indicate that you no longer need the data in any way.



Wear leveling

As I wrote in the article about the history of FLASH, all memory cells have a limit on the number of maximum possible rewrite cycles. Obviously, some cells will be overwritten more often, some less, which will lead to premature failure of some cells. The first candidates for this are the initial disk areas where OS service tables are traditionally stored. Of course, the disk can “replace” the faulty cells with other ones, from among the “redundant” ones, in the end the remapping process was invented long before the SSD, but modern flash drives try to prevent this from happening for as long as possible.



This is done using the “wear leveling” process: SSDs are written to all cells at regular intervals, changing them periodically. In theory, this allows you to use all the cells to the maximum, before they fail. In practice, this process must be performed very thoughtfully. Wear leveling requires that data that was once written and no longer overwritten (cold) was periodically transferred to another place in order to enable the recording of frequently changing (hot) data to those cells that were occupied by the cold. As you already understand, this leads to increased recording and disc wear.



In this case, the task of manufacturers of controllers is to find compromise algorithms that allow to maximize both indicators not to the detriment of each other.



Other methods

Also, modern SSD controllers produce a number of more complex optimizations, some of which I briefly mentioned in the previous article, to improve WA performance.



It is clear that not all data on a disk is changed with the same frequency. There is dynamic data, and there is static. Separating them in different areas of the disk is often a good idea, as this will allow you not to "touch" static data blocks when overwriting. The main disadvantage of this process is that it comes into conflict with the alignment of wear, requiring the most uniform load cells.



It is also easy to understand that the data on the SSD is better to record and erase sequentially. This facilitates the work of all the algorithms of the controller, so often in the disks different tricks are used to reduce the number of "random" write operations.



Not a single diplomat in the world has to make such compromises, which are SSD controllers (and their developers), and the complexity of modern controllers increases, opening up new opportunities for optimization. I think in one of the following articles I will return to the topic of SSD controllers and talk about their work on a specific example of the SandForce family from LSI.