推 caeserhaha : 有没有人要写FTL的04/11 23:36
FTL不像host protocol或是NAND interface是一套公开的规范
所以各公司甚至同公司不同产品之间
可能架构上会有很大的不同
而且FTL早期是不传之密 XD
完整写一个FTL的架构出来很可能会被公司告泄露机密
小弟这边在不涉及架构的前提下
稍微条列式分享下之前从事相关工作 所体会到的粗浅FTL相关精神
希望可以抛砖引玉
FTL主要的工作有几个 :
1. NAND Block management.
2. GC/Wearleveling.
3. L2P/P2L Table management.
I.
先从最简单的Data flow来
Host write => 把data 放到buffer上
=> 对NAND下Write cmd将Data写进 NAND
=> 更新L2P Table
Host read => 先根据Logical address查找P2L(L2P) Table
=> 找到Physical address
=> 拿着Physical address对NAND下Read cmd
=> 将读上来的 Data 发给host
从performance的角度来讲
这中间根据不同的NAND 就有太多可以优化的地方
(比方说估Buffer usage size, Table structure design...etc.)
另外 这两个flow是最直观会影响满碟前的performance的部分
所以非常重要
II.
Block managnment
把NAND的block绑在一起管理几乎是业界公认的常识
因为绝大部分的NAND erase cmd是以block为单位
而将block绑在一起管理 在某些场景下也稍微有助于NAND command interleaving.
III.
GC & wearleaving.
同样都是搬data & update L2P Table
GC的精神在于SSD busy时 要能够及时release出empty NAND blocks供host继续写入.
而广义的Wearleaving则是着眼于延长NAND Block的寿命
(端看你要看什么Read cnt/erase cnt还是其他可以象征性评估NAND Block寿命的数值)
这两个最终想达成的精神不一样
但大家设计FW时 都想搬得越快/尽可能搬越少次 越能达成这两者精神越好
至于怎么设计就是各家公司的秘密
另外评估GC做得好不好的一个标准就是写入放大(write amplification)
IV.
L2P/P2L Table management
除了前述的GC/Wearleaving之外
其他会涉及到搬data & update L2P Table的场景
主要有两个
a. FTL等级的data error handle.
b. Abnormal power cycle后的Data recovery.
除了protect data还要保持data consistency.
(尤其当涉入host大量的erase/format cmd时 会更为复杂)
这两个东西的设计同样非常依赖NAND的规则. 细节不提
另外有一些也可能会在FTL layer处理的工作, 但比较偏SOC的部分
1. Data protection (包括E2E过程中Buffer的各种ECC 保护)
2. Thermal Throttling(温控)
3. Power control.
至于NAND cmd的优化 要不要放在FTL这层
要端看FW架构设计
以我的认知 基本上放一起的是越来越少
因为从Table management的角度来看 Logical address是连续的
但是NAND cmd排程的优化 则是要从NAND的physical架构角度切入
两个基本上不是很对头的东西
大概就这样