SSD TRIM

     TRIM 作为消费级SSD的救世神药，也是性能起飞的催化剂，下面简单介绍TRIM的前世今生。

一. TRIM相关背景/TRIM需要解决的问题

    TRIM由文件系统发起，就拿FAT32文件系统举例， 一个文件包括两个部分file（文件指针）和file data（文件数据）。

文件创建后如图1：在FAT区保存文件的指针（512B数据），文件数据可能分几个段（如file data1 和 file data2）

图1：

如图2:  当要删除文件时，文件系统重新写入文件指针（深色的file），新的文件指针不在指向老的file data。

 

图2：

如图3:  新的文件指针和没有任何联系， 老数据因而成为垃圾数据。

图3：

   由于SSD不感知host文件删除， 仍然以为这些数据是有效数据。 在做GC时会带来很多写放大。由此TRIM 应运而生。

2. TRIM需要做什么？

1）： 清除无效的LBA映射表。

   直接更新L2P table, clear trim LBA map。

2）：重新计算Block有效数据个数。

  通过L2P table查找到对应的BLK 号， 更新对于BLK的valid cnt。

3. TRIM远没有想象的那么简单

1）TRIM LBA不对齐处理：

    HOST 大多数据以sector（512B）访问， 但SSD内部往往以4KB~16KB 对齐。 那么如果这种不对齐的TRIM 命令如何处理呢？

   如图比如SSD 内部以4K mapping， 那么LBA 6~7为一个单元， LBA8~15为另外一个单元。 LBA8~15可以直接修改L2P清楚映射关系就行， 但LBA 6~7不是一个映射单元， 如果需要trim显然需要做一次read modify write，但这个对于大容量SSD 是不现实的。

   其实Spec 有规定可以不知道TRIM后数据为全0， 所以实际做法可以是不修改LBA6~7的映射关系。

2）TRIM 给GC 带来什么？

   TRIM对于GC如图插上翅膀， 尝试想一想GC面对一堆堆的无用数据需要搬移， 那么现在告诉你只需要搬这几个就行，是不是快乐多了，如图：

3）TRIM和SPOR的逆缘

  有了TRIM， TRIM过后的数据发生SPOR应该尽量保证no mapping

   试想一下这个场景：  Host 写 LBA0， 然后TRIM LBA 0~100， 再写LBA 0， 异常掉电，再上电，读LBA 0，host得到的数据是?

(L2P 不会一直dump)

假设：

如果读到数据是第一写的：证明TRIM完成后摄影关系并没有flush到nand。这样就是读到老数据，显然会verify不过。

如果读到数据是全0：证明读到的是trim后的数据， 如果最后一次后刚完成，就发生异常掉电，这是可能的。

如果读到数据是最后一次写的： 证明异常掉电前数据是写入的flash， 这也是合理。

          为了避免第一种情况发生，这里可以引进一种机制-> TRIM BITMAP， 每个BIT表示一个映射关系是否还在（比如4K mapping， 一个4K用1给bit 表示）。

TRIM BITMAP设计的初衷是因为L2P table 太大，不可能一直刷新，但trim之后的数据要在即使发生SPOR后也要尽量保证为no mapping，所以在TRIM时尽量在更新L2P同时去写入TRIM BITMAP到NAND， TRIM 命令的完成要保证TRIM BITMAP已经写入NAND。

            在SPOR起来之后做replay可以参看TRIM BITMAP信息来确定是否需要恢复相关映射关系。

 

THE END