Can TRIM operations be performed in RAID?

Can TRIM operations be performed in RAID?

I wonder if you have considered the following question: can TRIM operations be supported in RAID?

Imagine how to unmap the data block in the SSD by using the TRIM command after the RAID is created on the SSD and the application software (File System) runs directly on the RAID software? It seems that this is not a problem. In fact, it is a big problem for RAID. From the perspective of R & D personnel, Mr. Wu can take a look at the problems introduced by TRIM in RAID and also the issues that users should pay attention.

At present, the open source software for RAID is MD, and many users are very keen on this software. It is believed that the software runs very stably, has good performance, and has complete functions. In addition, many technical staff provide free open-source maintenance for the software. In fact, compared with professional RAID storage software, MD is a demo system. Currently, the TRIM operation of SSD is not supported in the MD software. It does not mean that you do not want to add this function, but it is not easy to add this function, which involves a lot of development workload.

For ssd trim operations, the main idea is to release the ing data block of a logical address (LBA) inside the SSD to improve the SSD performance. This is mainly because the SSD adopts the FTL method internally to Append write all the written data, so when there is no idle resource, SSD needs to start garbage collection to obtain idle resources. Garbage collection has a huge impact on SSD performance. Therefore, if the business can actively release idle resources, the garbage collection inside the SSD will be much easier, thus improving the SSD performance. TRIM is a mechanism for the application layer to actively release idle resources.

When an application is directly deployed on an SSD, it can easily recycle resources by sending TRIM commands to the SSD. However, the situation has changed dramatically after RAID is introduced between the application software and SSD. First, let's look at the next normal RAID data layout, which looks very regular:

In such a data layout, each strip has a data verification block (RAID5). Once a data block in the Strip fails, the data can be restored by verifying the data P. Assume that the file system located above RAID wants to TRIM a data block, which falls in the D data block area of SSD1. What should RAID do for such operations? An intuitive operation is to update the P data block in the Strip after RAID drops the D data block TRIM on SSD1. The reason is that after the TRIM operation, the D data block on SSD1 has changed. To ensure the consistency of the Strip data block, you must update the P data block. The TRIM operation of a data block in a strip triggers updates of the Strip validation data. This is an important cost for TRIM operations in strip RAID.

In fact, the fact is far worse than the Strip update. After a data block in an SSD is TRIM, the data in this data block will become uncertain. For example, after a data block is TRIM, the data read may be the same as the original data block, or it may be zero. The data after the TRIM block changes over time. This depends entirely on the implementation of the SSD internal firmware program. This data uncertainty poses a fatal data correctness problem to RAID. For example, after the D data block in SSD1 is TRIM, the P verification data is updated based on the data after TRIM. After a period of time, the D data block in SSD1 may change. In this case, the data in the entire strip will be in an inconsistent state, affecting the correctness of the data.

From the above analysis, we can see that the TRIM of RAID data is best measured in strip. When all the data in a strip can be TRIM, TRIM operation commands can be sent to SSD. Therefore, in RAID, the TRIM operation is amplified to the band level, instead of the original Sector block level operation.

However, when a RAID device is exposed to users as a block device object at the Sector level, the file system still sends a TRIM operation at the Sector level to RAID. In this case, how does RAID convert a TRIM operation at the Sector level to a TRIM at the band level? This requires the combination of TRIM in RAID. For example, TRIM operations are recorded by using Bitmap. After the TRIM operations are merged to a certain extent, TRIM operations are performed on the entire belt. This design will cause great implementation complexity, and there are still many problems to consider, such as Bitmap memory usage, abnormal power loss and other problems. Therefore, it is not easy to handle TRIM problems with an excellent RAID data protection software.

(From bucket's blog-storage path)

How to build a RAID 10 array on Linux

Debian soft RAID Installation notes-use mdadm to install RAID1

Common RAID technology introduction and demo (Multi-chart)

The most common disk array in Linux-RAID 5

RAID0 + 1 and RAID5 Performance Test Results

Getting started with Linux: disk array (RAID)

This article permanently updates the link address: