レビューメディア「ジグソー」

RAID0で快適PCライフ

今回は、zigsowインテルダイナマイトレビューで当選したintel X-25M 160GB SSD x2台を利用したRAID0のレビューをお届けする。

しかし1つ先にお断りしておかなければならないのは、今回送付されてきたのは、商品説明画像にあるようなリテールパッケージ版のSSDSA2MH160G2R5ではなく、SSDSA2MH160G2C1と、組み込み用の茶箱版であった。
リテールパッケージ版、組み込み用茶箱版のどちらの製品にも9.5mm→12.5mm厚用のスペーサーは付属しており、リテールパッケージ版との違いとしては、2.5inch→3.5inch変換マウンタが付属しないという点のみで、保証期間などはどちらも3年と変わらない為、マウンタの要不用、そして価格でリテールボックスにするか、組み込み用の茶箱を選ぶかの選択をしてもいいだろう。

まずはRAID0の説明から。RAID0とは、RAID本来の利用方法である冗長性の確保という観点からは事なり、冗長性を確保する事はできず、2台に同時に読み書きを行うことでパフォーマンスを上げる為に用いられる手法だ。ちなみにRedundant Arrays of Inexpensive(Independent) Disksの頭文字を略したものである。

RAID自体はそもそもハードディスク(データドライブ)の信頼性を確保するための機能であり、RAID0自体はHDD2台にまたがって書き込む為に、物理的故障率が2倍になり信頼性を下げる為、RAIDのなかでは異端児的な存在だ。…が、ことSSDに関した場合、HDDと違い、単純に故障率が2倍に上がるわけではなく、SSDの寿命を決める「総容量と総書き込み量の相関関係がほぼ比例関係にある」という特性のため、2台となることで総容量が2倍になり、寿命までの総書き込み量の理論値がおおよそ2倍程度に延びるという性質があり、単純に信頼性が下がるというわけではないところがミソだ。

しごく簡単にいえば、10GBのSSDと100GBのSSDでは、寿命までに書き込める総容量が10倍変わってくるという事だ。(実際には他の要素も絡んでくるので、ここまで単純に寿命が決定するわけではないので、その点は注意して欲しい。)

ということで、SSDの場合は、2台でRAID0とすることで物理的な故障に対しての信頼性は1/2に落ちるものの、総書き込み量における寿命は2倍近くに延びる可能性があるため、3台、4台と増やせば、リニアに寿命が延びる可能性があるのだ。この辺りはHDDとSSDの特性の違いということで、RAID0が単純に信頼性を落とすわけではないという点で非常に面白い関係だと言える。

SSD自体の内部ではRAID0と同様の事をNANDフラッシュに対して行っており、今回のintelのX-25Mの場合は、内部のコントローラーが10個のNANDフラッシュに対して並列に同時アクセスする事で、読み書きのパフォーマンスを上げるとともに偏った書き込みを行わず、それにより寿命を延命させている。言わば内部でNANDフラッシュに対して10chのRAID0を組みアクセスしている形だとも言える。ある種RAID0はNANDフラッシュやSSDと非常に相性が良いとも言えるだろう。

まずは動作確認から。RAIDアレイを組む前に単体でICH10に接続し動作確認を行った。SSDを接続しWindowsを起動すると以下の様な感じでセットアップされた。
セットアップ終了後、再起動しベンチマークをとってみたところ、本来のパフォーマンスが出ていないのではないのではないかというような、少々遅い結果が出た。その結果がこれだ。
何度か再起動するなどをして試してみたのだが同様の結果が出たため、SATAポートを移動してみたところ、本来のパフォーマンスであろう下の様な結果出た。
この後、元のポートに戻してみたところ、本来のパフォーマンスが出るようになったので、結局何が原因だったのかがわからないのだが、もしこの様に本来のパフォーマンスが出ないような状況となった場合には、ケーブルの抜き差しやポートの移動などをすることで、状況が改善することがあるかもしれない。パフォーマンスが出なかった時のピーク性能が140MB/秒という数字から察するに、最初は接触不良などによりSATA1.5Gbpsでアクセスされていたのかもしれない。

ということで、単体でもシーケンシャルリードで261MB/秒、ライトで107MB/秒、そしてランダムアクセスでもHDDとは比較にならないほどの、かなり高いパフォーマンスが出ている事がわかるだろう。

SMARTの値などを確認してみると、数度のベンチマークしか行っていないのにもかかわらず、既に総書き込み量が66.5GBと表示されていた。10GBも書き込んではいないのだが、出荷前にはしっかりと動作確認が行われているということなのだろう。
また、対応機能を確認してみるとTRIMに対応している事が読み取れる。TRIMとは、SSD・フラッシュメモリーの独特なアクセス方法に関する最適化コマンドとでも言う様な機能であり、現状ではWindows7のみが対応しているという状態だ。しかしながら、Windows XPやWindows Vistaでもintel SSD TOOL BOXをインストールし、利用する事で、Windows7の様に常時とまではいかないが、手動、またはスケジューリングを設定して定期的にSSD内部の最適化を行う事が出来るツールが無償で提供されている。(ただしAMD/ATIのチップセットで利用する事はできないので注意して欲しい)

このTRIM機能や、intel SSD TOOL BOXに関する情報は、こちらの「インテル® SSD オプティマイザーとは?」というページが詳しいので気になる方は参照してみると良いだろう。

このTRIMに関してなのだが、SSDを使用する上で機能的に素晴らしい機能なのではあるのだが、RAIDを利用する場合には現状では残念ながら利用できない。今後、intel SSD TOOL BOXやOS、RAIDドライバの対応待ちというのが現状だ。

