中可以做 *** 作吗？

RAID中可以做TRIM *** 作吗？

不知道大家有没有考虑过这样一个难题:TRIM *** 作可以应用在RAID中吗？

想象一下，在SSD上创建RAID后，系统软件(系统文件)立刻运行在RAID手机软件之上，那么如何根据TRIM指令去映射SSD中的数据块？看起来不是问题，实际上是RAID的大问题。存储胡夫可以带领大家从R&D人员的角度探讨RAID中TRIM引入的问题，从中也可以窥见客户应该注意的问题。

目前RAID级别的开源项目是MD，很多客户对MD这种手机软件非常热衷。我觉得这个手机软件运行非常流畅，性能优秀，功能齐全，也有很多专业技术人员进行完全免费的开源系统维护。实际上，与技术专业的RAID存储软件相比，MD是一个试用的系统软件。目前MD手机软件不兼容SSD的TRIM *** 作，不是不愿意加这个功能，而是加这个功能不容易，会涉及大量的开发和设计劳动。

对于SSD的TRIM *** 作，关键思想是根据SSD中一个逻辑详细地址(LBA)释放的投影数据块来提高SSD本身的性能。这主要是因为SSD中使用了FTL的方法，所有加载的数据都使用追加写入。因此，当没有空剩余资源时，SSD必须启动垃圾分类回收来获取空剩余资源。垃圾分类收集对SSD的性能危害很大。所以如果业务进程能够主动释放空多余的资源，那么SSD内部的分类垃圾收集就会容易很多，从而提高SSD自身的性能。TRIM *** 作是允许网络层主动释放空多余资源的系统。

当系统软件立即在SSD构建时，它可以根据pushTRIM指令轻松地从SSD获取资源。然而，在系统软件和SSD之间引入RAID之后，情况发生了巨大的变化。首先，让我们了解一个通用的RAID数据合理布局，它看起来会非常整洁:

在这种合理的数据布局中，每个条带都有一个数据校验块(RAID5)。一旦一个条带中的一个数据块出现了常见故障，就可以根据校验数据p对该常见故障数据进行修复，此时假设位于RAID之上的一个系统文件要修剪一个数据块，这个数据块正好落在SSD1的D数据块区域。对于这种 *** 作，RAID必须做什么？一个很直观的 *** 作是，RAID整理完SSD1上的D数据块后，需要升级这个条带中的P数据块。原因是经过TRIM *** 作后，SSD1上的D数据块发生了变化。如果要保证条带数据的一致性，就必须升级P数据块。条带中数据块的修剪 *** 作导致条带检查数据的升级。这是条带RAID中TRIM *** 作的关键成本。

事实上，客观事实远不如丝带升级。整理SSD中的数据块后，整理数据块中的数据可能变得不确定。例如，在数据块被修整后，加载的数据很可能与原始数据相同，也很可能为零。而且随着时间的变化，修整后的数据也会发生变化。这完全在于SSD内部夹具程序流程的完成。这种数据的可变性给RAID带来致命的数据准确性问题。例如，在示例中，在SSD1的D数据块被修整后，P校验数据根据修整后的数据被更新。一段时间后，SSD1的D数据块可能会发生变化。此时各条数据可能会不一致，会危及数据的准确性。

从分析来看，最好以条带为企业进行RAID数据整理。当条带中的所有数据都可以被修整时，修整 *** 作指令可以被推送到SSD。因此，在RAID中，TRIM *** 作被放大到条带级，而不是原来的扇区块级 *** 作。

但是一般RAID机器设备对客户的暴露仍然是扇区级块机器设备的目标，系统文件仍然会把扇区级TRIM *** 作推给RAID。针对这种情况，RAID如何将扇区级修剪 *** 作转化为条带级修剪？所以需要在RAID中进行TRIM的组合，比如按照位图系统写下TRIM *** 作，组合到一定程度后再对整条带进行TRIM *** 作。这种设计方案可能会导致完成的复杂度很大，同时也有很多必须考虑的问题，比如位图占用内存空、异常掉电等等。所以，用一款优秀的RAID数据维护手机软件来解决TRIM问题，并不是一件很容易的事情。

(摘自存储老胡的博客——存储之道)