JMF602搭載SSDのプチフリのメカニズムについて(2)
以下の内容は、ある程度推測を含みますが、現象を矛盾なく説明できているかと思います。ただし、筆者はSSDに関して全く専門ではありません。もし間違いがあれば、ぜひご指摘をいただきたいと思います。
最初に結論を書いてしまいます。
- JMF602は数ブロックを1管理単位にまとめてウェアレベリングを行っている。SHD-NSUM30(MLC,30GB,SATA)の場合、1管理単位＝4ブロック(4MB×4＝16MB)。
- JMF602は空きブロックのうちの一部をシステムデータとして用いている。SHD-NSUM30の場合、システムデータの大きさは76管理単位(76×16＝1,216MB)。
- 小さな書き込みが起こると、JMF602は変更された部分のみをシステムデータ内のブロックに書き込む。ブロックコピーはアイドル時に行われる*1。
- 書き込みが連続して行われ、システムデータが使い切られたとき、JMF602はブロックコピー・ガベージコレクションを行い、システムデータに空きを作る。これに必要な時間は、SHD-NSUM30の場合700msまたは900msかかる。しかし、ワーストケースの場合、これだけの時間をかけても2管理領域しか開放されない。
検証には、CrystalDiskMarkのソースを流用し、読み書き一回ごとのレスポンスタイムをファイルに保存するプログラムを作成しました。乱数生成アルゴリズムやファイルの作成部分はそのままで、大きなファイルを扱えるようにアドレスを64bitに直し、時間計測をtimeGetTime()からパフォーマンスカウンタに変更しています。
以下はその検証の過程です。
まず、4KBのランダムライトについて、ファイルサイズを変更したときの影響について見てみます。結果の描画はGnuplotを用いています。遅いときと早いときの差があまりに大きいので、グラフの縦軸は対数にしています。ファイルの大きさは500MB，1000MB,2000MB,4000MBの4種類です*2。
2000MB,4000MBのときだけ、異常にレスポンスが悪い現象(以下面倒なのでこれをプチフリ現象と呼びます)が観測されています。そのときの時間はおよそ700msまたは900msであり、HD Tuneの結果と一致しています。グラフは300回までしか表示していませんが、500MB,1000MBでは5000回ぐらい書き込みをしてもこの現象は観測できませんでした。
以前の記事で紹介したDailyTechによるJMicron社に対するインタビューでは、システムデータが一杯に近く、それでもホストPCがデータの書き込みを続けた時にプチフリ現象が発生するということでした。ということは、上記の500MB,1000MBのテストではシステムデータを使い切っていないということが分かります。
ここで、システムデータの働き方を、図を用いて解説します。
この図は、5回の1KBランダムライトが行われた状況を示します。なお、各数字は、何番目の書き込みかを表し、システムデータは空きブロックすべてであるとします。
まず、最初の書き込みが行われると、空きブロック中最も消去回数の少ないBlock5に対し、変更部分のみの書き込みが行われます。2番目と3番目の書き込みは同一ブロック内に対する書き込みなので、両方とも2番目に消去回数の少ないBlock2に書き込まれます。次に、4番目の書き込みが最後の空きブロックであるBlock6に対して行われます。問題は5番目で、もう書き込めるブロックがありません。仕方ないので、Block1から5へブロックコピーを行い、ブロック1を消去して空きブロックとします。そして、消去したばかりのBlock1に5番目の書き込みを行います。
このとき留意するべきなのは、1番目から4番目の書き込みはブロックコピーを伴わないので高速ですが、5番目の書き込みはブロックコピー後に始めて行われるので、低速になってしまうという点です。
ただし、4番目の書き込みと5番目の書き込みの間に時間があり、ストレージがアイドル状態になっていれば、その間にブロックコピーを済ませることができます。そうすれば5番目の書き込みも高速に行うことができます。
さて、ここで実際のデータに戻るわけですが、この結果はプチフリ現象が発生するまでの時間が早すぎます。1000MBの予備領域を確保するには、4MBのブロックが250個必要です。しかし、4000MBのテストでは、100回程度でプチフリ現象が発生しています。ということは、このシステムデータはブロック単位ではなく、もっと大きな単位で管理されていると考えられます。
そこで、完全にランダムなアドレスにデータを書き込むのではなく、あるサイズごとにアドレスをジャンプさせていき、レスポンス時間を計測しました。
これらの図はこの書き込みパターンを図示したものです。ジャンプ単位が管理単位より小さければプチフリ発生までに時間がかかります。ジャンプ単位を大きくしていくとプチフリ発生までの時間が短くなっていきますが、ジャンプ単位が管理単位を越えた場合、単にいくつかの管理単位が飛び越えられるだけなので、プチフリ発生までの時間は変わらないはずです。
すなわち、ジャンプするアドレスを大きくしても最初のプチフリ現象までの回数が変わらなくなる場所を探せばいいということです。
結果は、以下の表のとおりです。
| ジャンプ距離 | 8MB | 10MB | 12MB | 14MB | 16MB | 18MB | |||||||
| 初プチフリ[回] | 152 | 122 | 102 | 88 | 77 | 77 | |||||||
| 初プチフリまでの総ジャンプ距離[MB] | 1216 | 1220 | 1224 | 1232 | 1232 | 1386 |
結果から、管理単位は16MB、すなわち4ブロックであり、JMF602は4ブロックを1単位として管理を行っていると考えられます。
いくつかの傍証からも、この結果は妥当です。まずこの記事では、1回のエラー訂正ごとに4個のブロックが減少しています。また、今まで寄せられたJSMonitorの報告では、Good/System Block Countの数はすべて4の倍数になっています。
また、初プチフリが観測されるまでの回数と1回のジャンプ距離の積が表の3行目ですが、管理単位以下の結果ではほぼ一定の約1.2GBとなっています。これがシステムデータの大きさであると考えられます。これで、500MB,1000MBのランダムライトテストでプチフリ現象が見られなかったのは、ファイルサイズがシステムデータサイズを下回っていたためであることが確認できました。
次に、この図を見てください。
上記のテストのうち、16MBジャンプのときの書き込み時間をGnuplotでグラフにしたものです。1回遅くて2回早いという非常に規則的な結果が得られています。これは、1回のプチフリ現象でわずか2管理単位しか空き領域にならないことを示しています。これでは、平均しても200ms以上のレスポンス時間になってしまいます。
またも長くなってしまったので、続きは次回です。
