(3)

SSDの"寿命"を理解する

大変長期間放置して申し訳ありませんが、ようやく続きです。

改めてSSDの寿命とは？

前回までの内容を簡単にまとめると、以下のような感じです。

  • NANDフラッシュの書き換え回数が増えると、ビットエラーの発生率が上昇する
  • SSDやUSBメモリなどのコントローラは、ビットエラーが多くなったブロックを無効化する
  • 無効化されたブロックが増え、SSD内に設けられた予備領域が使い果たされると、そのSSDは"寿命"を迎える
  • ビットエラーには、書き込みエラー(書いた瞬間にエラーがある)、保持エラー(書き込みから時間が経つとエラーが発生する)、リードディスターブ(多数回の読み込みを行うとエラーが発生する)の3種類がある
  • NANDフラッシュの種類によっては、保持エラーが非常に大きくなることもある。一方、リードディスターブは概ね無視できるほど小さい

SSDをはじめとするNANDフラッシュの"寿命"を平均書き換え回数で表現するにあたり、話をややこしくしているのがデータ保持エラーの存在です。書き込みエラーだけを考慮するのであれば、SSDに対する読み書きを繰り返し、壊れてしまった瞬間の平均書き換え回数を調べればよいでしょう。しかし、前回の記事にある通り、保持エラーの影響は非常に大きいのです。そのため、"書き込みエラーだけで壊れてしまう書き換え回数"に到達するより手前で使用をやめておかないと、しばらく前に書き込んだデータが気づいたときには壊れていた、といった現象が起こり得ます。

じゃあどのくらい手前でやめたらいいの？という問いには、SSDやNANDのベンダも明確な答えを出せていないように思えます。MLCタイプのNANDの書き換え回数の限界は5,000回や10,000回と指定されていることが多いのですが、これらは大分余裕を持った値になっているようです。慎重を期すならその程度の書き換えが生じたら使用をやめた方がいいということでしょう。

このように、SSDをはじめとしたNANDフラッシュ製品の"寿命"は、書き換え回数でスパッと表せるものではありません。多数回の書き換えを行ったNANDフラッシュ製品を使い続ける場合は、保持エラーによるデータ破損のリスクを念頭に置いた方がよいでしょう。同時に、NANDフラッシュ製品を長期間使用せずにしまい込むのもおすすめできません。

余談ですが、これからのSSDのコントローラを評価するにあたり、ECCの強化を始めとした寿命延伸機能は重要なファクターになると思います。既にプチフリSSDはほぼ根絶され、各社のSSD間の体感速度の差は縮まりつつあります。そんな中で他社との差を打ち出すのに、"高耐久性"は有用なアピールポイントとなるでしょう。例えば、前々回紹介したように、SandForce社のSF-1200/1500は、512バイト中192bitのエラーを訂正できるECCを持つほか、書き込みデータのオンライン圧縮による書き込み量の減少、RAID5に似た冗長データ(RAISE:Redundant Array of Independent Silicon Elements)の付加、全体の27%もの予備領域の確保、詳細不明ながらリードディスターブやデータ保持エラーへの対策など、野心的な寿命延伸機能を盛り込んだコントローラです。SF-1200/1500搭載SSDは、ともすれば"ランダムライトは割と速いけどコストパフォーマンスが微妙なSSD"という評価を受けがちですが、実際には高耐久性が求められる用途向けの製品と言えます。

というわけでJSMonitorについて…

今までツッコミが無かったのは皆様の優しさだと思っているのですが、以上のような背景を考えるとJSMonitorのような"寿命予測"ソフトはちょっと考え物です。まあ若さ故の過ちというか、今の状態だと逆に怖くてこんなソフトは公開できないでしょうね…
何が問題かというと、今のインタフェースだと"何年何月にお前のSSD壊れるよ？"と宣言しているようにしか見えない点です。前述したように、平均書き換え回数5,000回とか10,000回に明確なラインとしての意味があるわけではなく、その回数を越えた直後に壊れるという事例はむしろ少ないと思われます。
しかし、JSMonitorを使えば、例えばSSDへの書き込み量を減らす対策が効を奏しているのを検出できるなど、書き込み量のロギング・モニタリング機能そのものにはある程度意味があると思います。いつの間にか寿命予測機能が無くなっていたHDD Healthと同じ運命というのはちょっと悲しいので、もう少し見せ方を考えるべきかなあという感じです。今のところは、"SSD Tips"みたいな情報表示欄を作って、初回起動時に"T.E.Cの意味は何か？"を表示するというのを考えています。何かいいアイディアのある方はぜひコメントをお願いします。

