ingram14
原博客地址:https://blog.csdn.net/wangpeng22

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

posted on 2020-11-19 20:08  ingram14  阅读(456)  评论(0编辑  收藏  举报