私の手元には、intelのRAID対応チップセットICH10R、JMicronのJM363という2つのコントローラーを搭載したMSI BIG BANG FUZION、そしてSil3132を搭載したRAIDコントローラーがあったので3つのコントローラーでRAIDを、そしてBIGBANG FUZIONに搭載されているJMicronのJM322もWindowsに標準搭載されているストライプ機能を使ってベンチマークをとってみた。

セットアップ自体は、どのコントローラでもそれほど難しいものではなく、intelのICH10R内蔵RAIDコントローラの場合であればBIOS画面でCtrl+I、Sillicon ImageのSil3132RAIDコントローラであればCtrl+Sを押し、その後に表示されるセットアップ画面で、RAID0を構築するためのドライブを選択し決定するだけだ。その際にストライプサイズの設定があり、コントローラにもよるが、4KB~128KBの設定ができる。このストライプサイズと言うのは、簡単にいえば、2台(もしくはそれ以上)に書き込むときに、1台あたりの最低データサイズというイメージだ。4KBに設定すれば4KBずつ書き込まれ、128KBにすれば128KBずつ書き込まれる事になる。このストライプサイズを小さくする事でランダムアクセスが速く、大きくする事でシーケンシャルアクセスが速くなる。今回は、どのコントローラでもストライプサイズを中間値である32KBに設定してRAIDボリュームを構築した。

------------------------------------------------------------------------
※Intel in Akiba 2010 Summerにて、SSD-RAID0構成での注意点として、

         「RAID0のストライプサイズは64KBを選ぶ」

という注意事項がありました。おそらくSSD側の最小ブロックサイズとの兼ね合いなのだろうと推測されるところですが、64KB以上に設定した方がよいでしょう。
------------------------------------------------------------------------

まずはintelのICH10Rからだ。(上が単体、下がRAID0)
読み込みで500MB/秒を超え、書き込みでは200MB/秒を超え、単体の時と比べ、ほぼ倍となっている。しかしながら512KBのランダムアクセスは読み込みで1.5倍、書き込みで2倍となっているが、4KBのランダムライトは殆ど変っていないのが特徴的だろうか。

そしてICH10Rを使ったWindowsのソフトウェアRAID0(ストライプボリューム)の結果がこちらだ
ハードウェア設定でのRAID0と比較してもほとんどそん色のない結果が出ている。この事から、起動ドライブとして利用するのでなければ、RAID対応のハードウェアを使わなくともWindowsの標準機能であるストライプボリュームでもパフォーマンスは十分に発揮できるという事がわかる。

次にJMicronのJMB363をテストしてみた。(上が単体、下がRAID0)
こちらは単体の時点でICH10Rよりもパフォーマンスが悪い。それだけにあらず、RAID0とする事で書き込み速度は上がっているが、読み込み速度は逆に下がってしまうという様な結果となってしまっている。JMB363はRAID対応チップとして廉価なRAIDボードに搭載されている事が多いのだが、SSDをRAID0として使うには少々力不足であると言わざるを得ないだろう。ならば、ハードウェアではなくOSでストライプボリュームを作成してみたらどうなるのだろうか?という事でその結果がこちらだ。
ハードウェアでRAID化した時と殆ど変らない結果となった。ということは、RAID化の為にパフォーマンスが落ちたというよりは、複数のドライブに同時アクセスした場合のピークパフォーマンスがこの程度なのであろうと考えられる。

SilliconimageのSil3132の結果はこちらだ(上が単体、下がRAID0)
こちらもJMB363とほぼ同様な結果となった。こちらも廉価なRAIDカードに良く使われるチップの為、あまりパフォーマンスは高くないのだろう。このチップはポートマルチプライヤに対応しているため、ポートマルチプライヤ対応のHDDケースにSSDを2台搭載し、1chでのRAID0も試してみた。その結果はこちらだ。
2chでの運用とピークで2割程しか変わらない結果となった。JMB363と共に、あまりにピーク速度の速いSSDとのRAIDには向かないのだろう。

チップの機能としてはRAID機能を有しているが、eSATA用に搭載されているためRAID機能を有していないJMB322をWindowsのストライプボリュームでテストしてみた。(上が単体、下がストライプボリューム)
こちらもやはりJMB363と同様に単体でもRAIDでも奮わない結果となってしまった。やはり廉価なコントローラはピークが低いといった感じなのだろう。

以上の結果から、JMicronやSillicon Imageなどの非常に廉価なRAIDコントローラでは、現状ではSSDのRAIDコントローラとしては力不足であると言える。それとは真逆に、今回の結果を見るとintelのチップセットに統合されているICH10Rのコントローラは非常に優秀だと言えるだろう。もし、SSDでRAID環境を手に入れようと考えていて、チップセットにRAID機能が内蔵されていない場合、下手に高価なRAIDカードを買うよりも、マザーボード自体を買い替えてしまった方が廉価に済ませる事ができるとも言える。

また、500MB/secを超えるような速度を実現しようと思うとPCI Express 2.0 x1の帯域(500MB/sec)では収まりきらなくなるため、より高パフォーマンス向けのRAIDカードはPCI Express 2.0 x4以上のインターフェースを有している。しかしながらPCI Express 2.0 x4などのインターフェースを持つマザーボード自体も少なく、RAID0を目的とするのであれば、これらの面から見てもマザーボードごと交換してintelのICH10Rなどのチップセット内蔵のRAID機能を利用した方がいいだろう。

もしRAIDカードの増設を考えている場合も帯域の問題から、間違ってもPCI接続のRAIDカードを選択してはいけない。通常のPCI(32bit/33MHz)の場合は133MB/secが上限となってしまっているため、SSD単体の速度ですらPCIバスがボトルネックになってしまうからだ。一部サーバーやワークステーション、PowerMacなどに搭載されている64bit/66MHzなどであれば4倍の533MB/secとなりPCI Express 2.0 x1と同等、PCI-Xであれば1066MB/secとなりPCI Express 2.0 x2とほぼ同等となるが、普通はそのような特殊なPCIバスが一般的なコンシューマー用のマザーボードに搭載されている事はない為、もしRAIDカードを増設するのであれば、PCIではなくPCI ExpressのRAIDカードを選択するべきである。