参考リンク

東芝の勝算：HDD 完全代替に向けてOSによる対応が急務 - Tech-On！(要ID登録)
USBメモリーは 10年もつか - PC Online(要ID登録)
【USBメモリー編】放置厳禁！データの“自然蒸発”に要注意：徹底研究 メディアの寿命 - PC Online(要ID登録)
開発の現場から最新事情をレポート | SSD完全攻略マニュアル | DOS/V POWER REPORT
【元麻布春男の週刊PCホットライン】SSDの寿命 - PC Watch
SSDの信頼性は、すでにHDDを超えている〜東芝セミコンダクター社 インタビュー - 本田雅一の週刊モバイル通信
【福田昭のセミコン業界最前線】NANDフラッシュメモリの信頼性を保つ技術 - PC Watch
http://d.hatena.ne.jp/mathme/20090113/1231854636
USBメモリの書き換え限界寿命が来ると何が起きるのか、実際に寿命が来たケースをレポート - GIGAZINE
SSD耐久テスト - BotchyWorld
SSDアーキテクチャと未来(PDF)
ソリッドステートドライブのデータ信頼性と寿命(PDF)

(2)

SSDの"寿命"を理解する

ちょっと間が開いてしまいましたが、続きです。

NANDフラッシュにはどのくらいビットエラーが発生するか？

実際のNANDフラッシュのビットエラーの発生率について、以下の文献が興味深いので紹介してみたいと思います。

  • N. Mielke, T. Marquart, N. Wu, J. Kessenich, H. Belgal, E. Schares, F. Trivedi, E. Goodness, and L. R. Nevill. "Bit Error Rate in NAND Flash Memories," In Proc. of IEEE International Reliability Physics Symposium(IRPS 2008), pp.9-19, 2008.

この文献は、2008年に開催された国際学会の予稿で、著者はIntelとMicronの社員です。文献そのものはIEEEの会員資格を取得するか、あるいはIEEEと提携している大学の回線を使わないと参照できませんが、図表のうちのいくつかはPC Watchによる日本語での紹介記事から参照することができます。
要約は上記日本語記事を見てもらうのが早いのですが、以下では少し補足を入れておきます。
まず、図表中の4つの記号のうち、△はIMFTのNAND,□はスペックが"書き換え回数10,000回"となっている製品、○と◇は"書き換え回数5,000回"の製品とスペックに書き換え回数制限が記されていない製品です(どっちがどっちかは明記されていません)。テスト内容は1万回の書き込みの後、約1年〜1年半の放置または1万回の読み込み、となっていますが、□のデバイスのみは時間切れのためか放置実験は行われていません。
"Raw Read Error Rate"(RBER)は"ECC使用前のビットエラー発生数÷読み込みビット数"を意味します。指数で表記されるとわかりにくいのですが、例えばRBER=1.0E-7*1なら1.25MBの読み込みあたり1ビット、RBER=1.0E-10なら1.25GBの読み込みあたり1ビットのエラーが発生した、ということを表します。なお、RBERの分母は"読み込みビット数"であり、"NANDの総ビット数"ではないことに注意してください。
書き換え回数が増えるごとにRBERが上昇するのはまあ当然の結果として、むしろここで注目すべきはデータ保持エラーの方です。PC Watchの記事の写真3(予稿のFigure8)を見てください。特に○のNANDは、なんと最終的に桁が3つも上昇しています。これは、約1年半の放置でエラービットが発生する頻度が1,000倍に上がったことを意味します。
一方、リードディスターブについては、1万回程度の読み込みではほとんど問題にならないようです。リードディスターブの効果は一回書き換えが行われればキャンセルされるので、実際の使用で問題になる可能性は限りなく低そうです。
残念ながら上記の日本語記事では省略されていますが、予稿の中にはエラー訂正の効果についての推定結果も掲載されています。そこで用いられていた指標は、"訂正不可能エラーが発生したセクタの割合"(Cumulative Fraction Sectors Failing=CFSF*2, 訂正不可能エラー数÷総セクタ数)と"エラー訂正を行った後のビットエラーレート"(Uncorrectable Read Error Rate=UBER,訂正不可能エラー数÷読み込みビット数)の2点です。
予稿のFigure.20は、縦軸に4ビットECCを用いた場合のCFSF、横軸に1セクタ当たりの読み込みビット数を示したものですが、かなり印象深い図になっています。その結果を箇条書きすると以下のような感じになります。

  • 1万回の書き込み終了時点で、◇のCFSFは1.0E-08(約50GBあたり1つ)程度、他3つは1.0E-14程度。
  • 放置後実験後は、○のCFSFは1.0E-04(約5MBあたり1つ)以上、◇は1.0E-05前後まで増えるのに対し、△(IFMT製)は1.0E-13程度にしか増えない。
  • HDDのUBERは1.0E-13〜1.0E-16程度。NANDフラッシュのUBERが1.0E-13を上回ったのは、○と◇の放置実験後のみ。一方△のUBERは、実験全期間を通して1.0E-16を遥かに下回る。

