(2) wiperの効果を検証
かなり時間が経ってしまいましたが、色々と実験してみた結果を掲載したいと思います。やはり、IndilinxコントローラのMaximum Erase Countの上昇の仕方は異常で、ウェアレベリングのアルゴリズムに問題があるのではないかという印象です。
以下はその実験内容です。
まず、前回の記事の続きで、Solidata製のK5-64(SLC,64GB)に対し、Maximum Erase Countの上昇がいつ止まるかを試してみることにしました。
テストに使用したのはIometerで、テストファイルサイズを4MBに設定し、そこに延々とシーケンシャルライトを繰り返すようにしてみました。このテストでは、論理アドレス上の非常に狭い範囲にのみ書き込みを行うため、ウェアレベリングの性能が低い場合、ごく少数のブロックの書き換え回数のみが増えてしまいます。そのため、Maximum Erase CountとAverage Erase Countの差が広がっていくことが予想されます。
テストを開始してから1時間程度放置してみたところ、Average Erase Countは13しかないにも関わらず、Maximum Erase Countはなんと12,941に達していました。
前回の記事で解説したように、D1の残り寿命のパーセンテージは、CDのMaximum PE Count Specification(書き換え限界回数)とAverage Erase Countから計算されます。K5-64のCDの値は10,000に設定されています。すなわち、Average Erase Countが10,000になるときを寿命としているにもかかわらず、あっという間にMaximum Erase Countが10,000を越えてしまいました。事前の予想では、どこかのタイミングで予備ブロックが全て入れ替わり、Maximum Erase Countが伸びなくなるだろうと予測していたのですが、どうやらそうではないようです。
ここでいったん仕切り直しをすることにしました。JSMonitorの次回のバージョンはIndilinxにも対応させる予定なのですが、そのSMART情報の読み込み部分だけを先に作成しました。それを用い、一回シーケンシャルライトを行うごとにSMART情報を取得、ログファイルに保存するプログラムを作成しました。Iometerでのテストと同様、テストファイルのサイズは4MBです。同じ所にデータを書き込むために、毎回ファイルポインタを先頭に戻してから4MBのデータを書き込んでいます。
なお、テストごとにMP Toolを使って全てのSMART情報を消去しています。K5-64はSLCタイプなので多少無理をしても(多分)問題ありません。MLCのVertexではとてもやる気にならないテストですね…
また、パーティションはNTFS、クイックフォーマットで作成しています。パーティションアラインメントはデフォルトのまま(63KB)です。
テスト内容は、以下の4種類です。
- Maximum Erase Countが600になるまで書き込み続ける(下図赤線)
- Maximum Erase Countが300になるまで書き込み続け、30分放置した後テストを再開、600になるまで書き込み続ける(下図緑線)
- フォーマット直後にWiperを実行し、Maximum Erase Countが600になるまで書き込み続ける(下図青線)
- Maximum Erase Countが300になるまで書き込み続け、Wiper実行後にテストを再開、600になるまで書き込み続ける(下図ピンク色の線)
2番目のテストは、アイドル時にスタティックウェアレベリングが行われるかどうかのチェックです。
各テストについて、縦軸にMaximum Erase Count、横軸に書き込み回数を取ったグラフが以下です。
どのテストも、600回に到達するまでの書き込み回数はおよそ8500回程度で、テスト方法による差異は大きくありませんでした。また、どのグラフも、まったくMaximum Erase Countが上昇しないフェーズと、ほぼ一定の割合(書き込み8回あたりMaximum Erase Count1回)で上昇するフェーズが交互に発生しています。
テスト2の結果から、アイドル時にはスタティックウェアレベリングは行われないようです。テスト4では、Wiperを実行した直後はMaximum Erase Countの上昇が収まりますが、その後また上昇が始まり、最終的にほぼ追いつく形になっています。
言うまでもなく、書き込み8回あたりMaximum Erase Count1回の上昇というのは、異常に早いペースです。これが示唆するのは、わずか8個のブロック内でダイナミックウェアレベリングが行われているということです。以前の記事でも解説していますが、ダイナミックウェアレベリングは、予備ブロックのうち最も書き込み回数の少ないブロックに新しいデータを書き込むことで実現されます。そのため、スタティックウェアレベリングが起こらない限り、予備ブロック全てのErase Countは同じ値になっていきます。もし予備ブロック全てのErase CountがMaximum Erase Countと同値になってしまえば、そのうちのどれに書き込みを行ってもMaximum Erase Countが上昇してしまいます。8個のブロック内だけでダイナミックウェアレベリングを行えば、8回の書き込みごとにブロックが1巡し、Maximum Erase Countが1つ上がっていく計算になります。
腑に落ちないのは、勢いこそ鈍るものの、Maximum Erase Countの上昇が止まらないことです。時々Maximum Erase Countが増えなくなる領域があることから、スタティックウェアレベリングらしきものがあることは間違いないのですが、すぐにまたMaximum Erase Countが上昇し始めてしまいます。
どうやらもう少し詳細に問題を調べる必要がありそうです。というわけで次回に続きます。