高価なRAIDカードであれば様々なRAIDボリュームの構築であったり、パリティビットの演算など、それ自体がワンボードコンピュータの様な構成となっており、非常に多機能でCPUに対する負荷も少なく、バックアップなども含め本格的な運用をするのであれば、チップセット内蔵のRAID機能よりもずっと有利であることは間違いない。しかしながら、単純にRAID0でパフォーマンスを上げたいというだけであれば、わざわざ高価なRAIDカードを導入するメリットはほとんどないと言ってしまってもいいだろう。

何を持って高価な…とするか微妙なところではあるが、MarvelのRAIDコントローラを有した1~2万円程度から購入できる、まともな機能を有した比較的廉価なRAIDカードでも500MB以上の転送速度を有しているようだ。パフォーマンスに関してはコントローラによってかなりばらつきがある為、可能であれば事前に良く調べた方がいいだろう。

さて、ここからは、このSSD2台でのRAID0環境の実運用だ。

筆者の場合、どうしてもOSのブートドライブには150GB~250GBを利用しているため、1台のSSDでは運用できるような状態ではなかった。今回のレビューに伴い、ブートドライブの中身で他のドライブに移動できるデータを整理してもこんな状況である。


ということで、筆者としてはピークスピードというよりはRAID0によるドライブサイズの拡大というポイントから今回の運用に至っているわけだ。正直言って、OSのブート速度やアプリケーションのブート速度と言うのに頓着は無く、基本的に遅いのは当然であるという前提からOSもアプリケーションも基本的に起動しっぱなしである。OSも1からブートさせるのは時間がかかるので、殆どの場合サスペンドを利用しており、サスペンドからの復帰であればそれなりに高速だ。つまりこれらの点に関しては特に期待はしていない。OSのブートに関しては特に、様々なデバイスが接続されている筆者のPCではディスクのリードが速くなろうとも、各種デバイスのイニシャライズに時間がかかるため、それほど高速になるとも思えないというのも理由の1つである。

前述したとおりそれほど期待をしていないOSの起動である。Windowsのログオン画面までの時間は多少は縮まったものの、やはりそれほど劇的なものではなかった。しかしながら、ログイン画面からパスワードを入力し、実際にWindowsが快適に使えるようになるまでの時間は圧倒的に短くなった。

HDDで運用している時は、おおよそ3分~5分はガリガリガリガリと延々重たい処理を繰り返していたのであるが、SSD RAID0にしたところ、これがおおよそ20-30秒程度となった。OSの再起動などを行った場合には、大抵他の事をして時間を潰していたのであるが、ここまで短くなると待てない事はないレベルになったような印象を感じる。

しかしながらそれでも、いわゆるクリーンで殆どデバイスが繋がっていないようなクリーンなWindowsと同程度になったというだけの話であり、それほど騒ぐような改善とは言い難い気もする。なぜなら、結局のところサスペンドからの復帰と大差がないので、実運用ではWindows Updateなどで再起動が必要になった時程度と、筆者にとってはそれほど恩恵が受けられないからだ。

アプリケーションの動作に関しても、OSの起動と同じようにフォントやマテリアルなどをブート時に読み込むようなアプリケーションは圧倒的に早くなった。が、やはりこれも筆者の使い方である、アプリケーションは起動しっぱなしで使う。という利用方法からするとそれほど恩恵の受けられるものではない。確かに起動が速いのは嬉しいのではあるが、だからと言って、メモリーが足りないわけでもないのにわざわざアプリケーションを終了する理由が無いのだ。アプリケーションのその他の運用に関しても起動以外で膨大な量のファイルを読み込むような作業というのはあまりに稀であるため、それほど驚くような改善というまでには至っていない。

と、ここまで書いてきて、実運用でそんなに変わらないのか?という印象を与えてしまったかもしれない。しかしそんなことは断じて無い。SSD化における恩恵はOSやアプリケーションの起動という点だけではないのだ。

今回のSSD RAID化において筆者が個人的に感じた一番の利点・改善点は、「様々な細かい動作の軽快さ」である。速度が速くなったというよりは、軽くなったというのが適切な表現だろう。細かな操作の1つ1つにあった微妙なストレスから解消されたというイメージだ。その細かな操作後の反応が極僅か、下手をすれば改善速度が1秒以下というものなのだが、この1秒以下のストレスはPCを長時間試用するにあたり細かいストレスとなって蓄積されていくのだ。この細かなストレスから解放された事で、不思議と羽が生えたかのようにPCの動作が軽くなったと言えるだろう。

具体的には、例えば一番顕著だったのはコントロールパネルを開いた時だ。コントロールパネルはなぜか開くのに時間がかかる。それが一瞬で開き目的のアイコンを選択できるというのは快適の一言だ。これと同様に、フォルダの表示も圧倒的に速い。また理屈は良くわからないが、SSD以外のHDDに保存してあるフォルダの表示なども速くなった。こういった細かなファイル、フォルダ操作のちょっとした引っかかりは積り積って結構なストレスとなる。これが解決された事で、不思議とPCが段違いに速くなった錯覚を起こす。いや、錯覚ではなく実際にSSDにより速くなったのだろう。