この結果から、NANDフラッシュの型番によってはデータ保持エラーが意外と大きな影響を及ぼすことが分かります。しかも、これらのNANDのプロセルルールは63nm〜72nmであり、現行の3xnm〜5xnm世代の製品に比べるとエラーレートはかなり低いはずです。すなわち、現行の製品のデータ保持エラーは上述の結果よりさらに悪化している可能性が高いのです。現行世代のNANDフラッシュのエラーレートについても調べてみたのですが、今のところそれらのデータが載っている論文などは見つけられていません。もし該当するデータが載っている文書をご存じの方は、教えていただければ幸いです。

その他NANDフラッシュのエラーレートに関する文書

SLC,MLC両タイプのNANDの書き換え回数とエラーレートの相関グラフが出ています。2種類のECCの効果などが出ています。残念ながら、使用したNANDの型番やプロセスルールに関する記述はありませんでした。

SLC,MLC両タイプのNANDの書き換え回数とエラーが発生したセクタ数の相関グラフと、各種ECCの効果が出ています。やはりNANDの型番やプロセスルールに関する記述はなく、また、実験に使用されたNANDがSLCで64セクタ、MLCで128セクタと少量です。



しつこいですがまだ続きます。

*1:これはプログラミングでよく使われる指数の書き方であり、1.0\times10^{-7}と同じです

*2:原稿の中ではCFSFという略称は出ていませんが、以下面倒なのでこれを使います。

(1)

SSDの"寿命"を理解する

「NANDフラッシュを利用した製品には寿命がある」という記述はあちこちで見かけますが、具体的に"寿命"とは何なのかという点についての詳しい説明は少ないのが現状です。…というより、今まで不勉強で僕がよく分かってなかったので、最近調べた内容について記しておきます。

SSDはどうなったら使えなくなる？

SSDの寿命が尽きた状態とは、SSD内の予備領域が払底した状態を指します。
SSDをはじめとしたNANDフラッシュを利用するストレージには、必ず「予備領域」が設けられています。後述するように、SSDやUSBメモリなどのコントローラは、ビットエラーが多数発生したセクタを含むブロックを"不良ブロック"とみなし"無効化"します。このとき、OSから認識されるストレージの容量が減ってしまうと困ったことになります。そこで、コントローラは、予備領域からブロックを補填することで、額面の容量が減らないようにしています。次々にブロックが無効化されていき、予備領域が空になってしまうと、ストレージは"寿命"を迎えることになります。東芝のSSDの場合、この状態になるとSSDがリードオンリーモードになるようです。他社製コントローラでは特に明言されていませんが、予備領域が無くなるとNANDフラッシュの仕組み上データの書き換えができなくなるので、おそらく同様にリードオンリーモードになると思われます。
一般的なコンシュマー用SSDの予備領域は、"Binary Gigabytes"(GiB,1024x1024x1024Bytes)と、"Decimal Gigabytes"(GB,1000x1000x1000Bytes)との間の約7%の"ギャップ"を用いて捻出されています。例えば128GBのSSDの場合、NANDフラッシュは128GiB(＝128x1.024x1.024x1.024≒137.4GB)搭載されています。その差分の約9.4GB分が予備領域になります。
予備領域の払底＝寿命となるので、NANDフラッシュの総量が同じであれば、予備領域の割合が多い製品ほど寿命が長くなります。そのため、長寿命を目指した製品は予備領域の割合を多く取っています。例えば、X25-Eの64GB版は80GibのNANDを搭載しているので、全体の約25.5%が予備領域です。STEC社の産業用グレードのSSDに至っては、実に全体の約46.9%が予備領域になっています。

