JMF602搭載SSDのプチフリのメカニズムについて(3)

システムデータの回復時間

システムデータのガベージコレクションが終了するまでの時間を測定してみました。
前回の記事までのテストは、テスト開始までに5分間の待ち時間を取っていました。今回は、その時間を短くした際にどうなるかを計測してみます。一度プチフリ現象が発生するまで16MBジャンプの書き込みを行い、表の上段の待ち時間の間は何もせず、その後もういちど16MBのジャンプ書き込みを行って、初プチフリが観測されるまでの回数を計測しました。

	待ち時間[秒]		10		30		60		90		120		150		180
	初プチフリ[回]		8		24		50		73		77		77		77

全てのシステムデータが解放されるまでに、なんと90秒以上の時間がかかっています。
次に、待ち時間に何もしないのではなく、90秒間ずっとランダムリードを行ってみたところ、全くシステムデータが解放されず、3回目にはもうプチフリ現象が発生してしまいました。つまり、読み込みが発生しているときはSSDがアイドル状態にならず、システムデータの解放が進まないようです。

同一箇所への連続書き込み

前回の記事にも書いたとおり、NANDフラッシュはデータを上書きすることはできません。そのため、同じ箇所に何度も書き込みを行うときは、前のデータに直接上書きするのではなく、別の場所に書き込む必要があります。
その時にJMF602搭載SSDがどのような挙動をするのか分からなかったので、全く同じアドレスに何度もデータを上書きするテストを行ってみました。
すると、予想ではジャンプ時と同様に77回めでプチフリ現象が発生するかと思いきや、なんと9729回までプチフリ現象が発生せず、以降も9729回おきにしかプチフリ現象が発生しませんでした。また、ランダムライト時やアドレスジャンプ時と異なり、レスポンス時間は約370msまたは約590msでした。
よって、同じ箇所への書き換えの場合、システムデータは4ブロックの管理単位ではなく、もっと小さい単位で管理されていると考えられます。
SHD-NSUM30の場合、1ブロックは4MB、1ページは32KBなので、1ブロックあたり128ページがあります。9728を128で割るとちょうど76となり、システムデータ内の管理単位の数とぴたりと一致します。ということは、同一ページの書き換えの場合は4ページ=128KBを1単位として管理が行われていると考えられます。
そこで、書き込みのサイズを4KBから大きくしていき、初プチフリが発生する回数を計測してみました。

	テストサイズ[KB]		4		8		16		32		64		96		128		192		256
	初プチフリ[回]		9729		9729		9729		9729		9729		4865		4865		3243		2432

うーん、計算が合いません。256KBで半分の4865になるのであれば管理単位は128KBのはずですが、上の計算結果では管理単位は64KBということになってしまいます。残りの半分はどこに行ってしまったのでしょうか…？
いずれにしても、なぜかはよく分かりませんが、同一アドレスへの書き込みの場合、ランダムライトやアドレスジャンプに比べ、プチフリが発生するまでの時間が非常に長いことが分かりました。

まとめと考察

以上見てきた通り、JMF602搭載SSDは、最悪の場合、わずか77回の書き込みでシステムデータを使い果たしてしまい、その状態では最悪の場合3回書き込みあたり1回の割合で700msまたは900msという非常に遅い書き込み時間が発生します。また、システムデータを使い切った状態から元に戻るために90秒以上もの時間が必要で、しかもその間は読み込みすら行われない完全なアイドル状態でなければいけません。
このSSDをシステムディスクとして使用した場合、一度システムデータを使い果たしてしまうと、上記の700msまたは900msという書き込み時間の間にさらに読み書きの要求が溜まり、連鎖的にレスポンスが悪い状態が続くことが予想されます。これが「プチフリ」の正体ではないでしょうか。
なぜ4ブロックを1管理単位として扱っているかはよく分かりませんが、可能性としてはJMF602のスペックの問題が挙げられます。JMF602は、96KBのDRAMメモリしか搭載しておらず、そのうち64KBはバッファとして使われるので、演算に利用できるのはわずか32KBとなります。ウェアレベリングを行うためにはブロックの消去回数をソートする必要がありますが、そのブロック数は例えば128GBモデルでは32000以上にもなります。SMARTから読み取れる情報によると、消去回数は3Byteの変数で表されているので、それを全て読み込んでしまうと32000x3Byte=96KBにもなってしまい、それだけでメモリから溢れてしまいます。実際には全ての消去回数をメモリにロードする必要は無いでしょうが、4ブロックを1管理単位として扱うだけで、メモリ必要量は4分の1になりますから、恩恵は大きいでしょう。
この異常に遅い書き込み時間そのものも、JMF602のバッファの少なさに起因していると思われます。上記のように、JMF602はバッファを64KBしか持っていません。一回のプチフリ現象で3管理単位が解放されるので、全てのブロックコピーが終了するまでに3x4x4096/64=768回ものコピー処理を行う必要があります。これでは遅くて当たり前です。

プチフリ対策について

今までの結果から考えると、読み書きの回数自体を減らすことが有効であるため、ページングファイルの無効化、プリフェッチの無効化といった対策は有効であると思われます。プチフリ自体は書き込み時に発生しますが、システムデータが解放されるためにはSSDがアイドル状態にならないといけないので、読み込みも減らした方が効果的なはずです。
また、書き込みが行われるアドレスの範囲がシステムデータのサイズである1.2GBを超えない限り、プチフリはほとんど発生しないと思われます。
以前の記事で、空き領域をデフラグすることで書き込み速度が回復することを紹介しましたが、この空き領域デフラグはプチフリ対策としても効果があると思います。空き領域が断片化して虫食い状態になっていると、飛び飛びのアドレスにデータが書き込まれてしまうためです。よく、インストールしてすぐは快適だったのに、しばらく使い続けたらプチフリが発生しだしたという体験談を目にしますが、これは空き領域の断片化が進行したためである可能性があります。

以上で、このシリーズは一区切りとさせていただきます。テスト結果や推測の内容について、ご指摘があれば遠慮無くお願いします。なお、SLC製品のテスト結果については後日掲載します。