これは、Windows 95時代に16MBから128MBへとメモリーを増設した時の体験に良く似ている。現在のユーザーであれば「128MB?たったそれだけ?」と思うかもしれないが、当時はOSやアプリケーションの消費するメモリーは極少量であったために、起動後でも10~20MB程度しか利用していなかったのだ。しかも16MBでは、何か動作をするたびにスワップ発生するのだが、このスワップの発生も、たかだか2~5MB/sec程度のアクセス速度しか無かったHDDにスワップが発生していた事もあり、現在とは比べ物にならないほど遅かったのだ。それが128MBへとアップグレードした事により、スワップが殆ど起こらなくなり圧倒的に劇的に改善されたのだ。これが15年前の話で、これ以降はPCを買い替えても、とにかくメモリーは積めるだけ積むという形で更新してきたため、この時の様に体感的に「PCの動作が軽くなった」と感じた事は無かった。

ここまで劇的なものではないが、PCが非力な時代の総SCSI化というのもPCを軽くする常とう手段であった。今でこそシリアルATAが当たり前であり、SCSIなどコンシューマー用途で使う理由が無い程の状況になってはいるが、10年ほど前位までは、廉価なPCにはパラレルATAが、高速なPCやワークステーションにはSCSIのHDDが使われる事が当然だった。この理由は、パラレルATAでのアクセスにCPUリソースを食われてしまうというのが一番の理由だ。SCSIであれば、SCSIチップ自体が一種のRISCプロセッサであり、殆どCPUリソースを食わずにハードディスクなどの各種デバイスにアクセスする事が可能なため、パラレルATAでのディスクアクセスで発生してしまう「妙な間」が無かったのだ。

今でこそCPUが非常に強力であるので、ATAでの運用でこの様な「妙な間」を感じる事はまずないだろう。しかしながら、当時はSCSIとATAとの間には埋められないほどの大きな溝があったのだ。

この様な背景からHDDメーカーのラインナップはATAのHDDは4500-5400rpm、SCSIのHDDは5400-10000rpmというような状況となっており、実質高いパフォーマンスを発揮させるためにはSCSI化が必須ともいえた。ましてRAID環境自体がSCSIのみで利用されてきたものであり、ATAで利用できるようになったのはごく最近であり、当時はATAのRAIDは信頼性の面から見ても極めて稀な存在であり、実際に運用されている事例もまた極めて稀だったのだ。

と、話は少々ずれてしまったのだが、PCのディスクドライブの総SCSI化というのは、私の中で「大量のメモリーの増設」のカルチャーショックに次ぐものであったのだ。

これ以降はCPUが速くなろうともHDDが速くなろうとも、ランダムアクセスが早くなるわけではないので、PC自体が「軽く」なる事はほとんどなかった。もちろんPCは「速く」なった。しかし「軽く」はならなかったのである。

そこで今回のSSD RAID化だ。15年を超えるPC歴のなかで3回目のカルチャーショックが今回のSSD化だろう。SSD化の凄いところは、「速くなると同時に軽くなる」という点にあると思う。PCの中での最悪のボトルネックが「人間の入力」と「ディスクアクセス」だ。その中でディスクアクセスは、シーケンシャルアクセスが100MBを超えるようなHDDが出てきたため一見速くなったかのように感じるのではあるが、実はシークタイム自体は殆ど変っていないか、下手をすれば遅くなってしまっていたりする。これにより「軽く」動作するための条件はこの十数年変わらなかったのだ。

そこに風穴を開けたのが今回のSSD。時代の流れと共に大容量化したHDD、そして肥大化したアプリケーションからしてみれば、まだまだ容量の問題が取りざたされてはしまうものの、今回の様に、高価なデバイスを追加する事無くRAID0化ができる事で、容量の問題も力技ながら解決する事が出来る。つまり筆者の場合には、今回のRAID化は、速度における恩恵よりも、容量における恩恵の方が大きいと感じている。もちろん速度的なメリットもあると思われるが、それ以上に容量におけるメリットの方が圧倒的に大きいと感じたのだ。

ただ、残念な事に現状ではRAID化にはデメリットが伴っている。それは前述もしたがSSDの最適な書き込み方法ともいえるTRIMに対応していない点だ。

TRIM自体は前述もしたがこちらの「インテル® SSD オプティマイザーとは?」というページが詳しいので参照して欲しい。

TRIMに対応したWindows7でも、RAID化する事により、SSDとして認識してくれず、RAIDコントローラーがRAIDボリュームに対してTRIMコマンドを有効にしていないようだ。このため、書き込み量が増えれば増えるほど、本来そのSSDがもつ最大のパフォーマンスを維持し続ける事ができなくなってしまう。実運用から1週間、2週間後にベンチマークをとってみた。その結果がこちらだ。
運用開始
運用開始
1週間経過
1週間経過
2週間経過
2週間経過
1ヵ月経過
1ヵ月経過

この結果を見るとわかると思うが、アクセス速度が段階的に落ちてきているのがわかる。ハードディスク的に言えば断片化が起き、その為に速度低下がおきているイメージだ。SSDの場合は断片化による速度低下は殆どないので違う状況が起きて速度が低下しているのだが、これがTRIMが有効である場合にはここまで速度が落ちる事は無いのだ。

つまり、単体で利用していれば起きるはずの無い速度低下がRAIDでの運用時には如実に速度低下が現れると言う事になる。これはもうintelなりRAIDチップベンダーにお願いするしかないのだが、とにかく1日でも早くRAIDに対応したTRIMツールを開発して欲しい。
SSD ToolboxでもRAIDドライブはサポートされない
SSD ToolboxでもRAIDドライブはサポートされない



しかしながら、速度低下が起きたところで、HDDよりも圧倒的に高速である事は揺るぎのない事実であり、HDDで運用していた時の様な細かなストレスが片っ端から無くなっている状態は殆ど変わらない。つまり筆者の利用方法では速度低下による体感できるような差は感じられないのだ。

しかしながら、速度低下が起きているのと、そうでないのとでは精神的な面で差が出てくるように思うし、こういったレビューで「RAIDで使っていると速度低下が起きる」というような文字が、あたかも「RAIDで使うと遅くなる」というような受け取られ方をされないとも限らない。その為にも各ベンダーの皆様には、早期の対応を願いたい。