ビットエラーとECCとブロックの無効化

どのような状態になったときにブロックを無効化するかは、SSDのコントローラによって異なります。
NANDフラッシュには、ビットエラー(データ化け)が発生する可能性があります。特にMLCタイプのNANDの場合は、かなり高い確率でビットエラーが発生します。そのため、SSDのコントローラは、ECC(Error-correcting code)という冗長データを書き込み時に付加し、読み込み時にそれを用いてエラーのあるビットを修正しています。
書き込み・消去時のエラーは、書き換え回数が多いほど起こりやすくなります。それが、「NANDフラッシュには書き換え回数の制限がある」と言われる所以です。一般的に、NANDフラッシュのベンダは、MLCでは5,000から10,000回、SLCでは100,000回が書き換え回数の上限であるとしています。
実は、ここに一点重要なポイントがあります。この書き換え回数の上限は、NANDフラッシュのベンダが指定した強度のECCを用いた時のものです。多くの場合、ベンダはMLCの場合は512バイト中4ビット, SLCの場合は512バイト中1ビットを訂正可能なECCを想定しています(訂正 4ビットで済んでいたのは5xnm世代までで、最近の3xnm世代のNANDでは8ビットECCが想定されているようです。参考:【福田昭のセミコン業界最前線】NANDフラッシュメモリの信頼性を保つ技術 - PC Watch)。そのため、SSDのコントローラがベンダの想定より高い強度のECCを利用していれば、より多い回数を書き換えることが可能になります。
例えば、DailyTechの記事の記事によると、IndilinxのBarefootコントローラは512バイト中12ビット以上のエラー訂正が可能であり、また、BCHとリードソロモンの2種類のECCがハードウェア実装されているようです。一方、SandForceのSF-1500コントローラの場合は何と512バイト中24バイト(192ビット)を訂正可能なECCを搭載しています。これだけ強力なECCがあれば、相当な回数の書き換えを行っても正しくエラー訂正が可能になるでしょう。
もうお分かりかと思いますが、ブロックの無効化判定がコントローラごとに異なる理由は、コントローラごとに異なる強度・アルゴリズムのECCを用いているためです。例えば、4ビットECCを用いるコントローラは、1セクタ内に5ビットめのエラー(＝訂正不能)が出る前にそのセクタを含むブロックを無効化する必要があります。しかし、ECCの強度がより高ければ5ビットめのエラーも訂正可能なので、そのブロックを無効化する必要はなくなり、結果として寿命が長くなります。

NANDフラッシュのビットエラーの種類について

ビットエラーは、データの読み込み時にECCをチェックすることにより、検出・修正されます。ビットエラーの種類を細かく分類すると、以下のようになります。

  • 書き込みエラー (書き込んだ時点で既にビットエラーがある)
  • データ保持エラー (長期間放置しておくとビットエラーが発生する)
  • リードディスターブ (消去を行わずに多数回の読み込みを行うとビットエラーが発生する)

いずれも、書き換え回数が多いほど発生しやすくなります。余談ですが、寿命が迫ったSSDをバックアップメディアとして用いるのは危険です。なぜなら、寿命が迫ったSSDではデータ保持エラーが発生する可能性が高く、しばらく机の中にSSDを放り込んでいたらデータが壊れていた、といった悲劇が発生しうるためです。そういう用途には、おとなしくHDDを使いましょう。
これらは書き込み・読み込み時に発生するエラーですが、さらに消去時のエラーというのも存在します。これは、消去動作を行っても全てのビットが1にならない現象です。この現象が発生したときは、SSDコントローラはそのブロックを無効化することが多いようです。



