(3) ファームウェア1819におけるウェアレベリングの性能

今まで、Indilinx社製Barefootコントローラを搭載したSSDを使っていると、特に異常な操作をした訳でもないのにMaximum Erase Countが非常に大きな値となる現象が発生していました。
結論から言うと、どうやらこの現象はファームウェアのバグに起因するものであったようで、バージョン1819(Vertex 1.4/1.41, Agility 1.3/1.31)では修正されました。以下では、その問題について、Solidata製のK5-64を用いた検証の結果について記します。

ファームウェア1819のリリースノートには、このような一文があります。

  • Bug fix: Performance boost routine reused the recently used block and it did harm to wear leveling.

あからさまに怪しいです。すぐにこの問題の検証をしたかったのですが、こちらの手持ちのVertexはすでにMaximum Erase Countが3300を超えており、この値が更新されるまで書き込みのテストを行うのは気が引けます。しかし、前回の記事に書いたとおり、MP Toolを用いてファームウェアをアップデートすると、SMARTの値を含むSSD上の全てのデータがリセットされます。そこで、K5-64をMP Toolでアップデートし、Average/Maximum Erase Countがほとんど0に近い状態で検証を行いました。
検証内容は、LBA上の同じアドレスにデータを書き込み続け、その時のAverage/Maximum Erase CountをSMARTから取得するというものです。スタティックウェアレベリングのアルゴリズムが悪いと、このテストによってMaximum Erase Countだけが増え続けてしまいます。
以下に、ファームウェア1571の時のテストを再掲します。縦軸にMaximum Erase Count、横軸に書き込み回数を取ったグラフが以下です。

テスト内容を若干変更して4回計測しましたが、いずれも8500〜9000回の書き込みでMaximum Erase Countが600を超えています。
これと同じテストをファームウェア1819において実行しました。スタート時のMaximum Erase Countは33,Average Erase Countは19でした。
…Maximum Erase Countは全然上昇しません。2871回目の書き込みで先にAverage Erase Countが20になり、その後、10220回目の書き込みでようやくMaximum Erase Countが34になりました。これではグラフを作るまでもありません。
というわけで、この問題はバグに起因しており、ファームウェア1819で修正されたと考えるのが妥当です。もしかすると、Barefoot搭載SSDの故障が多い(気がする)のも、この問題が原因かもしれません。というわけで、未だに1571以前のファームウェアをお使いの方は、できる限り早急に1819にアップデートすることをおすすめします。
なお、以下が現在のJSMonitorの結果です。

Maximum PE Count Specificationが10,000だったのも、ちゃんと100,000に直っていました。