(1) JMF602とBarefootのスタティックウェアレベリングの性能比較

SSD Barefootコントローラのウェアレベリングの実効性について

TranscendからIndilinxコントローラ搭載のSSDが発売されるようなのですが、そのデータシートがアップされており、そこにSMARTの仕様も記述されていました。Vertexシリーズの最新Firmware(v1.3)で追加されたD2,D3エントリの情報はないものの、それ以外の全ての仕様が明らかになっています。

01(001) Raw Read Error Rate
09(009) Power on Hours
0C(012) Device Power Cycle Count
B8(184) Initial Bad Block Count
C3(195) Program Failure Block Count
C4(196) Erase Failure Block Count
C5(197) Read Failure Block Count
C6(198) Total Count of Read Sectors
C7(199) Total Count of Write Sectors
C8(200) Total Count of Read Commands
C9(201) Total Count of Write Commands
CA(202) Total Count of Error bits from flash
CB(203) Total Count of Read Sectors with Correctable Bit Errors
CC(204) Bad Block Full Flag
CD(205) Maximum PE Count Specification
CE(206) Minimum Erase Count
CF(207) Maximum Erase Count
D0(208) Average Erase Count

なお、これらの値の数値表現は伝統的なSMARTの仕様には従っていないため、一般的なSMARTモニタリングソフトでは正しい値は表示されません。正しい値の計算方法は以下の通りです。

  • CrystalDiskInfo 2,7.4, Speedfan など
    • [現在値(Current)]+[最悪値(Worst)]x256+[生の値(raw)の1byte目]x256x256+[生の値(raw)の2byte目]x256x256x256+....
  • HD Tune Pro 3.5
    • [Current]+[Worst]x256+[Data]x256x256

CrystalDiskInfo 2.7,4やSpeedfanは、生データを16進数で表示しているので、一度10進数に直して計算する必要があります。また、CrystalDiskInfo 3.0 Alpha 3では、Indilinxコントローラ搭載のSSDを自動識別し、データを全て生の値(16進数)として表示してくれます。

さて、仕様が分かったのは良いことなのですが、これらのSSDはウェアレベリングのアルゴリズムに問題があるのではないかという気がしています。
CrystalDiskinfo 3.0 Alphaの開発版のサポートスレッドには、Indilinxコントローラ搭載SSD(Vertex, S592など)の情報がいくつか寄せられていますが、Average Erase CountとMaximum, Minimumとの差が非常に大きい方が何人もいらっしゃいます。すでにMaximum Erase CountがMLCの書き換え寿命と言われる1万回を越えてしまっている方もいるようです。
そこで、手持ちのVertex(30GB)を用いて、ウェアレベリングの実効性を調べるテストをしてみました。
テスト内容は簡単で、Iometerを用いて非常に小さいファイル(今回は何となく2MB)にシーケンシャルライトを一定時間繰り返すものです。このテストでは、LBAの狭い範囲内のみ書き換えが発生するため、スタティックウェアレベリングが正しく動作しない場合、AverageとMaximumの値が離れてしまうことが予想されます。
結果は以下の通りです。

Average Maximum Minimum
実験前 365 1241 14
10分後 366 1718 14
20分後 368 2941 14

Maximumの値は容赦なく増えていっています。スタティックウェアレベリングが動作しているとは考えられません。AverageとMaximumの差がより大きくなればスタティックウェアレベリングが働き始めるのかも知れませんが、前述の通り、すでにMaximumの値が10.000を越えている方もおり、その実効性には疑問符をつけざるを得ません。
また、比較実験として、JMF602を採用しているBuffaloのSHD-NSUM30で同様の実験を行ってみました。

Average Maximum
実験前 174 412
10分後 175 431
20分後 177 436

AverageとMaximumの差は若干しか開いていません。これなら、スタティックウェアレベリングが正しく動作していると言えるでしょう。JMF602は、AverageとMaximumの差が一定値*1より離れないようにスタティックウェアレベリングを行っているようです。この結果を見る限り、Indilinxコントローラのウェアレベリングアルゴリズムの性能は明らかにJMF602に劣っています。

この現象は、もしかすると寿命の定義が間違っていることを起因にしているかもしれません。
以前の記事に、ID=D1の値が残り寿命をパーセンテージで表した数値だと書きましたが、この値はID=CDの"Maximum PE Count Specification"という値とAverage Erase Countを用いて以下のように計算しているようです。

    • D1 = (1-[Average Erase Count]/[Maximum PE Count Specification])x100*2

すなわち、Maximum PE Count Specificationが10,000の場合、Average Erase Countが100増えるごとにD1が1減り、100,000の場合はAverage Erase Countが1000増えるごとにD1が1減ります。
そして、なぜか前述のスレッドによせられた報告では、全てのMLC製品のMaximum PE Count Specificationの値が100,000(Current=160,Worst=134,Raw 1Byte目=1)となっており、逆に、SLCを採用しているK5-64では、Maximum PE Count Specificationの値が10,000（Current=16, Worst=39, Raw 1Byte目=0) となっています。
もし、書き換え耐性が100,000回と言われるSLCを採用した製品であれば、10,000回を越える書き換えはあまり問題になりません。もしかすると、VertexをはじめとするMLCのシリーズでは、SLCを前提としたウェアレベリングアルゴリズムが動作してしまっているのかもしれません。この場合、SSD全体の寿命にほど遠い段階で一部のセルが壊れ始めてしまうことが予想されます。

というわけで、Vertex, UltraDrive ME, S592など、Indilinxコントローラを採用したSSDをお持ちの方は、CF(Maximum Erase Count)とD0(Average Erase Count)を調べてみてください。
…と言っても、この問題に関してユーザ側ができることはほとんどありません。正直に言って、本エントリの内容は何かの勘違いであって欲しいです。

*1:製品によって異なるようですが、おおむね256のようです

*2:小数点以下切上げ