(1)IndilinxコントローラのSMARTについて
IndilinxコントローラのSMARTについて
テスト本番の前に、なぜIndilinx製コントローラ搭載製品を選んだのか、それによって何が分かると期待できるのか、という点についてまとめておきます。
Indilinx BarefootコントローラのSMARTの仕様は、Transcend社のデータシートに掲載されています。厳密には、今回のテストで使おうとしているOCZ OnyxシリーズはAmigosというコントローラを搭載しているのですが、BarefootとAmigosは同じIndilinx社製であり、取得できるSMARTの項目が一致している上、変な値にもなっていないので、まず間違いなくSMARTの仕様は同一であると考えられます。
耐久テストを行うにあたり、SSDの内部状態が観測できるという利点は非常に重要です。もしSMARTが全く利用できなければ、SSDが故障したときに内部で何が起こっていたかを推測するのは困難になります。これから解説するように、Indilinx社製コントローラのSMARTからは、非常に詳細な情報を読み取ることができ、内部状態を詳しく知ることができます。
上図は、今回のテストに用いるOCZSSD2-1ONYX32GをJSMonitorで表示したもので、重要な項目を四角で囲っておきました。以下、色別に内容を解説しておきます。"Total Sectors Read with CBE"などです。各項目にマウスカーソルを合わせるとツールチップが表示されますが、その中では省略していない名称を表示しています。">*1
- NANDの消去回数
赤の四角で囲った値は、NANDフラッシュの最大・最小・平均消去回数です。これらの値から、NANDへの書き込み量の総量や、ウェアレベリングがどれだけ正しく機能しているかを推定することができます。
- 不良ブロック関連
青の四角で囲った値は、主に不良ブロックに関する情報です。Initial Bad Blockは、製造時の問題などにより、先天的に破損していたブロックの数を表していると考えられます。一方、Program/Erase/Read Failure Block Countは、書き込み・消去・読み込み時のそれぞれの動作に失敗したブロック数を表し、おそらくこれらの動作失敗が発生したブロックは無効化されると思われます。データシートには、"Read Failure Block Count(Uncorrectable Bit Errors)"と書かれているので、"Read Failure"とは、ECCを用いても修正しきれなかったエラーが発生したことを示すようです。
- RBER(Raw Bit Error Rate)
緑で囲った値から、今回のテストのキモとなるRBER(Raw Bit Error Rate)という値を計算することができます。RBERについては以前の記事でも紹介していますが、この値はビットエラーの頻度を表し、NANDが消耗してくると値が大きくなってきます。
RBERの計算方法は、"ECC使用前のビットエラー発生数÷総読み込みビット数"とするだけです。IndilinxコントローラのSMARTからは、"(Total Error Bits Count)/(Total Sectors Read*4096)"で計算することができます。4096を掛けるのは、1セクタが4096ビットからなるためです。上記のスクリーンショットの状態からRBERを計算すると、36,951/(160,699,137*4096)=5.61E-8となります。
なお、スクリーンショット中に"Read Error Rate"の項目がありますが、この値はおそらくRBERを四捨五入(または切り上げ)した値の指数を表示していると思われます。前述した通り、計算から求めたRBERは5.61E-8なので、これを四捨五入すると1.0E-7になります。スクリーンショット中の"Read Error Rate"の値は7なので、一致しています。同様に、現在システムドライブとして用いているK5-64では、Total Error Bits Count=13,243、Total Sectors Read=4,314,373,168となっているので、そこからRBERを計算すると7.50E-10となり、四捨五入すると1.0E-9となります。このK5-64の"Read Error Rate"の値は9なので、やはり計算は合っているようです。
RBERが重要な指標である理由は2点あります。1点目はNANDフラッシュそのものの特性を知ることができるという点、2点目は統計学的な意味におけるサンプル数を増やすことができる点です。
まず1点目について。SSDの主要な部品はコントローラ(+外部DRAM)とNANDフラッシュの2点であり、通常外部から観測できるのは、この2点によって構成された複合的な状態です。しかし、RBERはコントローラから切り離されたNANDフラッシュの状態を示す指標です。すなわち、平均消去回数に応じたRBERの値を計測すれば、その結果は同一の型番、乃至は同一のファミリーのNANDフラッシュを搭載している他のSSDの内部状態を推測する上で役に立つ可能性があります*2。今回のテストに用いるOCZSSD2-1ONYX32GはIntel製の29F32G08AAMDBというNANDを使用していますが、前回の記事で述べた通り、同一のNANDがS596 Turboの64GB版にも使われています。また、IntelのSSDも、容量は異なりますが、これと同じファミリーのNANDを搭載しています。
そういう意味では、他社のNANDを搭載したSSDとRBERの比較を行ってみるというのは面白そうです。SuperTalentのFTM32G225H(UltraDrive GX2シリーズ)はBarefoot ECOコントローラに東芝の34nmNANDの組み合わせで容量32GBなので、比較対象としてはピッタリなのですが、どうやらもう製造中止で店舗でもほぼ売り切れのようです。どこかに売っているのを見かけたら教えてください。最近はドルが安いから海外通販もありかな…?
次に2点目についてです。今回のテストは、主に経済的な理由により、使用するSSDは1台か、あるいは買い足したとしてもせいぜい2,3台の予定です。統計学的見地からは、サンプル数が1とか2のテストはほとんど意味を持ちません。詳細は次回の記事で紹介する予定ですが、JEDECの制定した"Solid-State Drive (SSD) Requirements and Endurance Test Method"では、最低でも31台のSSDをテストに用いることが要求されています。
しかし、RBERの場合は、サンプル数はSSDに搭載されているNANDのビット数となるので、一挙にサンプル数が増えることになり、統計学的に有意な値となることが期待できます。もっとも、搭載されているNANDのロットは全て同一でしょうから、無作為抽出ができているとは言えません。もしかすると、CPUのOC耐性のように、NANDにも耐久性が有意に高い、あるいは低いロットが存在するかもしれません。実際、前述のJEDECの評価指標でも、連続していない3つ以上のロットの製品をテストに用いるように指定されています。しかしまあ、流石にロット違いで耐久性に5倍とか10倍の差がでることはないだろう、ということでここは大目に見てください。
- その他
その他のSMART値として興味深いのは、"Total Sectors Read with CBE(Correctable Bit Error)"です。これは、読み込み時にECCによって訂正可能なエラーが生じた"セクタ数"を表すと思われます。もしこの値がTotal Error Bits Countに比べ著しく小さければエラービットが局在しており、逆にTotal Error Bits Countとそれほど値が変わらなければエラービットが遍在していると考えられます。前者の場合、エラービットの多いブロックを無効化すればSSDはより長く使えるでしょうが、後者の場合は寿命が近づくと立て続けに不良ブロックが増え、あっという間に予備領域が使い果たされる、といった現象が生じるかもしれません。
さらに、"Bad Block Full Flag"も興味深いところです。字義通りに解釈すると、不良ブロックが一杯になったときにこのフラグが立つということでしょうから、無効化されたブロックが増え、予備領域が使い果たされた場合にこの値が1になると期待できます。予備領域が無くなると、原理上SSDに対する書き込みはできなくなってしまうので、この値が1になったときにSSDがリードオンリーモードになるのではないかと個人的には予想しています。なお、今のところこの値が更新された例は見たことがありません。
というわけで、あまりに長くなってきたので続きは次回に回します。
OCZ OCZSSD2-1ONYX32G(Onyxシリーズ)の殻割り&ベンチマーク
結局今週末はサボってしまったので、まだ耐久テスト用のプログラムは作ってません…
まあ、拙速なのもどうかと思うので、先に何を調べたいのかについてまとめたエントリを書く予定です。ご意見・ご要望も絶賛受付中です。
というわけで、今回は誤魔化しのために殻割り画像と適当なベンチマーク結果を乗せておきます。
OCZSSD2-1ONYX32G 内部構造
NANDフラッシュは、Intelの(JS)29F32G08AAMDB(4GiB)が8枚搭載されています。エルミタージュ秋葉原のの記事によると、JMF616搭載のS596 Turboの64GB版にも同じNANDが載っているようです。
ちなみに、X-25M G2の160GB版のNANDは29F16B08JAMD1(16GiB)、X-25M G2の80GB版及びX-25Vの40GB版は29F64G08CAMD1(8GiB)を搭載しているので、型違いです。
見ての通り、基板は片面実装です。コスト削減ですね。
ベンチマーク結果
- HD Tune Read Test (Full Test)
- HD Tune Write Test (Full Test)
- HD Tune Random Read Test
- HD Tune Random Write Test
- CrystalDiskMark 1000MB
例によって、0Fillではスコアが上昇します。HD Tuneの書き込みテストも0Fillなので、CrystalDiskMarkの0Fillの方に近いスコアになっています。
意外とRandom Read 4KBの性能は高めですが、やはり書き込みは遅いですね。55MB/sで書き込みを続けると、Average Erase Countが5000回になるまでに約33.67日、10000回になるまでに67.34日かかる計算になります。実際には読み込みを入れないとビットエラーレートを取得できないので、より長い時間がかかることになります。うーん、先は長いなあ。
東芝SSDの耐久テストとリードオンリーモードについての所感(訂正済み)
お詫びと訂正
昨日の時点では、該当のSSDのファイルシステムが破損したとの前提で記事を書いてしまいましたが、その後Puppy Linuxでドライブをマウントしたところ正常にファイルの読み込みができたとのことです。従って、この記事は前提自体が間違っていました。大変申し訳ありません。
しかも、昨日の時点のこの記事は、ほぼ断定的にファイルシステムの破損原因をデータ保持エラーのせいだと結論していたり、そもそも何か書き方が感じ悪いなど問題が多すぎるので、全面的に書き直させていただきました。あまり見ていただきたくはないんですが、反省を込めて昨日時点の記事の内容をこちらの魚拓に残しておきました。うーん、穴があったら入りたい… プロフィール画像も変えておいたので許してください。
SSDとリードオンリーモード
はじめて引越し近距離を使う人が知っておきたい3つのルールさんで行われていた東芝SSDの耐久テストの結果が出たようです。記事によると、884.8TBの書き込みでSSDに異常が発生したとのことです。当初Windowsではデータを読み込むことができず、ファイルシステムに破損が発生していることが予想されました。しかし、Puppy Linuxを用いたところ、リードオンリーのドライブとして認識することができ、データの復旧ができたということです。
DOS/V Power Reportのこの記事によると、東芝のSSDは、寿命が近づくとリードオンリーモードに移行するとされています。以下に該当部分を引用します。
寿命に関連して、実際に書き換え回数の限界に達したらどうなるのだろうか。「安全のために弊社のSSDは、あらかじめ準備された予備エリアがなくなり、実際に書き込める容量がドライブ公表値を下回る寸前になった場合には、リードオンリーモードに移行するようになっています」(白井氏)とのこと。これで、最悪の場合でもユーザーはそこまでのデータを失うことがない。
今回のBotchyWorldさんの実験結果では、この機能が動作していることが実証されました。
しかし、リードオンリーモードとなったSSDは、CD-Rのようにバックアップメディアとして使える訳ではありません。NANDフラッシュには「データ保持エラー」が存在するためです。NANDフラッシュは、書き込みからしばらく時間が経つとどんどんビットエラー(データ化け)が増えていきます。さらに、多数回の書き込みが行われたNANDでは、新品のNANDに比べ、非常に多くのデータ保持エラーが発生していきます。従って、リードオンリーになった直後は正常にデータを読み込めても、しばらく時間が経った後にもう一度見てみたらデータがほとんど壊れていたといった事態が発生する可能性があります。
以前の記事で紹介した研究では、約1年半の放置でRaw Read Error Rate(読み込み時にエラービットが発生する確率)が約1,000倍に増えるという事例もありました。この研究では63nm〜72nm世代のNANDが使われていますが、昨今の3x〜5xnm世代のNANDはコストと引き替えにビットエラーは発生しやすくなっており、状況はより悪化している可能性が高いです。
従って、もし皆さんの手持ちのSSDがリードオンリーモードになってしまったら、1分1秒でも早く中のデータのバックアップを取りましょう。バックアップを開始するまでの時間が早ければ早いほど、データが失われる可能性は少なくなります。
また、今回のBotchyWorldさんの実験では、Windowsではファイルシステムが破損したように見えたにも関わらず、Linuxでマウントするとデータが読み込めたそうです。これは重要な知見で、Windows上でSSDが壊れてしまったように見えても、あきらめずにLinux系のOSで復旧作業を試す価値があるということです。BotchyWorldさんの実験で用いられたPuppy Linuxや、あるいは定評のあるSystemRescueCDなど、CDやUSBメモリからブートできるLinux系OSを万一に備えて用意しておくといいでしょう。
$Bitmapとは?
上記のBotchyWorldさんの記事では、Windows XPにSSDを接続した際、「$Bitmap」が壊れているというメッセージが表示されています。このメッセージを見たために、僕はファイルシステムが致命的に破損しているものだと思い込んでしまいました。
「$Bitmap」とは、ユーザーが作成するファイルではなく、NTFSのメタデータの一つです。$Bitmapとは何かについて、『インサイドWindows 第4版 (下)』より引用してみます。
NTFSは、ボリュームの割り当て状態を「ビットマップ」ファイル($Bitmap)に記録します。ビットマップファイルのデータ属性ビットそれぞれは、ボリュームのクラスタを記憶し、そのクラスタが空いているかファイルに割り当てられているかを示します。
このように、$Bitmapは非常に重要な領域です。マイクロソフトのサポートページにあるように、たまたま$Bitmapだけに障害が発生した場合であれば、チェックディスクで直ることもあるようです。
余談
BotchyWorldさんの記事を見ていて僕もSSD耐久実験をしたくなってきてしまいました。以前の記事でNANDフラッシュのエラーモードを解析した論文を紹介しましたが、Barefoot搭載SSDであればエラービットの数がSMARTから取得できるので、この論文とほぼ同じテストを行うことができます。単に壊れたか壊れないかの二択ではなく、どれくらい壊れそうかが分かるということですね。
Barefoot搭載SSDといえばVertexの30GB版を持っていますが、これから2xnm世代に移行しようかという時期に50nmのNANDのテストをしても意味なさそうなのと、古いファームウェアのバグでMaximum Erase Countが異常に多くなっている状態なので、これを使うという手はありません。
となると新品で買うしかないですね。候補としては、Corsair Novaシリーズの32GB版(CSSD-V32GB2-BRKT)か、OCZ Onyxシリーズの32GB版(OCZSSD2-1ONX32G)あたりでしょうか。しかし、前者はファームウェアアップデートが公開されていない点が、後者はコントローラが"Indilinx Amigos"という別製品である点が気になります。OCZで公開されているOnyxのファームウェアのバージョンは他のBarefoot搭載製品と同じ1.6になっているので、おそらくBarefootとAmigosでSMARTの仕様は同じだと思うのですが、若干不安です。Onyxの方が値段が安いということもあり、できればOnyxを選びたいものです。
というわけで、もしOCZ OnyxシリーズのSSDをお持ちの方がいらっしゃったら、JSMonitorが動作するか、あるいはCrystalDiskInfoでどのような項目が表示されるかを教えていただければ幸いです。
- 追記
コメント欄にてkobagenさんに情報を頂いたので、早速Onyxを発注してしまいました。週末にプログラムを組んで耐久試験を実行してみようと思います。
はてなブックマーク始めてみました
最近は時間がない+そもそもネタ切れで全く更新がなくて申し訳ありません。
先月末ぐらいからはてなブックマークを始めてみました。はてなブックマークは、オンラインにブックマークを保存・共有することができるサービスで、ブックマークしたページに対するコメントを書くこともできます。Twitterとの連携機能なんかもあります。
というわけで、SSD関連の小ネタは、今後ははてなブックマークに追加していく予定です。
さて、宣伝だけでは何の芸もないので、以下ではちょっと便利なはてなブックマークの使い方を紹介してみます。
注目度の高いWebページを自動的に取得
RSSを用いて、多くのブックマークが付けられているページを自動的に取得することができます。なお、この機能を利用するだけなら、はてなブックマーク自体には登録する必要はありません。
例えば、キーワードに"SSD"が含まれ、5個以上のブックマークが付けられているページを表示するには、以下のページにアクセスします。
http://b.hatena.ne.jp/t/SSD?sort=hot&threshold=5&mode=rss
Firefoxのライブブックマークに上記のページのフィードを登録すると、こんな感じに表示されます。
当然ながら、"SSD"を別の単語にすることもできますし、ブックマーク数の下限を3や10など他の値に変更することも可能です。この機能を用いれば、効率的な情報収集を行うことができます。
Firefoxアドオンで簡単にブックマーク追加&ブックマークコメント閲覧
http://b.hatena.ne.jp/help/firefox_addonを用いれば、現在閲覧中のページをはてなブックマークに登録することができます。また、そのページに付けられたブックマークの数を確認でき、コメントのみを表示することもできます。
これを使うと便利…というより、これなしではあまりはてなブックマークを使う気になれないですね。ちなみに、Google Chrome版もあります。
新世代ハイブリッドHDD Momentus XTシリーズ - 高速化の原理とベンチマーク
SeagateのMomentus XTシリーズは、2.5インチHDDに4GBのSLCフラッシュを搭載した"ハイブリッドHDD"です。このシリーズについてのベンチマークや実環境でのパフォーマンスについては、既に多数のレビューが存在します。とりあえず列挙すると、AnandTech, Tom's Hardware, Tech Report, HDD・SSDとの比較動画といったところです。特に最後の動画で分かるように、OSやアプリケーションの起動時間について、Momentus XTはSSDには劣るもののHDDよりかなり高速になるようです。
しかし、これらのレビューでは、"ハイブリッド"によりどれだけ高速化されるのか、明白なベンチマークスコアは提示されていません。やはり、MB/sで性能表記ができないとなんとなく落ち着きませんよね。(←僕だけ?) というわけで、本日の記事では、"ハイブリッド"による高速化の原理の解説と、Iometerを用いた高速化の効果の測定を行ってみました。使用したのは、500GBモデルの"ST95005620AS"です。
Adaptive Memory Technologyによる高速化の原理
"ハイブリッドHDD"と呼ばれる製品は2,3年前にも数機種が発売されましたが、性能的にいまいちだったこともあり、あっという間にフェードアウトしてしまいました。
これらの第一世代ハイブリッドHDDは、Windows Vista,7の機能である"ReadyDrive"に依存しており、OSが不揮発性キャッシュ(NV Cache, 要するにNANDのこと)を制御します。一方、Momentus XTシリーズは、HDD内部のコントローラがNANDを制御しています(Adaptive Memory Technology)。そのため、Momentus XTであれば、Windows XPでもLinuxでもMac OSでも、NANDによる高速化の恩恵を得ることができます。
そういうわけで、CrystalDiskInfoでMomentus XTの情報を取得すると、ReadyDriveに用いられる"NV キャッシュ"は非搭載と表示されます。
一方、高速化の原理は、Adaptive Memory Technology、ReadyDrive、USBメモリなどを用いるReadyBoostのいずれも同じで、NANDを"読み込みキャッシュ"として用います。すなわち、OSやMomentus XTのコントローラは、読み込みが頻繁に発生するアドレスを調べておき、アイドル中にそれらのデータをHDDからNANDへとコピーしておきます。その後は、該当のアドレスへの読み込み要求が来ると、データはNANDから読み込まれることになり、NANDの高速なランダムリード性能を活かすことができます。NANDに書かれたデータは電源を切っても消えないので、SuperFetchと違って再起動後も使用することができます。
なお、これらの技術で高速化されるのはランダムリードだけで、シーケンシャルリードと書き込み全般は高速化されません。NANDフラッシュは、チップ1枚あたりのシーケンシャルリード・ライト性能はそれほど高くありません。SSDやUSBメモリに使われるNANDの場合、MLCではRead 20MB/s程度、Write 5〜10MB/s程度で、SLCでも読み書き双方が20MB/s程度です。さらに、NANDは本来ランダムライトを非常に苦手としています。従って、シーケンシャルリードと書き込み全般はHDDの方が高性能であり、NANDを利用する必要はありません。
Adaptive Memory Technologyの効果をベンチマーク
以上の原理から、CrystalDiskMarkやAS SSD Benchmarkのようなファイル作成型のベンチマークソフトではAdaptive Memory Technologyの効果を評価できないことが分かります。これらのソフトはベンチマーク用の一時ファイルを作成しますが、そのファイルはHDD上に書き込まれてしまうので、ベンチマークの間NANDは蚊帳の外となってしまいます。
そこで、Iometerを用い、以下のようなテストを行いました。
- パーティションを削除し、物理ドライブへのアクセスモードとする。Maximum Disk Sizeは200,000セクタ(約100MB)とし、Starting Disk Sectorを適宜設定することで、NANDにデータが移動されていない(と思われる)領域でテストを行う
- 十分な時間(今回10分)4KBのシーケンシャルリードを行う
- しばらく放置
- 4KiB〜1MiBのランダムリードを行い、性能を計測する
手順2を行うことでHDDにアクセスを記録させ、手順3の間にNANDフラッシュにデータをコピーしてもらうという寸法です。ちなみに、ランダムリードを連続して何分動作させても高速化しませんでした。放置時間を設けると次のテストは高速化されるので、NANDへのデータコピーはアイドル中に行われているようです。
結果は以下の通りです。"Cached"とあるのが上述の手順の結果で、"Not Cached"とあるのが手順2,3を省いた結果です。Starting Disk Sectorは、Cachedテストでは4,000,000(先頭から約2GBのところ)、Not Cachedテストでは4,200,000(先頭から約2.1GBのところ)としました(色々なテストをしているうちにだんだん後ろに来てしまいました)。
どうでもいいですが、Gnuplotできれいな棒グラフを書くTipsに感動したので、今回の結果はそれを用いた図にしてみました。凡例もこのグラデーション付きで書けないかなあ?
512Kまでは"Cached"の方が早いですが、768Kで追いつかれます。NANDによる高速化の恩恵は、512KBくらいまで受けられるということでしょう。一方、"Cached"の4Kの結果は5.23MB/sとなっており、SSDの4〜5分の1程度のスコアでした。
個人的な予想では、高速化の恩恵が受けられるのはせいぜい32KBか64KBぐらいまでだろうと思っていました。前述した通り、SLCタイプのNANDフラッシュの読み込み性能は一般的に1チップで20MB/s程度で、Momentus XTにはチップが1枚しか搭載されていないためです。ところが、結果を見ると256KB以上では60MB/s近い速度が出ており、かなり高速なチップが採用されているようです。*1
結論
以上のテストから、Adaptive Memory Technologyの効果を計測することができました。4Kのランダムリードで5MB/sを超える結果が出ており、これは一般的な2.5インチHDDの10倍ものパフォーマンスです。また、128K,256Kといった比較的大きなサイズの読み込みに対してもAdaptive Memory Technologyは有効に働いています。
しかし、このスコアではSSDの速度には太刀打ちできず、"SSD>ハイブリッドHDD>HDD"という序列がはっきりしてしまいました。やはり、Momentus XTは、「どうしても250GB以上の大容量が欲しいが、その容量のSSDを買うほど予算が無い」というノートPCユーザ向けの製品と言えそうです。
*1:Tech Reportの記事では、Momentus XTに使われているNANDの速度はRead 140MB/s、Write 100MB/sとされています。にわかには信じがたいのですが、それほど高速にできるものなんでしょうか…?
"MimicXLS"でRealSSD C300の性能向上&RealSSD C300のSMART解析
RealSSD C300における小サイズランダムライト性能
前回の記事で述べたように、RealSSD C300はパーティションアラインメントが調整されていない場合に大きくランダムライト性能が下がります。また、こだわりのMONOさんの記事にあるように、AS SSD Benchmarkを実行すると、Writeの"Acc.Time"が低スコアになります。この項目は512バイトのランダムライトにかかる時間の平均値であり、0.8msということは1250IOPS(0.625MB/s)でしかありません。同じテストにおいて4KBのランダムライトは29.62MB/sなので、これは不自然に低い値です。
これらの現象は、RealSSD C300が4KiB未満の書き込みを不得意としているために発生するのではないかと推測されます。そこで、Iometerを用い、512B, 1KiB, 2KiB, 4KiBのランダムライトのテストを行ってみました。さらに、下図のように、Iometerには書き込みアドレスをアラインするための項目があるので、"Sector Boundaries"(デフォルト)の場合と、4KiB境界にアラインした場合の両方のベンチマークを取りました。
比較対象としてOCZ Vertexシリーズの30GB版、さらにおまけで前回取り上げたWD20EARSの結果を乗せています。各テスト時間は10秒、テスト領域は1000MBとしています。また、結果の単位はIOPSです。
Test | RealSSD C300 | Vertex 30GB | WD20EARS | ||||
512B(not aligned) | 1272.3 (0.62MB/s) | 2464.7 (1.20MB/s) | 70.1 (0.03MB/s) | ||||
1KiB(not aligned) | 1452.5 (1.42MB/s) | 2395.2 (2.34MB/s) | 68.3 (0.07MB/s) | ||||
2KiB(not aligned) | 1642.0 (3.21MB/s) | 2191.4 (4.28MB/s) | 60.4 (0.12MB/s) | ||||
4KiB(not aligned) | 1801.7 (7.04MB/s) | 1950.6 (7.62MB/s) | 63.9 (0.25MB/s) | ||||
512B(4KiB aligned) | 1283.3 (0.63MB/s) | 2396.4 (1.17MB/s) | 64.4 (0.03MB/s) | ||||
1KiB(4KiB aligned) | 1304.4 (1.27MB/s) | 2374.0 (2.32MB/s) | 61.9 (0.06MB/s) | ||||
2KiB(4KiB aligned) | 1275.5 (2.49MB/s) | 2339.9 (4.57MB/s) | 61.1 (0.12MB/s) | ||||
4KiB(4KiB aligned) | 16299.0 (63.67MB/s) | 2284.8 (8.93MB/s) | 278.3 (1.12MB/s) |
驚くべきことに、RealSSD C300がパフォーマンスを発揮できるのは4KiB単位の書き込みが4KiB境界にアラインされている時のみです。それ以外は、全ての項目でVertex 30GB(Barefootファミリーの中でほぼ最低速度)に劣る性能しか出ていません。また、WD20EARSもC300と全く同じ傾向を示しています。
MimicXLSを用いた小サイズファイルの書き込み速度向上
RealSSD C300とWD20EARSのベンチマーク傾向は、体感速度に影響を及ぼす可能性があります。パーティションのアラインメントが取れていれば、どうせクラスタサイズは4KiBなんだから関係ないんじゃないの?という声も聞こえてきそうですが、実際には関係あります。クラスタサイズは最小のファイルサイズを指定しますが、OSはセクタ(512バイト)単位での読み書きを行います。また、NTFSのファイル情報は"管理レコード"に記録されますが、その大きさはクラスタサイズに関わらず1KBです。こだわりのMONOさんの記事では、C300の体感速度はX-25MやVertex LEに劣るとされていますが、その原因はこの小サイズの書き込みの遅さである可能性があります。
さて、この問題について、http://hpcgi1.nifty.com/yosh/さんのhttp://hpcgi1.nifty.com/yosh/sp/aft/という記事に非常に詳細で参考になる記述があります。また、同ページにおいて、問題を回避することができる"MimicXLS"というソフトが公開されています。このソフトは、ドライブの論理セクタサイズを大きなサイズ(デフォルトでは4096バイト)にエミュレートさせるというものです。
というわけで、"MimicXLS"によるパフォーマンスの向上をベンチマークしてみました。なお、Iometerは論理セクタサイズ未満のサイズの書き込みテストは行えないので*1、フォルダのコピー速度を計測する非常に簡単なソフトを作って実行してみました。中身はSHFileOperation関数にかかった時間を高分解能パフォーマンスカウンタで計測しただけです。
コピーするフォルダは前述のページと同様にGCC 4.5.0のソースを用いました。OSはWindows 7 64bit(KB981208適用済み)、チップセットはP55、AHCIモードです。コピー元はK5-64(Barefoot搭載SSD, SLC, 64GB)です。テストは3分の間隔を置いて3回繰り返しました。表中の数値の単位は秒です。
コピー先ディスク・条件 | 一回目 | 二回目 | 三回目 | ||||
RealSSD C300 256GB(通常) | 97.41 | 97.45 | 100.71 | ||||
RealSSD C300 256GB(MimicXLS) | 87.79 | 88.68 | 89.44 | ||||
WD20EARS (通常) | 131.99 | 131.77 | 132.59 | ||||
WD20EARS (MimicXLS) | 100.79 | 101.58 | 101.54 | ||||
Vertex 30GB (通常) | 90.35 | 89.60 | 89.18 |
MimicXLSにより、コピー速度が高速化されているのが分かります。先ほどのIometerの結果ほどのインパクトはありませんが、この計測時間にはコピー元のファイルの情報収集にかかる時間(エクスプローラでのコピーの際に"コピーの準備中"と表示される時間)が含まれていることもあり、性能向上の余地が小さかったと考えられます。
以上のように、RealSSD C300には小サイズの書き込みの性能が悪いという不思議な特性があります。この問題はMimicXLSにより緩和できるので、該当のSSDをお持ちの方は試してみてはいかがでしょうか。当然のことですが、システムにダメージがあっても大丈夫なようにバックアップを取り、くれぐれも自己責任でトライしましょう。
RealSSD C300のAverage Erase Count
RealSSD C300のSMARTの仕様は公開されていないのですが、簡単に書き込みテストを行った結果、おそらく"AD"の項目がAverage Erase Countを示すことを突き止めました。ファームウェアのバージョンは0002です。
やったことは単純で、シーケンシャルライトとランダムライト(4KB)を行いながらSMARTの値を取得し、変化を記録しただけです。
まず、シーケンシャルライトについては、書き込み量とADの変化は以下のようになりました。SMARTの取得に結構時間がかかるので、取得タイミングは1GiBの書き込みごとに一回のみとしました。
ADの値 | 総書き込み量 | 差分 | |||
26 | 218[GiB] | 218[GiB] | |||
27 | 470[GiB] | 252[GiB] | |||
28 | 722[GiB] | 252[GiB] | |||
29 | 974[GiB] | 252[GiB] |
きれいに252GiBごとにADの値が1ずつ増えています。NANDの総容量は256GiBなので、先天的不良ブロックなどを除いた残りが約252GiBなのでしょう。
次に、シーケンシャルのテストの直後から始めたランダムライトの結果は以下の通りです。書き込みサイズは4KB、書き込みの範囲はディスク全体とし、SMARTの取得は1024回の書き込みごとに行いました。
ADの値 | 総書き込み量 | 差分 | |||
30 | 39.67[GiB] | 39.67[GiB] | |||
31 | 70.95[GiB] | 31.28[GiB] | |||
32 | 101.85[GiB] | 30.90[GiB] | |||
33 | 132.75[GiB] | 30.90[GiB] |
ディスク全域へのランダムライトなので、テストの途中からだんだんと書き込み速度が落ちてきます。SMART取得時間も含め、最初は32MB/sぐらいの書き込み速度だったのが、ADの値が31に変わる頃には10MB/s程度にまで下がり、最終的に9MB/s程度で落ち着きました。最初だけADが変化するのに必要な書き込み量が多いですが、これは物理アドレスの断片化が少ない状態のとき、書き込みの一部を最適化できるためだと思われます。完全に劣化した状態でADが変化するのに31GiB程度を要していることから、この状態でのWrite Amplificationは8となると思われます。
これ以外にも、RealSSD C300のSMARTには、なぜかだんだん減っていくAA, 上位2バイトと下位4バイトがそれぞれ別の値を表しているように見えるB5など、気になる項目が色々あります。東芝さんもそうですが、SMARTの仕様は公開してもらいたいものです。
追記(2010/8/8)
ちょっとお問い合わせを受けたので補足しておきます。
今回取り上げたRealSSD C300のパフォーマンスの低下についてですが、これを以て地雷認定をするほど酷いものではありません。と少なくとも僕は思います。
上述したコピーテストについて、GCCのソースは小さなファイルを大量に含んでおり、非常に条件の悪いものでしたが、それでもパフォーマンスの低下は10%程度でしかありません。そもそも小さいサイズの書き込みはOSのキャッシュが効くので、体感速度には大きく影響しないと考えられます。実際、大学で使用しているノートPCのメインストレージをX-25MからRealSSD C300に移行したのですが、特に目に見えて体感速度が下がったという感触はありません(まあ僕はあまり敏感な方ではないのですが…)。
というわけで、これからお買いになる人も現在お使いの人も、大きな心配する必要はないと思います。
*1:実際には、読み書きをするディスク・ファイルのバッファリングやキャッシングをしない設定(FILE_FLAG_NO_BUFFERING)にした場合の制限です。詳しくは、Windows previous versions documentation | Microsoft Docs、などを参照してください
NAND/AFTにおけるパーティションアラインメント問題のまとめ
最近のHDDの大容量化・低価格化はとどまるところを知らず、2TBのWD20EARSは何と9,000円を下回る価格で販売されています。従来のHDDは512バイトを1物理セクタとして扱い、PC側も同様に512バイトを1論理セクタとしていたのですが、WD20EARSを始めとしたWestern Digital社の最近のHDDは、4096バイトを1物理セクタとするAdvanced Format Technology(AFT)を採用しています。AFTは、HDDの見かけの容量を増やし、読み書きの速度を向上させ、おまけにECCの効率まで向上するといいことずくめなのですが、一方で後述する論理・物理セクタのずれによる性能低下が発生します。この性能低下は、SSDやUSBメモリといったNANDフラッシュ製品でも起こります。今回の記事では、これらの性能低下問題について、性能が下がる原理と、実際のパフォーマンスの変化についてまとめます。
Advanced Format Technology + Windows XP におけるパフォーマンス低下問題の整理
Advanced Format Technologyについての詳細は、@ITの記事に詳しく解説されています。XP以前のWindows OSでのパフォーマンスの低下問題は、これらのOSがHDDをフォーマットすると、パーティション開始オフセットを63論理セクタ(31.5KiB)に設定してしまうことに起因します。この状態を図示すると、以下のようになります。
Physicalは実際のHDD上の物理アドレス、LogicalはOSが操作する論理アドレスを表し、正方形のブロック1つが512バイト(1論理セクタ)を表します。太枠の長方形は、上段は物理セクタ、下段はパーティションのクラスタを表します。
物理セクタ・パーティションクラスタの双方が4KiBなのに、論理アドレスが始まるのが63セクタめなので、1論理セクタずつ位置がずれてしまっています。このずれを修正するためには、パーティション開始オフセットの大きさを8論理セクタの倍数にすればよいわけです。Vistaや7ではパーティション開始オフセットが2048になるため、この条件をクリアしています。
要するに、この問題の原因はOSがXPであることではなく、パーティション開始オフセットの大きさが8の倍数になっていないことにあります。従って、XPでAFT採用HDDをフォーマットする場合であっても、Diskparなどのツールを使ってオフセットを調整しておけば問題ありません。同様に、Vista以降のOSでも、意図的にオフセットを63に変更すると、XP同様のパフォーマンスの低下が発生します。
実際に、Windows7(64bit)においてWD20EARSのパーティション開始オフセットをdiskparを用いて変更したベンチマーク結果は以下のようになりました。(P55チップセット、AHCIモード、IRST使用)
オフセットを63にすると特にランダムリード・ライトでパフォーマンスが低下しているのが分かります。この辺は体感速度に影響しやすいところなので、しっかりパーティションアラインメントを調整した方がよいでしょう。
オフセットのずれによるパフォーマンス低下の原理
前掲のテスト結果では、特にランダムライト性能が大きく落ち込んでいます。これは、オフセットがずれた状態で小さな書き込みを行うと、実際の書き込みはRead-Modify-Writeと呼ばれるアルゴリズムによって行われるためです。以下では、Read-Modify-Writeがどのように行われるか、図を用いて簡単に解説します。
以下のように、OSが1クラスタ(4KiB)を書き込むときについて考えます。
AFT採用HDDでは4KiB単位(図の太い長方形枠)の読み書きしかできないので、このように境界線をまたぐ書き込みを直接行うことはできません。
そこで、まず最初にHDD内のRAMに、境界前後の8KiB分のデータを読み込みます(Read)。
次に、RAM上のデータに、OSから送られた書き込みデータを上書きします(Modify)。
最後に、RAM上の8KiBのデータを書き込みます。これで、OSから指示された4KiBの範囲内だけの書き込みを行うことができます。
以上のように、OSは4KiBの書き込みしか行っていないにも関わらず、実際のディスクでは8KiBの読み込みと8KiBの書き込みが行われています。それでは遅くて当たり前です。
上記のプロセスは書き込みについてですが、読み込みに関してはより単純で、1物理セクタ分を余分に読み込み、いらない部分を省いてOSに送るだけです。この場合、常にOSの要求より1物理セクタだけ多くの読み込みが行われます。
NANDフラッシュ製品の場合
こだわりのMONOさんの記事でも解説されているように、SSDやUSBメモリなどのNANDフラッシュ製品でも、これと同一の問題が発生します。NANDフラッシュは、読み込みも書き込みもページと呼ばれる単位で行う必要がありますが、ページの大きさは、例えば多くのMLCタイプのNANDでは4KiBとなっています。そのため、オフセットがずれていると、前述のAFT採用HDDと同様に、ページの境界をまたいだ書き込みが行われる可能性があるため、Read-Modify-Writeに起因するパフォーマンス低下が発生します。
オフセットがずれている場合のパフォーマンスの低下量は、製品によってかなりの差があるようです。以下に、いくつかのストレージについてオフセットを変化させた場合のCrystalDiskMarkの結果を掲載します。いずれも前述のWD20EARSと同じ環境での測定です。
- OCZ OCZSSD2-1VTX30G(Vertexシリーズ、Barefootコントローラ、32GB)
- Crucial CTFDDAC256MAG01G1(RealSSD C300シリーズ、256GB)
Vertexでは4KBの書き込み性能が若干下がっているだけですが、RealSSD C300では大きくベンチマーク結果が低下しています。RealSSD C300ほどの差が出ることは珍しく、Intelや東芝、JMF602といったあたりもBarefoot同様に4KBの書き込み性能が微減する程度のようです。
VertexなどのSSDでパーティションアラインメントの影響が少ない理由は、以下のように推測することができます。
SSDは、複数のNANDに対して並列(またはインターリーブ)にデータの読み書きを行うことで高速化を図っています。コントローラが単純な設計であれば、例えば、ページサイズ4KiBのNANDを4個並列で動かした場合、一回の読み書きの単位が16KiBになります。そのため、それ未満のサイズの書き込みが行われると、必ずRead-Modify-Writeが行われます。
このSSD上のドライブのオフセットがずれていることを想定します。もし書き込みがページの境界線をまたいでしまうと、2ページ分のRead-Modify-Writeが必要となるため、書き込みのレイテンシは2倍程度になると考えられます。
しかし、下図を見れば明らかなように、OSからの書き込み量が4KiBの場合、その書き込みが物理セクタの境界線をまたぐ確率は1/4でしかありません。
従って、4KBのランダムライトのIOPSは、オフセットがずれているとフルスペックの80%(4/5)に下がると予想されます。同様に物理ページサイズが32KBなら8/9, 64KBなら16/17にしか変化せず、影響は限定的です。
一方、Intel,Micron,Sandforceのように、よりランダムライトが高速である製品は事情が異なる可能性が高いです。
ランダムライトが遅いSSDは、コントローラが仕事をサボっているから遅いのではなく、先ほどのRead-Modify-Writeのようにせっせと(無駄な)読み書きを行っているから遅いのです。SSDを語る上では、"Write Amplification"がよく話題になります。これは、"OSが実際に書き込んだ量の何倍の書き込みがSSD内部で行われたか"を表す指標です。先ほどのNANDを4並列で動かすSSDのRead-Modify-Writeの場合、OSからは4KiBの書き込みしかしていないのに、SSD内部では16KiBの読み書きが行われるとするなら、単純にそれだけでWrite Amplificationは4になります(実際のWrite Amplificationはガベージコレクションなどの影響でもっと増える)。この場合、どうがんばってもSSDの地力の4分の1以下しか性能を発揮できないわけです。また、JMF602のプチフリ状態、あるいはUSBメモリやSDカードでは、OSからの書き込みが行われる度にブロックコピー(詳細はこちらの記事参照)が行われます。この場合、Write Amplificationは簡単に数百を超えます。
例えばIntelの場合は10並列でNANDへの読み書きが行われますが、4KiBのOSからの書き込みごとに4x10=40KiBのRead-Modify-Writeを行っていたら、CrystalDiskMarkで観測されるような40〜50MB/sというスコアを出すことはできないでしょう。また、Intelが主張する"Write Amplification=1.1"を達成するのも到底不可能です。詳細はもちろん不明ですが、うまくRead-Modify-Writeを避けるようなアルゴリズムが実現されていると考えられます。
そして、それらのRead-Modify-Writeを避けるアルゴリズムがコントローラごとに異なるというのは十分考えられます。Intelのアルゴリズムはオフセットがずれていた場合の悪影響を受けにくく、Micronのアルゴリズムは悪影響を受けやすいのでしょう。
アラインメントの状態チェックと対策
パーティション開始オフセットを簡単に調べるには次のようにします(XP,Vista,7共通,64bitでも可)。XPを使っていなくても、TrueImageなどのバックアップツールが勝手にオフセットを63にしてしまうことがあるので注意が必要です。
- Win+Rで"ファイル名を指定して実行"ダイアログを出す
- msinfo32と入力してOK
- コンポーネント->記憶域->ディスク とツリーを辿る
- 各ディスクの"パーティション開始オフセット"の値を調べる
ずれたパーティションアラインメントを直す方法は、こだわりのMONOさんの記事に詳しく掲載されています。有料のソフトでもいいから簡単確実に修正したいという場合は、同様にこだわりのMONOさんの記事で紹介されているParagon Alignment Toolを使うのが良いでしょう。また、WesternDigital社は、自社のAFT採用HDD向けのオフセット修正ツールを公開しています。