[請益] SSD寫入方式與壽命問題

看板Storage_Zone作者 (號暱稱)時間6年前 (2017/08/11 16:03), 編輯推噓11(11推 0噓 42→)
留言53則, 10人參與, 最新討論串1/1
好一陣子沒有注意SSD的發展了 最近考慮購置才驚覺產品大都是以TLC為主 想當初我買MLC還覺得怕怕的 現在QLC的時代都快要來了XD 當然我看了各種說法 都會用計算的方式告訴你其實正常用度下用到過保是沒問題 只不過我還是覺得其計算方式有些地方我還是有疑問 例如我以TLC舉例 通常網路會假設一顆120G的SSD 如果可以寫入1000(實際上是500-1000可他都用1000算)次 那壽命就是120G*1000 的總量 然後就舉例一天寫60G 可以用2000天大約是6年 可是這裡面似乎還是有疑慮 比方說 SSD控制晶片有聰明到能夠跨槽去平均嘛?? 如果不行 那麼假如你把SSD分為兩槽60G 那麼壽命不就剩一半? 又比如 長期占用的檔案晶片也能夠挪移嘛?? 假如不會 那麼C槽60G假如有30G是系統 那麼空間就只剩30G了 壽命又要折一半 另外就是 即是控制晶片真的是全面的聰明平均抹寫 SLC的抹寫次數是MLC的10倍以上 價格根本不到10倍 MLC的次數也是TLC的7-10倍 價格TLC也沒有便宜那麼多啊 這麼說來 與其我一直用大容量去衝高使用壽命 反而不如買一顆小小的SLC 他的C/P值反而好不是嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.250.44.207 ※ 文章網址: https://www.ptt.cc/bbs/Storage_Zone/M.1502438589.A.DDC.html
→
08/11 16:14, , 1F
MLC寫入壽命根本就不是TLC的7-10倍
08/11 16:14, 1F
→
08/11 16:15, , 2F
Wear Leveling運作在更底層,基本不會被分割所影響
08/11 16:15, 2F
→
08/11 16:16, , 3F
大廠TLC產品起碼都1500 P/E起跳,目前看測試還有逼近
08/11 16:16, 3F
→
08/11 16:16, , 4F
3000 P/E的
08/11 16:16, 4F
→
08/11 16:17, , 5F
MLC的話家用級就3000 P/E,少數舊產品才5000
08/11 16:17, 5F
→
08/11 16:17, , 6F
要再上去如10K就要到eMLC的企業級產品
08/11 16:17, 6F
→
08/11 16:20, , 7F
(真的爛的除外,如Micron 16nm 2D TLC)
08/11 16:20, 7F
推
08/11 19:33, , 8F
MLC實測記得也很多都高於3000一大截
08/11 19:33, 8F
→
08/11 19:33, , 9F
廠商抓低標標示而已
08/11 19:33, 9F
→
08/11 19:40, , 10F
弄個RAM disk，起碼把瀏覽器暫存目錄指向RAM disk
08/11 19:40, 10F
→
08/11 19:40, , 11F
，SSD的壽命能延長一些。
08/11 19:40, 11F
推
08/11 22:47, , 12F
借問C大，如果平均讀寫在作用在最底層，那檔案表的
08/11 22:47, 12F
→
08/11 22:47, , 13F
部份，也會被平均讀寫機制"照顧"到嗎？
08/11 22:47, 13F
推
08/11 22:55, , 14F
除非真心想研究其中的技術 不然一般使用者根本不用
08/11 22:55, 14F
→
08/11 22:56, , 15F
管平均讀寫什麼的 正常用到退休都還不一定壞
08/11 22:56, 15F
推
08/11 23:01, , 16F
會這麼問，是因為NTFS有所謂的 "時間標記"，每次檔
08/11 23:01, 16F
→
08/11 23:01, , 17F
案變動都會更新記載。這樣BT抓檔是分各區塊寫入，理
08/11 23:01, 17F
→
08/11 23:01, , 18F
論上，完成一個檔案時，雖然所屬各別cell頂多就寫入
08/11 23:01, 18F
→
08/11 23:01, , 19F
一兩次。但"時間標記"卻會變動很多次。會寫壞cell
08/11 23:01, 19F
→
08/11 23:01, , 20F
嗎？ 還是我多慮了？用FAT32是不是就沒這問題了？
08/11 23:01, 20F
推
08/11 23:16, , 21F
這我就不知道了,值得討論
08/11 23:16, 21F
→
08/12 00:11, , 22F
一般來說，"時間標記"對SSD來說，也是user data的
08/12 00:11, 22F
→
08/12 00:12, , 23F
一部分，照搬不誤。
08/12 00:12, 23F
推
08/12 00:29, , 24F
謝謝解答。
08/12 00:29, 24F
→
08/12 02:09, , 25F
好的FW對於FTL也會做Wear Leveling
08/12 02:09, 25F
→
08/12 12:36, , 26F
Wear-leveling本來就針對FTL做吧 是好的連GC也會做
08/12 12:36, 26F
→
08/13 17:24, , 27F
因為沒有研究時間標記的寫入量，但是 估計也是KB級
08/13 17:24, 27F
→
08/13 17:24, , 28F
的，以目前主流的4K-mapping慘一點時間標記給你佔
08/13 17:24, 28F
→
08/13 17:24, , 29F
掉一個page也才16K，所以請不需要擔心
08/13 17:24, 29F
→
08/13 17:28, , 30F
目前QLC看起來用SLC Cache比較簡單，所以對QLC的寫
08/13 17:28, 30F
→
08/13 17:28, , 31F
入量也不需太擔心，不過真的又麻煩又慢
08/13 17:28, 31F
推
08/13 17:54, , 32F
主要是我的BT軟體很兩光，印象中沒看到buffer這個
08/13 17:54, 32F
→
08/13 17:54, , 33F
選項，所以，若是下載很慢，每4K就對該檔案寫一次，
08/13 17:54, 33F
→
08/13 17:54, , 34F
這樣，1M的檔案會分256次寫入，1G檔案會分4096次寫
08/13 17:54, 34F
→
08/13 17:54, , 35F
入，時間標記(甚至其他屬性)就會變動並寫入4096次。
08/13 17:54, 35F
→
08/13 17:54, , 36F
我不清楚NTFS資料結構是不是將時間標記寫在某個固定
08/13 17:54, 36F
→
08/13 17:54, , 37F
地方，例如$MFT或檔頭;也不知道SSD平均耗損機制會
08/13 17:54, 37F
→
08/13 17:54, , 38F
不會處理這個。所以才有此疑問。
08/13 17:54, 38F
推
08/13 17:55, , 39F
時間標記要是寫在檔尾就沒這問題。
08/13 17:55, 39F
推
08/13 18:02, , 40F
最主要，我真的用SLC的SSD來下BT, 一直平安。將來免
08/13 18:02, 40F
→
08/13 18:02, , 41F
不了換成QLC, 不知道還能不能這樣惡搞。若定點寫入
08/13 18:02, 41F
→
08/13 18:02, , 42F
損壞了，雖然有保固，但來回寄送還是麻煩。不如換軟
08/13 18:02, 42F
→
08/13 18:02, , 43F
體先。
08/13 18:02, 43F
→
08/13 18:05, , 44F
每家FTL設計不同，很難完全確定；但是分次寫入不會
08/13 18:05, 44F
→
08/13 18:05, , 45F
讀出來在寫進去，所以寫入量並不會1MB變成256MB，
08/13 18:05, 45F
→
08/13 18:05, , 46F
如果一次寫4K資料+4K時間標記，也能1page完成，總
08/13 18:05, 46F
→
08/13 18:05, , 47F
而言之 不需要太擔心
08/13 18:05, 47F
推
08/13 18:44, , 48F
謝謝你，那我就放心使用了。
08/13 18:44, 48F
推
08/17 13:05, , 49F
1024K x 1024=1M 1024M x 1024=1G
08/17 13:05, 49F
→
08/17 13:05, , 50F
1024G x 1024=1T.....一般240G ssd 都會
08/17 13:05, 50F
→
08/17 13:06, , 51F
有 60T以上的壽命(TBW有的更高),沒有看到
08/17 13:06, 51F
→
08/17 13:06, , 52F
50T以上都不必跳腳,即使見到50T也不用跳腳
08/17 13:06, 52F
→
08/17 13:08, , 53F
,除非有拖慢情況才做處置(我還沒遇過)
08/17 13:08, 53F
‣ 更多 cosmo2256 的文章
文章代碼(AID): #1PZMIztS (Storage_Zone)