------------------------------------------------------------------------
※)2010年8月26日追記
※)2010年8月26日追記
RAID0を構築し、1か月ほど利用した状態で、速度が落ちたりしていないかをチェックしてみた。その結果がこれだ。
HD Tune、Crystal Disc Markともにパフォーマンスが落ちていることが読み取れる。そこで、一度RAIDアレイを解体し、Trimをかけたうえで再び再構築してみることにした。

その方法は簡単で、筆者はSeagateのHDDをよく利用している為、RAID0で利用しているSSDのシステムデータを、バックアップ用に使っているSeagateの500GBのHDDにSeagateのDiskwizardを使ってシステムデータをバックアップした。
その後、このシステムを転送したHDDより起動し、SSDで構築したRAIDアレイを解体、その後単体のドライブとして認識させ、intel SSD TOOLBOXを利用してTrimをし、再度RAIDアレイを構築して、システムデータを書き戻すという手順だ。

実際に行ってみると、特に問題が起きることなく進んでいき、SSDのRAIDを解除し単体のドライブとして接続、SSD ToolboxでTrimをかけようとしたところ、パーティションが無ければTrimができないというようなエラーメッセージが…。なるほど、ファイルシステムがわからなければTrimは不可能という事か。

そのご、Windows Vista付属の管理ツールからNTFSでファイルシステムを作成、クイックフォーマット後にSSD Toolboxを起動。そしてTrimを実行したところ…1秒かからずに終了してしまった…。おいおい?大丈夫なのかこれは?と心配するほどあっというまなのだ…。

ということで実際にチェックしてみると…
Trim前
Trim前
Trim後
Trim後
見事にパフォーマンスが戻った!よしよし。ここでCrystal Disk infoを使って、このSSDに各々どれくらい書き込みがあったのかをチェックしてみた。
506.41GBと526.49GBと、おおよそ160GBという容量の3倍強の書き込み量という結果であった。電源投入回数が異常な数値になっているのは少々気になるものの、ベンチマークを利用したりした1か月間での書き込み量がこの程度なのであるから、各セルが1万回の書き込みという寿命の最低ラインすらまだまだ当分先という事だ。とりあえず一安心である。

さて、Trimが終わったところで、再びRAID0を構成したいと思う。今回はせっかくなのでWindows上から実行してみた。
と、こういった手順だ。非常に簡単に組めたのだが…

なぜかデータストライプサイズを16KB以外に設定しても、問答無用で16KBに設定されてしまうというバグが存在するようで、今回はIntel in Akiba 2010 SummerでSSD-RAID 0構成時の注意点として64KB以上にすることというアナウンスがあったため、64KB、もしくは128KBで構成しようとしたのだが、Windows上からは残念ながら64KBおよび、128KBで設定することはできなく、結局のところBIOSでRAID0を構築設定せざるを得なかった。
なぜか16KBとなる
なぜか16KBとなる

RAID0の構築の際に、これまたIntel in Akiba 2010 SummerでSSD-RAID 0構成時でのTIPSとして上がっていた、

●RAIDボリューム構成時はTrim対応していません。  なのでTrimの代わりに"over-provisioning"としてスペア領域を持たせておくといいでしょう。

というアナウンスを実践すべく、RAID0での160+160=320GB中、250GBを領域確保し、残りの70GBをスペア領域として持たせてみた。これにより、パフォーマンスダウンが抑制されるという事なので、これもまた後日、検証してみたいと思う。

さて、RAIDアレイを構築し実際にパフォーマンスが回復したかどうかをチェック。今回は64KBのストライプサイズでアレイを組んだので、前回とどれくらいの差があるのかも見てみた。
ストライプサイズ64KB
ストライプサイズ64KB
ストライプサイズ32KB
ストライプサイズ32KB

シーケンシャルリードでは結構速くなったものの、ランダムリード・ライトではパフォーマンスダウンとなった。が、その差は数パーセントなので、体感的な違いが出てくることはないだろう。

最後にTrim、スペア領域を作成した状態でのHD Tuneでの結果を掲載したい。
こちらの結果は、システムを戻していない状態だ。綺麗にフラットな状態となり、パフォーマンスが改善していることがわかる。
こちらはシステムを書き戻したときのディスクの状態。
そしてこちらがシステムを書き戻した後にHD Tuneを実行した時の結果だ。システムやデータが書き込まれた部分がきれいに速度が落ちた状態で、何も書き込まれていないところの速度との差がよくわかる。


RAIDでの運用に関しては、基本的にそのままではTrimが不可能ではあるが、このように、それほど難しい手順ではなく、バックアップを取りRAIDアレイを解体すればTrimをかけ本来のパフォーマンスに戻すことができる。バックアップをとる機会があれば、その時に一緒にTrimをかけてしまえばパフォーマンスも戻り、一石二鳥になるのではないだろうか?

最後に、更にここからおおよそ2か月ほど使った状態のHD Tune及び、Crysital Disk Markの結果を紹介したい。まずはHD Tuneの結果であるが、Trimを実行した直後とほとんど変わらないようなグラフとなった。
次にCrystalDiskMarkの結果であるが…
ストライプサイズ64KB化、20%スペアエリア確保、Trim後アレイ組み直しシステム転送直後
ストライプサイズ64KB化、20%スペアエリア確保、Trim後アレイ組み直しシステム転送直後
ストライプサイズ64KB化、20%スペアエリア確保、2か月運用
ストライプサイズ64KB化、20%スペアエリア確保、2か月運用
参考:スペアエリア無しで1か月運用後の結果(ストライプサイズ32KB)
参考:スペアエリア無しで1か月運用後の結果(ストライプサイズ32KB)
上がシステムを書き戻しそのシステムから起動した状態のベンチマークの結果、中央が64KB+20%のスペア領域を確保したSSD RAID0、その2か月後の結果なのだが、20%ものスペアエリアを投資した割には、ガッツリパフォーマンスが落ちていることが読み取れる。この結果をかんがみるに、スペアエリアの確保に関しては、私の場合、それほど効果は高くないように思える。おまじないとしては有効ではあるものの、その貴重な容量を潰してまでも投資する理由があるのかという点では疑問符が残る結果となってしまった。しかしながら、シーケンシャルライトのみは、そのパフォーマンスを維持している為、全く効果が無いというわけではなく、シーケンシャルライトのパフォーマンスは落ちない為、シーケンシャルライトを優先するユーザーの場合にはスペアエリアを設けた方がよいのかもしれない。
------------------------------------------------------------------------
さて、SSDをRAIDで運用するのに関連したTIPSをいくつか紹介したいと思う。