長くなって来たので、続きは次回にします。

CrystalDiskMark 3.0の新機能紹介

SSD

更新をサボっている間に、CrystalDiskMark 3.0が公開されていました。
旧バージョンのCrystalDiskMark 2.2と比較して、SSDの性能を多角的にベンチマークするための新機能がいくつも追加されています。今回の記事では、ベンチマーク結果を交えてそれらの新機能を紹介してみたいと思います。

Random Read/Write 4KB QD=32

起動して一番最初に目に付くのが、"4K QD32"という新しいテスト項目が追加されている点です。これは、NCQ(Native Command Queuing)による性能向上をベンチマークするためのテストです。
NCQとは、HDDやSSDが複数の読み込み・書き込み命令を同時に受け取ったときに、同時処理や順序の並び替えにより、パフォーマンスを向上させる仕組みです。QD(Queue Depth)とは、同時に発行される命令数を表します。つまり、このテストでは32個の命令を同時発行しています。

このベンチマーク結果では、Readに関しては"4K QD32"のスコアが"4K"の2倍以上になっていますが、Writeに関しては"4K QD32"と"4K"がほぼ同等になっています。すなわち、このSSD(K5-64)では、読み込みにのみNCQが有効であるということが分かります。他のSSDでは、例えばIntelのX25-Mでは読み書き両方でNCQが有効であり、SamsungのPB22-Jシリーズや東芝のHG2シリーズでは読み書き双方ともNCQは無効です。

テストサイズ 2000MB/4000MBの追加


CrystalDiskMarkは、テスト用に一時ファイルをディスクに作成し、そのファイルに対し読み書きを行うことでベンチマークを行います。2.2ではこのファイルの最大サイズを1000MBまでにしかできませんでしたが(デフォルト100MB)、3.0からは最大サイズが4000MBになりました(デフォルト1000MB)。
テストファイルのサイズが小さいと、例えば大容量の書き込みキャッシュを持つRAIDカードのベンチマークを行った際に非常に高いスコアが出てしまうことがあります。これは、テストファイルの全て、あるいは大部分がキャッシュ上に作成されてしまうことが原因です。(参考:Akiba PC Hotline!によるLSI MegaRAID SAS 9260-8iのベンチマーク)

同様の現象が、SSDにおいても発生することがあります。上図は、BuffaloのSHD-NSUM30(JMF602,MLC,32GB)についてテストサイズ1000MB/2000MBの結果を比較したものです。
注目するべき点は、Write 512K/4Kのスコアが2000MBでは非常に落ち込んでいるところです。この現象は、JMF602がSSD内の予備領域のうちの一部分をあたかも書き込みキャッシュのように用いており、テストサイズを2000MBにするとその領域からデータが溢れてしまうことに起因します。JMicronはその一部分の領域のことを"システムデータ"と呼んでおり、SHD-NSUM30の場合は約1.2GBの容量を持ちます。テストサイズ1000MBの場合はシステムデータ内にファイルが収まりますが、2000MBの場合は溢れてしまいます。
JMF602搭載SSDを起動ディスクとして使用したとき、システムデータが一杯となるとランダムライトの性能が異常に遅くなり、OSの反応まで悪くなってしまいます。それが悪名を馳せた「プチフリ」です。2.2まではテストサイズが1000MBまでしか選べなかったため、多くのJMF602搭載製品についてランダムライト性能の低下を検出できませんでしたが、今回のバージョンからはしっかり検出できるようになりました。
(プチフリ問題に関しての詳しい検証はこちら)

書き込み内容の変更(Random/0Fill/1Fill)


前回の記事に書いた通りなのですが、一部のSSDは書き込み内容によって大きくパフォーマンスが変化します。3.0では、"ファイル(F)"->"テストデータ(T)"から、書き込み内容を変更することができます。上図は、OCZのVertexシリーズの30GB版において、書き込み内容を変化させたベンチマーク結果です。
この機能は、書き込み内容が0Fillである他のベンチマーク(HD Tune, ATTO Disk Benchmarkなど)との比較のためのものと言えます。そのため、理由がない限りデフォルトのランダムのままでベンチマークを行った方が良いでしょう。

