悶! 來分析SSD Freeze的成因

longyeekimo wrote:
我特別查了一下S59...(恕刪)

我對S599做IOMETER測試的時候,因為IOMETER會把磁區填滿所以一測就是衰退過的速度@@

可是不用iometer就不知道用啥了
當時對SSD瞭解太太少很可惜,這測試很多不足
http://www.mobile01.com/topicdetail.php?f=490&t=1671567&p=2
thx wrote:
比較有名的軍規SSD...(恕刪)


我仔細的看了一下你寫的那篇文章.
還不錯.

但有幾個小地方建議換個名詞比較貼近於業界常用的.

Channel: 一般我們不叫顆粒. 而叫通道數. 顆粒通常指實體系統上擺了多少的Flash memory
所以顆粒的定義應為 Channel x bank .
顆粒有時會叫device 但容易跟整台SSD混淆,所以很少人這樣講了

1 Pages= 4096 KBytes的User Data 數據塊 加上 128 Bytes的Spare Data所構成的 管理塊==>有點筆誤. 是byte

引用的論文我就沒仔細看了.我不是指導教授.

雖然說SSD滿了所以IO之類的速度慢了
但是把檔案清掉 TRIM 速度就應該回來?
但是 Sandforce 似乎有這個瑕疵?
是因為TRIM的驅動的關係嗎?
longyeekimo wrote:
wear leveling的定義是將block erase count 平均化.並不是清除data喔. 也沒wear leveling table,一般稱Erase count. Erase count是指Block被erase的次數.)



頭昏了 是清空Mapping Table Data 思路才對, 嚴格說
應該是清空Service Area +損壞區塊(Bad Block, or Worn-Out Block)


Mapping Table 功用是
NAND Flash Memory的同1個page不能做重覆寫入的行為。再者,在寫入1個sector資料之前,必須要有抹除1個Block的資料才能做寫入的動作,但抹除 1個Block的動作需要耗費相當多的時間,此舉造成了NAND Flash效能下降的最大原因。為了改善效能,最有效的方法就是減少Erase的次數,因此有了Mapping Table

具體技術細節 還是請各位去看OSSLab Link
http://www.osslab.org.tw/Storage/Flash/Flash



簡單講的話 , 對SSD 而言,一般ATAProtocol 只能訪問上圖 Data 區, 只有ATA Security 指令
會讓控制器對紅框Spare Area 清空.

圖上的 Spare Area 稱為Service Area 會好一點

因為在真正現行產品中   Sevice Area 包含 1.Spare data 2.Mapping Table 3.ECC



我們團隊雖然在儲存業界都有一點經歷 ,但是對Nand Flash 其實沒啥經驗
Lab 是這樣硬幹的

1. 寫入特定Data 好分析用
2.一顆顆用熱風槍吹下在SSD上的Flash ..><
3.拿下圖設備一顆顆讀取Nand Flash ,再做"好奇寶寶"研究...

Opensources,虛擬化,Voip,FC ,Storage ,Embedded system http://www.osslab.org.tw
thx wrote:
NAND Flash Memory的同1個page不能做重覆寫入的行為。再者,在寫入1個sector資料之前,必須要有抹除1個Block的資料才能做寫入的動作,但抹除 1個Block的動作需要耗費相當多的時間,此舉造成了NAND Flash效能下降的最大原因。為了改善效能,最有效的方法就是減少Erase的次數,因此有了Mapping Table


我不方便講明白. 但這句觀念有錯. 你可以再想想. 其實答案在一開始的分析裡.
方法是把128 或256 page的program time和Erase time計算一下. 你會發現一個相反的事實.

Mapping table是這樣來的沒錯.但原因不完全在減少Erase的次數.減少Erase次數只是附加效果.
那省了什麼? 答案就在一開始的分析裡.

看你們是開發軟體的,所以Firmware行為其實也不用掌控到很精細.
且,各家演算法大不相同. 所以software只要合乎大原則應該就有效果了.
不然就真的要針對firmware做出相對應的AP了.
weikichen wrote:
雖然說SSD滿了所以...(恕刪)


就我猜測
SF trim support不完整的原因來自於壓縮.

longyeekimo wrote:
最近覺得很悶.
因為hardware不配合, 我的SSD的研發案停了...(恕刪)


所以慧榮的SSD 停掉了喔!可惜可惜!
請恕小弟插花一下..

longyeekimo wrote:
我不方便講明白. 但這句觀念有錯. 你可以再想想. 其實答案在一開始的分析裡.
方法是把128 或256 page的program time和Erase time計算一下. 你會發現一個相反的事實.


不知道您要說的是不是拖累 randon 的時間是 program time 而不是 erase..

longyeekimo wrote:
Mapping table是這樣來的沒錯.但原因不完全在減少Erase的次數.減少Erase次數只是附加效果.
那省了什麼? 答案就在一開始的分析裡.

省了..program 的次數?

不知道我有沒有猜錯?
pcking wrote:

不知道您要說的是不是拖累 randon 的時間是 program time 而不是 erase..

longyeekimo wrote:
Mapping table是這樣來的沒錯.但原因不完全在減少Erase的次數.減少Erase次數只是附加效果.
那省了什麼? 答案就在一開始的分析裡.

省了..program 的次數?

不知道我有沒有猜錯?


1 個 block program time 其實跟 erase time 差不多
效能低落的主要原因是因為 program 分布在不同 block
在找不到可以寫的 block 情況下做 garbage collection
回收用不到的 block, erase 他 然後複製資料 寫入資料
所以效能低落是因為 random 寫入造成需要搬移的以及erase write都增加
尤其4k寫入更明顯
明明只寫4k 卻可能要花和寫 1 block 的時間一樣多

另外 Mapping table 主要是為了 wear leveling 才對

應該是這樣吧~?



漫步蔚藍晴空下 wrote:
1 個 block ...(恕刪)


睡了一晚,多好多內容.有人幫忙解釋的.我就不額外說明了.

對額外時間的解釋,您已經幫我解釋到了. 不過要幫你更正一卜, 1 page program time 和erase time接近才對.
1個block的program time是erase time 的百倍以上

的確是複製的時間. 我個人是稱為copy page. 所以有研究flash memory的話,flash裡有加速copy的command也是為了這點.
這個動作在algorithm佔用時間的比例超高. 即使使用了Mapping table也是如此.
如果讓Physic block address等於Logic block address的話(也就是固定關係), 那所有速度至少要除2以上.

但Mapping table存在的理由非只為這項.
第一個原因是bad block. 要避開memory中的bad block. 所以光這點就構成使用mapping table的理由.
再者是剛剛說的copy 問題. Wearleveling也算一項.還很多理由,一言難盡.

換言之,mapping table是所有flash algorithm的基底.非為任何一個獨立的演算法而存在.
反而應該說,很多演算法都根據mapping table的原則而設計.

關閉廣告
文章分享
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 12)

今日熱門文章 網友點擊推薦!