前述したとおり、SSDに対応したWindows7でもRAID化することで、本来SSDを接続した時に無効となる機能である自動デフラグやSuperfetch、Prefetchなどが無効とされない。もちろんSSDに未対応なWindows Vistaであれば、RAID化しないでSSDを運用した場合も同様だ。これらの機能はSSDの寿命に関連する総書き込み量を減らすための施策であり、パフォーマンスに関わるところではない。しかしながら物理的な寿命と密接に関連しているため、できるだけSSD向けの設定を施しておいた方がよいだろう。

自動デフラグの無効化。SSDにとってデフラグは実行する事でパフォーマンスが上がるわけでもなければ、寿命が縮まるという百害あって一利なしとも言える存在なため、絶対に無効にするべきだろう。筆者は標準のデフラグツールを使っていない(使っていないどころかアンインストールしてしまった)為、スクリーンショットを出す事が出来ないが、スタート・アクセサリ・システムツール・ディスクデフラグツールを選択し、ボリュームの選択を実行し、SSDドライブのみを無効とする事で、SSDに対しては自動デフラグを無効にし、HDDには有効にするなどの柔軟な対応ができるようになる。

読み込み順の最適化を施すPrefetchだが、ランダムアクセスの早いSSDではそれほど意味が無いので筆者は無効とした。無効にする方法はレジストリエディタにて

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

EnablePrefetcher=dword:0

とdwordを0に変更する。ちなみにdwordは1の場合にアプリケーション起動のPrefetchが有効、2の場合はシステム起動のPrefetchが有効、3の場合はアプリケーション起動、システム起動の両方を有効となる。

先読みを行い空きメモリにディスクの先読みを行うSuperFetchもPrefetchと同様に意味が無い為無効とした。

\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

EnableSuperfetch=dword:0

こちらのdwordも0,1,2,3でPrefetchとほぼ同様の内容だ。

なお、これでも止まらない場合にはSuperfetchサービス自体を止めてしまい、スタートアップでの自動起動を無効とすることで対処できるはずだ。


NTFSはファイルの読み込みだけでも、そのファイルに最後にアクセスしたのがいつであるかを記録してしまう仕様となっているため、この機能を無効にする。

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥FileSystem

NtfsDisableLastAccessUpdate=dword:1

0が有効で1が無効なので間違えそうになってしまうがdwordを1とする事で無効となる。

Windowsの各種イベントログをSSDではなく、ハードディスクドライブに移動する。
イベントログを表示し、ウィンドウ右にあるプロパティを選択。
プロパティを開くと保存先のパスが表示されるので、そのパスを変更する事で各種イベントログの保存先を変更する事が出来る。

デスクトップの移動もおこなった。Windows Vista/7であれば、ユーザーフォルダの中のDesktopフォルダを右クリックし、プロパティを表示させると「場所」というタブがでてくるので、移動先のフォルダパスを記入し移動ボタンを押す事でファイルの移動も同時に行える。


デスクトップと同様にマイドキュメントも移動した。また、マイドキュメントと同様の方法で、ミュージックやビデオ、ピクチャ、リンク、検索、保存したゲームフォルダなども移動できる。


割と不評を良く聞くインデックスサービスであるが、個人的には非常によく利用しているため、無効とするのではなく、これもインデックスが保存されるフォルダを移動させた。

コントロールパネルのインデックスのオプションを開き、詳細設定ボタンを押し、その後表示される詳細オプションに新しい場所としてHDDなど他のドライブを指定する事でインデックスが保存されるフォルダが変更できる。


仮想メモリ(スワップファイル・ページングファイル)をSSD以外のドライブに退避させる。仮想メモリーはメモリーが十分に搭載されているPCであったとしても意外と頻繁に読み書きが行われている。そこでこのスワップファイル・ページングファイルをHDDなど他のドライブに移動する。十分にメモリーが搭載されている場合、仮想メモリを無効とする事も可能ではあるが、アプリケーションによっては仮想メモリーが存在していない場合に正常に動作しないものもあるので、HDDなどにスワップファイルを作っておいた方がいいだろう。

設定方法はシステムのプロパティから詳細設定タブを選択し、パフォーマンス欄の設定(S)を押す。
その後、パフォーマンスオプションから詳細設定を選択し、仮想メモリー欄の変更(C)ボタンを押し、SSDのドライブにあたるドライブレターのページングファイルをなしに設定し、HDDなどにページングファイルを作成されるようにする。


テンポラリフォルダを移動する。ただ、環境やアプリケーションによってSSDの寿命よりパフォーマンスを望む場合にはテンポラリフォルダはSSDのままにしていおたほうがいいだろう。筆者の場合は、それほどテンポラリフォルダを利用しない(個別に設定されるアプリケーションを利用している)、またRAMドライブを利用している為、テンポラリフォルダの移動を行った。