空テストの追加

前述したように、通常の場合、書き込みキャッシュは"キャッシュ容量>テストファイルサイズ"となったときに大きな影響を及ぼします。ところが、SamsungのPB22-Jシリーズでは、書き込みキャッシュが特徴的に使われています。

上図は、PB22-Jシリーズの64GB版についての、CrystalDiskMark 2.2の結果です。Random Write 4KBの値が12MB/sを超えていますが、このような結果が出るのは1回目のみで、2回目は2MB/s前後、3回目以降は0.5MB/s程度の性能しかでません。CrystalDiskMarkは、5回(デフォルト値)のテストの最大値を結果として表示するため、最終スコアがこのような形になってしまいます。この結果は、おそらくPB22-Jが小さいサイズの書き込みに限ってデータをキャッシュに保存するためだと考えられます。

3.0では、この問題を軽減するために空テストが追加されています。すなわち、テスト回数が5回の場合は実際には6回のテストが行われており、最初の1回の結果は捨てられます。そのため、上記のような結果になります。

まとめ

以上のように、CrystalDiskMark 3.0では、SSD時代に対応した様々な機能追加が行われています。CrystalDiskMarkの最大の利点は、お手軽簡単というところにあります。ベンチマーク結果は多くの人の参考になりますので、皆さんもじゃんじゃんベンチマークしてBlogや掲示板などに貼り付けましょう。ただし、ベンチマークのし過ぎはSSDの寿命を縮めますので、長く細く使いたい人は程々にしてください。

Barefoot搭載SSDは書き込むデータの内容によって性能が変わる？

SSD

すでに旧聞に属する話なのですが、Crystal Dew Worldの掲示板において、SandForce社製のSF-1500コントローラ搭載SSDの書き込み速度の特性が話題になっていました。具体的には、書き込むデータの内容がランダムの時のシーケンシャルライト性能が130MB/s程度なのに対し、全て0のデータを書き込むときは200MB/s以上の速度が出るというものです。
SF-1500は長寿命化を図るため、非常に野心的な設計を施されたコントローラです。具体的には、オンラインでのデータ圧縮、512バイト中24バイトを修正可能なECC、RAID5に似た冗長データの保持(RAISE:Redundant Array of Independent Silicon Elements)など、既存のコントローラとは一線を画す機能が搭載されています。これらのうち、上記のパフォーマンスが変化する現象を引き起こしている原因は、おそらくデータ圧縮にあると思われます。すなわち、圧縮の効果が大きいデータの書き込みは速く、効果が少ないデータに対しては書き込みが遅くなるということです。いつもコメントを頂いているmarosamaさんのBlogの記事でも、データの内容によってコピー速度が大幅に変化することが示されています。
…というだけで話は終わりと思いきや、何故かBarefoot搭載のVertexでも同様に0Fillかランダムかで大幅に書き込み速度が変わるという現象が発生しています。Vertexでは、CrystalDiskMarkやAS SSD Benchmarkなどに比べ、ATTOやHD Tuneで妙に高いパフォーマンスが出るのですが、それはこの現象が原因のようです。
というわけで、書き込み内容を変えた際に、書き込み速度にどれだけの差が出るかを計測する簡単なプログラムを作ってみました。ダウンロードはこちらからお願いします。
このプログラムを、Vertex 30GB(Barefoot, MLC), K5-64(Barefoot SLC), MasterDrive SX 64GB(Samsung PB-22J相当)の3つのSSDに対して実行した結果が以下です。

SSD All 0x00h(0Fill) All 0xFFh(1Fill) Random
Vertex 142.285MB/s 163.934MB/s 91.8924MB/s
K5-64 176.831MB/s 189.225MB/s 176.202MB/s
PB-22J 140.056MB/s 144.174MB/s 144.604MB/s

