rabi

回復 47# Niel

多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率），那就是你的這一句：

所以ssd controller會將updated file寫入新page，不會立即rewrite(甚至完全不會rewrite)，然後update LBA，成個過程file system係不會知道。

要發生你的 best case，controller 首要條件是具備有足夠的 cache 來作你說的「新 page」，可惜，一般 SSD 的 cache 來說都只得 64MB-128MB，而 OS 的 page file 動不動都超過 1GB，加上其他的系統檔、記錄檔、瀏覽記錄檔、嘜檔物檔…，你的 bast case，發生機會是無法多的，何來証明：「rabi的論點係完全不成立的…」？

再說，上述的 best case，如果 OS 唔知的話，就會很弊，究竟 SSD 的 controller 幾時先把 cache 的內容寫入？接到硬盤關機指令時？仰或是你覺得 SSD 懂得察覺「登出」動作？好攪笑喎！Windows 登出時就會把快取寫入硬盤，包括 USB 手指，你係咪將這個和 SSD controller 的內客運作程序混淆了？

上一代的 MLC 每個 cell 的寫入次數是 10000 次，如果製程改為 25nm 就退化變成 3000 次，咁，除非唔知，否則真係傻瓜才會買咯。

Niel

回復  Niel

多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率），那就是你的這 ...
rabi 發表於 2011-2-21 08:54 PM

唔係best case，都唔係寫去cache，因為依個做法係完全不需要cache都可以做到。

將rewrite寫去其他available NAND page，而唔係overwritten the same page，依一個method係各大controller都有implement的。

Niel

回復  Niel

多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率），那就是你的這 ...
rabi 發表於 2011-2-21 08:54 PM

"多謝你的寶貴資料，但師兄你似乎太過高估 bast case 的 hit rate（發生機率）"

1. 由於同cache無關係，所以不存在hit rate問題。就算SSD係full (full user available capacity)，modern SSD controller會用spare area去handle overwrite request。

"要發生你的 best case，controller 首要條件是具備有足夠的 cache 來作你說的「新 page」，可惜，一般 SSD 的 cache 來說都只得 64MB-128MB，而 OS 的 page file 動不動都超過 1GB，加上其他的系統檔、記錄檔、瀏覽記錄檔、嘜檔物檔…，你的 bast case，發生機會是無法多的，何來証明：「rabi的論點係完全不成立的…」？"

1. 由於同cache無關係，所以同cache size/flush cache無關係。
2. Page file read:write 比例係 40:1，SSD read係無限的。由於我之前已經解釋SSD係計actual committed data 而唔係計 overwritten左幾多次。所以唔係best case。

"再說，上述的 best case，如果 OS 唔知的話，就會很弊，究竟 SSD 的 controller 幾時先把 cache 的內容寫入？接到硬盤關機指令時？仰或是你覺得 SSD 懂得察覺「登出」動作？好攪笑喎！Windows 登出時就會把快取寫入硬盤，包括 USB 手指，你係咪將這個和 SSD controller 的內客運作程序混淆了？"

Windows shutdown時，ACPI係會send command去hardware device，所以SSD係懂得察覺關機/standby等等動作。

rabi

modern SSD controller會用spare area去handle overwrite request

spare area？有幾大？大到可以 hit rate 100% 所以無「發生機率」的問題嗎？那麼這個 area 理論上要大於或等於這個 SSD 盤的容量了，老老實實喇，你作的嗎？

MLC 最怕「常滿」，就是因為當無「spare area」時，寫入資料要先 erase 才可寫入。你似乎嚴重地誤解了一些事情。

正常覆寫檔案的程序：
1. 將檔案快速寫入 spare area
2. update FAT
3. 將舊檔案 delete
4. 執行 trim 指令，將 delete 的相關 cell，全部 earse，已 erase 的 cell 就是 spare area，而你說的 block，是一群 cell 而已

spare area 不足：
被迫先執行 erase 指令，將「寫入」這個動物 delay，造成「跌速」，會很嚴重的。

所以，用 SSD 架 OS 而唔用 SLC 的，真係好打有限。

Niel

我地可以簡單估計一下25nm的SSD可以用幾耐:

以Vertex 2E 60GB 25nm為例:

Basic conversion:
60GB = 55.87935448GiB
55.87935448GiBx 3k cycle = 163.7090TiB (3k係下限，大多數係3k-5k)

OP (Over-provisioning):
V2E有13% overprovisioning
163.7090TiB x (1+13%) = 184.9912TiB

WA (Write Amplification):
Anandtech指出SF-1200 controller在real life可以有大約0.6 WA
(source: http://www.anandtech.com/show/41 ... -first-sf2500-ssd/2 )
388.5361TiB/0.6 = 308.3187TiB

當你係heavy user，一日寫20G data去OS drive:
308.3187 x 1024 / 20 = 43.249 years

我當Anandtech吹水，SandForce又講大話，所以成條數除2... = 21.6245 years...

rabi

回復 55# Niel

你知不知一文書部機，一般是 2GB RAM，只是簡簡單單的開 word、excel、IE、和 outlook，秘書小姐連續操作了四小時，系統總共「寫入」多少 data？

heavy user 一日寫入 data 是 20GB？你聽那個說的？條數究竟點計？你真的相信 page file 的 update 次數是個位數？

條數可能是咁計的：
就當 MLC 寫入次數是 3000 次，一隻 60GB 的 MLC 的寫入壽命為 60GB x 3000 = 180000GB，表示當用戶的寫入數據接近或超越這個數，這個 SSD 的 cell 理論上全部失效，如果 spare area 來來去去都是同一區，這個部份就先死，一隻 spare area 已死（或死一半）的 MLC，嚴重跌速，唔死都無用喇，強如 intel controller，空有十通道都無補於是喇…

比較一下 MLC 和 SLC 的價錢和性能，你還會說 MLC 低買嗎？

lagfix

ching可以貼個測試圖嗎?

Niel

modern SSD controller會用spare area去handle overwrite request

spare area？有幾大？大到可以 hit rate ...
rabi 發表於 2011-2-22 12:14 AM

...
為左令你明白，我地又做一個簡單計算:

又用V2E 60G做例，spare area有7.26GiB。
係話spare area可以滿，所以再不能作"正常覆寫檔案的程序"，所以其實你係講緊不停overwrite some files令7.26GiB滿左，之後controller又一直不commit TRIM command (or internal GC)，等7.26GiB用曬先做。

以OS drive來說:
1. SSD係唔會等用曬spare area先commit TRIM/ GC
2. 我當controller完全唔做野，用曬先做，不過以SF-1200為例block recycler都有70MBps。

不過你的例子係有可能發生，不過唔係一隻OS drive，而係你不停overwrite random data，不過你唔會不停寫random data去OS drive掛....