移動方法は、スワップファイルと同様に、システムのプロパティから詳細設定タブを選択し、下にある環境変数(N)ボタンを押す。その後表示されるTEMPとTMPの変数の値をHDDやRAMドライブなどSSD以外のフォルダを指定するといいだろう。
注意すべき点として、ユーザー環境変数のTEMP/TMPの他に、下のシステム環境変数にもTEMP/TMPが用意されているのでそちらも一緒に変更しておいた方がいいだろう。

SSDのみと言うわけではないがRAMディスク(RAMドライブ)を活用する事でSSDの寿命を延命するだけでなくパフォーマンスも改善できるので紹介したい。RAMDISKドライバ・ソフトウェアは、現在フリーウェアや商用ドライバを含めかなりの数がリリースされており、もし、メインメモリーを大量に搭載しているのであれば試してみてもらいたい。

RAMディスクは、RAID化したSSDと比べても更に速い。しかも基本的に読み書きによる寿命も無い為、前述した仮想メモリー(スワップファイル、ページングファイル)や、テンポラリフォルダをRAMディスクに指定する事でパフォーマンスが改善する。以下のベンチマーク結果はRAMディスクのパフォーマンスである。この数値を見ればどれだけ速いのかは一目瞭然だろう。頻繁に読み書きが行われ、ファイルの保存が必要ではない場合には是非とも活用したい機能の1つである。


前述したテンポラリファイルや仮想メモリー・ページファイル、各種ログファイルなどは、設定により移動する事が出来た。しかし、アプリケーションによってはインストールフォルダや指定フォルダにのみこういったテンポラリデータを保存し、その保存先を移動できない事がある。そんなときはシンボリックリンクを活用するといいだろう。

シンボリックリンクは、便利なショートカットともいえる存在で、ショートカットではアプリケーションからは"ショートカットファイル"としてしか認識ができないが、シンボリックリンクであればアプリケーションからリンク先を"フォルダ"や"ファイル"として認識できるため、頻繁に書き換えられるファイルなどを、このシンボリックリンクを利用して、RAMディスクやハードディスクに退避させる事でSSDの寿命を延ばす事ができる。
作成方法だが、スタートボタンのプログラム、アクセサリからコマンドプロンプトを右クリックし、管理者として実行をクリックして起動する。そして上記画像の例であれば、C:\にLINKというフォルダ(ディレクトリ)のシンボリックリンクを作成しW:\LINKにリンクさせるという方法だ。

/Dが付いているのはフォルダ(ディレクトリ)としてリンクさせたい場合に利用し、例えばファイルに直接リンクさせたい場合得あれば、

C:\>mklink log.txt W:\log.txt

等の様な形で実行する事でlog.txtへ直接リンクが張られる事になる。

なお、リンク先は先に用意しておかなければならないので注意して欲しい。リンクの解除は、エクスプローラからシンボリックリンク(ショートカットと同じアイコン)を直接削除すればいいだけだ。

このシンボリックリンクを作成するためにはWindows Vista以降、そしてシンボリックリンクを作るリンク元がNTFSでフォーマットされている事が条件となる。

デスクトップPCでハイバネーションを利用しているユーザーはかなり少ないのではないだろうか?確かにサスペンドトゥラムより安心ではあるものの、このハイバネーションに必要なハイバネーションファイル(hyberfil.sys)はブートドライブのルートにしか作成する事ができず、他のドライブに移動する事が出来ない。そのため、ハイバネーションを利用しないのであれば、メモリー搭載量を丸々書き込んでしまうハイバネーション自体を無効にしてしまったほうがいいだろう。

無効とするためには、スタートボタンからアクセサリ内にあるコマンドプロンプトを右クリックをし、管理者として実行を選択してコマンドプロンプトを起動させる。その後、起動したコマンドプロンプトの中で

powercfg.exe /hibernate off

としてエンターキーを押す事でhyberfil.sysが削除されるとともに、ハイバネーションが無効となる。もし、ハイバネーションを有効にしたい場合には同様の手順で

powercfg.exe /hibernate on

とするだけで元に戻せる。また、現在の状態を確認する時には

powercfg.exe /a

とすることで、現在ハイバネーション(休止状態・ハイブリッドスリープ)が有効であるか無効であるかが確認できる。


2週間超ほどSSD 160GB x2 RAID0を利用してきての総評だ。総評とはいっても、まだたったの2週間しか利用できていない点を踏まえて欲しい。

とにかく今回の体験レビューでは、もうHDDには戻れない快適さが手に入ったというのが一番の目玉だろう。しかしRAID化に関してはメリット・デメリットをよく考えて導入すべきだ。筆者の様に容量に問題を抱えていない場合には、TRIMが有効でかつ、特に設定をいじらずとも、自動的にSSD向けの設定が施されるWindows7を利用するのであれば、単体で利用する方が使い勝手がいいという場合も大いにあると思われる。

単体であればOSにWindows7を利用している場合であれば、誰にでも進められる素晴らしきアップグレードパスであるが、RAID化に関しては、少々複雑で煩雑な設定を行わなければならず、誰にでもおいそれとすすめる事はできない。しかしながら、もしこれらを乗り越える事が出来るユーザーであれば、RAID0化することで、SSDの最大の懸念事項である寿命の延命も可能となる為、オススメできる。



付録として、ファームウェアのアップデートを行ったのでそれに関する内容を記載したいと思う。今回送付されてきたSSDのファームウェアは最新ではなく1つ前の2CV102HAだった。現在は2CV102HDが公開されており、アップデートをする事にした。以下はその時の動画である。

ファームウェアのアップデートは正常動作している時には基本的にアップデートする理由は殆どの場合無いのではあるが、SSDという発展途上のデバイスの場合は、最新のファームウェアの方が様々な改善点が施されている場合が多く、自己責任の上でおこなえる人であれば、アップデートしておいた方がいいだろう。