以上の表のように、Vertexでのみパフォーマンスに大きな差が現れました。同コントローラでSLCを搭載しているK5-64は1Fillの時だけ若干速く、PB-22Jではほとんど差は見受けられませんでした。
Barefootを搭載したVertexとK5-64では、0Fillより1Fillの方が速くなっています。NANDフラッシュにデータを書き込む時は、最初に消去(全ビットを1にする)を行った後、データの書き込み(任意のビットを1から0に変える)を行います。おそらく、Barefootはデータが全て1だったとき、2番目の書き込みのフェーズを飛ばすような最適化をしているのだと思います。
Vertexにおいてのみ大幅にパフォーマンスが変化する原因はよく分かりません。Vertexは0Fill/1Fill以外でも、例えば00FF00FF...といった周期的なデータでも書き込みが速くなるので、もしかするとインターリーブが最適化される(次に来るデータが前と同じならロード時間が不要になる)のが原因かと思ったのですが、1.5倍もの差が出るとは思えず、また、K5-64でほとんどパフォーマンスに差が見られないことを説明できません。
というわけで、この現象の原因について心当たりのある方はご教授いただければ幸いです。

SST-HDDBOOSTについて、SilverStone社からお返事を頂きました

SSD

前回の記事に記した通り、実物のSST-HDDBOOSTの挙動が公式サイトの説明と異なっているのではないか？という質問をSilverStone社に送ってみたところ、非常に迅速かつ丁寧な回答を頂きました。ブログへの転載の許可もいただいたので、その内容について書きたいと思います。

パフォーマンスの問題について

SilverStone社のサポートによると、現在のファームウェア(Rev.100127.1.C07)はやはりHDDとSSDの両方に同時に書き込みを行っているとのことです。これは、詳細は分かりませんが、GPTを用いた2TB以上のディスクを接続した際に発生する不具合を回避するための措置だということです。この問題は近く公開されるファームウェアで解決される予定です。
というわけで、「試した！」さんの記事を見ると明らかなように、現在のファームウェアでCrystalDiskMarkを実行すると以下のような結果が得られます。

  • 読み込みは(ほぼ)SSDのスコア
  • 書き込みはHDDとSSDのうち遅い方のスコア

そして、新しいファームウェアを適用するとCrystalDiskMarkのスコアは読み書き共にHDDのスコアとほぼ同等になるはずです。その挙動が正しいので、「新しいファームウェアを入れたら速度が下がった！」と騒がないようにしましょう。
SST-HDDBOOSTの効果を正しくベンチマークするには、以下の方法が考えられます。

  • HD TuneやHD Tachのように、テスト時に一時ファイルを作らないソフトを用いて読み込み速度を測定する
  • Iometerでテストファイルを作成->消さずに再起動または手動シンクロナイズ->そのファイルを用いて読み込み速度を測定する

前者はテスト前に書き込み(一時ファイルの生成)を行わないので、SSDからの読み込みが行われます。後者は、再起動前に作成されたテストファイルはHDDに格納されますが、再起動時にSSDにデータがシンクロナイズされるため、再起動後のテストではSSDからの読み込みが行われるはずです。

HDDBOOST Utilityについて

HDDBOOST Utilityの全般的なマニュアルが存在しなかったので、機能・表示についても質問してみました。

  • Start/Stopボタン : 手動シンクロナイズのスタート・ストップ(ただし、前述の問題のため、現在は最初のコピー以外では動作していないと思われます)
  • Buzzer Muteチェックボックス : 機能未実装
  • Hybrid Informationグループボックス内の "Mode : Protect"の意味 : これもまだ機能未実装(将来的にモードが増える？)

HDDBOOST接続前のデフラグについて

ここからはサポートに聞いた話ではないのですが、ふと思いついたので記しておきます。
公式サイトのQ&Aにあるように、HDDBOOSTはディスクの先頭の一部分だけをSSDにミラーリングするため、HDDBOOSTを接続する前にHDDのデフラグを行い、データをディスクの先頭の方に詰めておくことが推奨されています。
マニュアルではWindows標準のデフラグの画面が表示されていますが、個人的にはこのデフラグにはPefrectDiskが適しているのではないかと思います。PerfectDiskには、"SMARTPlacement"という独自技術が実装されています。これは、ブートに関連するファイルや更新日時の古いファイル(=Read Onlyのファイル)をディスクの先頭の方に、更新日時の新しいファイル(=よく書き込みが行われるファイル)やディレクトリ情報などをディスクの後ろの方に持ってくることにより、断片化の生じる範囲を狭く保ち、以後のデフラグが速く完了するようになるという技術です。参考画像を見ると一目瞭然で、ブートに関係するファイル(紫)や更新日時の古いファイル(青)が先頭の方に並んでいるのが分かります。この方法でデフラグを行うと、ブートに関係するファイルや読み込みしか行われないファイルがディスクの先頭の方に来るため、それらのファイルが効率よくSSDにミラーリングされるはずです。デフラグ前に動画などの読み込みが速くなってもあまり関係ないファイルを避難させておくとより効果的でしょう。
なお、このソフトは有料ですが、30日間全ての機能が使用可能な体験版があります。もちろん最もよいのは製品版を買うことなのですが、この用途に使うだけなら、体験版だけでも十分かもしれません。

SilverStone SST-HDDBOOSTを買ってはみたものの…

SSD

SST-HDDBOOSTというキワモノが販売されていたので、ついつい手を出してしまいました。
この製品は、SSDを用いてHDDの読み込み速度を向上させるというものです。原理は簡単で、HDDの内容の一部をSSDにミラーリングし、読み込みのリクエストが来たときに、そのデータがSSD上にあればSSDから、なければHDDから読み込むというものです。SSDの方が圧倒的に読み込みが速いので、この仕組みでドライブ全体のパフォーマンスが向上するという寸法です。HDDのデータのうち、どの部分をSSDにミラーリングするかというのは色々工夫ができそうなものですが、この製品の場合は単にHDDのLBAの先頭部分だけがミラーリングされます(参照:代理店のマスタードシード社のページ、ギャラリー6枚目のHD Tuneの結果)。小細工を弄さず、男らしい割り切りですね。
この製品を用いれば、JMF602搭載SSDが救済されると考えられます。これらのSSDはリード全般とシーケンシャルライトは速いものの、ランダムライトが非常に低速です。それが原因でプチフリが発生してしまうので、これらのSSDはシステムドライブとして使うには向いていません。ところが、HDDBOOSTは、システムの起動時に同期を取る以外ではSSDに対して書き込みを行わず、専らHDDにのみ書き込みを行います。SSDに対して書き込みが行われないなら、当然プチフリは発生しなくなるはずです。なお、公式サイトではIntel G2を使った紹介画像が出ていますが、このSSDのランダムライト性能は非常に高いので、HDDBOOSTに使うにはもったいなさすぎます。
今回は、普段録画＆ファイルサーバーとして使っているマシンにHDDBOOSTを接続してみました。SSDはBUFFALOのSHD-NSUM30、HDDはWestern DigitalのWD15EADSです。OS(Windows XP)はWD15EADSの先頭60GBのパーティションにインストールされているため(使用量20GB)、システムに関連したファイルはほぼ全てSSDにミラーリングされ、快適な環境ができるはずです。
…という目論見だったのですが、どうも何かおかしいです。ミラーリングのプロセスは終了しているにも関わらず、使用感は全然快適でなく、ものすごく引っかかりを感じます。
そしてCrystalDiskMarkの結果は以下の通り。

この結果は公式サイトの説明と矛盾しています。CrystakDiskMarkはベンチマークを開始する前に一時ファイルを作成し、そのファイルに対して読み書きを行い、結果を出力します(テストサイズはそのファイルの大きさを示します)。公式サイトにあるように、システムの起動時にしかSSDに書き込みが行われないなら、その一時ファイルはHDD上に置かれるはずです。しかし、上記のベンチマーク結果を見る限り、読み込みのパフォーマンスは明らかにSSDに由来しています。すなわち、HDDBOOSTはHDDと同時にSSDにも書き込みを行っているとしか思えません。
というわけで、全く納得がいかないので、SilverStoneに問い合わせのメールを送ってみました。ついでに、HDDBOOST Utilityのよく分からない項目(Start/Stopボタン、Buzzer Muteチェックボックス、"Mode : Protect"の意味)についても聞いてみました。台湾は来週末から旧正月で休みになるようですが、果たして返信は返ってくるでしょうか…