推 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架構角度切入
兩個基本上不是很對頭的東西
大概就這樣