ファームウェアアップデートは、intelのサイト内のIntel® SATA SSD (ソリッド・ステート・ドライブ) ファームウェア・アップデート・ツールからダウンロードする事が可能だ。ダウンロードできるファイルはCDイメージファイルとなっており、isoイメージをCDに焼き、CDから起動させる事で実行が可能だ。

この時に、マザーボードのBIOSの設定を、RAID/AHCIではなくIDEに設定しておくことが必要となるので忘れないでIDEに設定しなおしてから実行しよう。

CDから起動した後は非常に簡単で、注意警告文を読んだかどうかを聞かれ、Yキーを、本当に書き込むかどうかを聞かれるので、再びYキーを押すだけだ。書き込む時間は非常に短いので焦らず確実に実行したい。どれくらいの時間がかかるのかは動画の方を見てもらえばわかるはずだ。2台接続されていれば、この確認と書き込みが台数分繰り返し行われる。動画は2台のSSDのファームウェアをアップデートしたものである。

余談ではあるが、ファームウェアのアップデートを行う前に組んでいたRAIDアレイだが、ファームウェアのアップデートを行った後でもそのままRAIDアレイとして利用する事が出来た。できればRAIDアレイは作りなおした方がいいとは思うものの、オススメはできないし、筆者は何の責任も持てないが、RAIDアレイを維持したままでもファームウェアのアップデートは今回の2CV102HAから2CV102HDへのアップデートの場合は可能なようだ。



------------------------------------------------------------------------
2010/6/21追記)
Intel in Akiba 2010 SummerにてSSD-RAID 0構成での注意点がアナウンスされました

●RAID0 ストライプサイズは、64KB以上を選ぶ

●Write Back ChaceをONにすると性能が向上するが、反面リスクもあります
 - 瞬断とか何かあった時は・・・気をつけてくださいね

●RAIDボリューム構成時はTrim対応していません。  なのでTrimの代わりに"over-provisioning"としてスペア領域を持たせておくといいでしょう。

●スペア領域のとしては、RAIDボリューム設定時のドライブサイズをちょっと小さめにして設定するのがいいでしょう。
 (各ドライブであきエリアを持たせるのではなく・・)
------------------------------------------------------------------------
※筆者注 "over-provisioning"とは日本語に訳すと過剰投資となるが、SSDの場合に"over-provisioning"という言葉は予備領域(スペアエリア)を意味する。つまり160GBのうちの何パーセントかを予備領域として確保しておくことで、パフォーマンスの低下やランダムライトに対する寿命の延命という効果が得らるため、Trimが対応しないRAID構成の場合には多めに予備領域を取った方がいいだろうとの見解なのだと思われる。参考までにIntelのSSDの場合、X25-Eなどのエンタープライズ製品で27%、今回レビューをしているX25-MなどのMLC製品では7%の予備領域が標準で確保されているとのことだ。

予備領域7%の耐久性を1とし、予備領域を27%とすることで、耐久性が7%時に比べ、おおよそ3.5倍になるとの事。
参考)「神様」が980XとSSDを解説、「もっと他社がんばれ」とエール

予備領域を確保するには、一般的にはATA Secure Erace後に、パーティションを切り、未使用領域を残しておけば良い。MHHD(HDGURU)やHDAT2でHPA(Hidden Protected Area)を設定する事で、OS上から完全に隠すことも可能だが、Windowsのみで利用する場合などであれば使用するパーティションを実容量の80%に設定し、残りの20%を放置しておくだけで、見えない7%と使わない20%の合わせて27%が予備領域として使用され、おおよそ3.5倍の耐久性が得られる可能性がある。また今回の様にRAID-0の場合には、Secure Erace後に160x2=320GBの中から80%程度をRAID-0領域としてビルドし、残りのサイズを放置しておいても同様の効果が得られるはずだ。寿命・耐久性を気にする人で、容量的に不満が無いのであれば、より多くの容量を予備領域として確保しておく事で、より長寿命となるだろう。ただし、予備領域を設定するためには、必ず予備領域を確保する前にATA Secure Eraceを実行してからにしよう。これを実行しないと予備領域の意味が無くなってしまう。(最大容量を確保し、空のパーティションを作成した上でIntel SSD Toolboxを使うことで同様の効果を得られるのかは不明。理論上は同様の効果が得られるはずではあるが、マスターファイルテーブル(MFT)の予備領域等が後方に記述されるなどの可能性も否定できない為、Secure Eraceを実行した方が確実だろう。)
------------------------------------------------------------------------
レビュー記事変更履歴

6/21 実運用1か月のベンチマーク結果とIntel in Akiba 2010 SummerでアナウンスされたSSD-RAID 0構成での注意点を記載
8/26 実運用2か月~4か月での状況とRAIDアレイを解体してのTrimなどを追記
12/29 現在のベンチ結果を掲載
2010/12/29
2010/12/29

2/28現在のベンチ結果を掲載
ファームウェアv1.7 02M3にアップデート
ファームウェアv1.7 02M3にアップデート

コメント (45)

他42件のコメントを表示

ZIGSOWにログインするとコメントやこのアイテムを持っているユーザー全員に質問できます。

YouTube の動画を挿入

YouTube の URL または動画の ID を入力してください

動画の ID が取得できません。ID もしくは URL を正しく入力してください。

ニコニコ動画の動画を挿入

ニコニコ動画の URL または動画の ID を入力してください

動画の ID が取得できません。ID もしくは URL を正しく入力してください。

ZIGSOWリンク挿入

検索対象とキーワードを入力してください

    外部リンクを挿入

    リンク先の URL とタイトルを入力してください

    URL を正しく入力してください。

    画像を挿入(最大サイズ6MB)

    画像を選択してください

    ファイルサイズが6MBを超えています

    別の画像を追加

    ZIGSOW にログイン

    ZIGSOW会員登録(無料)はこちらから