There are many factors that can influence the occurrence of corrupted data on a storage device, and one of the advantages of SSDs is that protection and even remediation mechanisms can be built into the controller itself, as is the case. case with the SSD. Recently released NVMe 1.4 protocol. Today we’re going to take an in-depth look at one of these mechanisms, perhaps the most important for preventing data corruption.
Read Recovery Level (RRL) in NVMe 1.4 SSD
The NVMe 1.4 specification (be careful as this feature we are talking about is not built into previous versions) introduces several new features to help deal with unrecoverable read errors and corrupted data, especially in RAID configurations and similar scenarios where the host system can recover the disrupted data much faster just by deleting it from another location. Let’s explain it.
The Read Recovery Level feature allows the host system (the controller, essentially) to configure how hard the SSD should attempt to recover corrupted data in the event of a problem. Los SSD suelen tener varias capas de corrección de errores (ECC) como podéis ver en la imagen de arriba, y cada una de las capas es más robusta pero al mismo tiempo más lenta (penaliza el rendimiento) y consume más energía, generando más calor at the same time.
In a RAID 1 or similar scenario, the host system will generally prefer to quickly get rid of an error by simply trying to read the same data that has been corrupted on one SSD into another of the drives that make up the RAID configuration, replacing the data. corrupted to continue functioning normally. Until now, the SSD had to try to correct the problem on its own with the ECC mechanisms, slowing the performance of the unit and greatly increasing the consumption of power and heat produced; Moreover, this method does not guarantee recovery of corrupted data, although it works well when simple read errors occur.
NVMe already supports Time-Limited Error Recovery (TLER), but this only allows the host system to limit error handling time in 100ms increments. Read recovery levels allow readers to provide up to 16 different levels of error handling policies, but readers that implement this feature only need to actually implement a minimum of two levels to meet the requirements. NVMe 1.4 standard. This functionality is defined at the assembly level by NVM.
Fatal read errors on SSDs
To proactively avoid fatal read errors, the NVMe 1.4 specification also adds the Verify and Get LBA Status commands. The Verify command is simple: it does everything a normal read command does except return data to the host system, but except that if a read command returns an error, a verify command will return the data to the host system. same error. If a read command succeeds, the Check command will also be successful.
This allows low-level cleaning of stored data without being bogged down by host interface bandwidth. Some SSDs will react to a fixable ECC error by moving or rewriting degraded or corrupted data, and a verify command will trigger the same behavior. In general, this reduces the need for debugging and checksum verification at the file system level, which does not improve performance, but prevents performance degradation. Each check command is labeled with a bit that indicates whether the SSD should quickly ignore the error or attempt to recover data, similar but overriding the read recovery level setting.
For its part, the Get LBA Status function allows the unit to provide the host with a list of blocks that may cause fatal read errors if a read or verify command is attempted on them; In other words, the controller is able to first compile a list of data that may be faulty and / or problematic, before errors occur.
The SSD may already have detected ECC errors during the background autoscan, or in severe cases, it may report which LBAs are affected by a channel failure or a full NAND fabric. The Get LBA Status function can also be used to instruct the SSD to perform a scan of the selected data ranges before returning the list of potentially unrecoverable blocks.
When the host system finds out that there is corrupt or missing data, either through the Get LBA Status function, issuing normal read commands, or using the Verify function, it can write that data to the same LBA using a copy obtained from somewhere else (like in a RAID system or in a backup), then continue to use those logical blocks normally, while the SSD will remove any bad physical blocks if necessary.
As you can see, these are just a few of the mechanisms SSDs have to preserve data integrity when problems arise in the unit, and with each new revision of the standards (which as in this case , are from the NVMe 1.4 standard), the mechanisms for detecting, protecting and resolving problems continue to be improved. However, we must remember that despite all that can happen irreversible errors that end up damaging the unit, no one is exempt (as of yet).
