Hatena::ブログ(Diary)

Lansenの現実逃避日記 このページをアンテナに追加 RSSフィード

2010-10-05

[]東芝SSDの耐久テストリードオンリーモードについての所感(訂正済み) 01:55 東芝SSDの耐久テストとリードオンリーモードについての所感(訂正済み)を含むブックマーク 東芝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など、CDUSBメモリからブートできるLinuxOSを万一に備えて用意しておくといいでしょう。

$Bitmapとは?

上記のBotchyWorldさんの記事では、Windows XPSSDを接続した際、「$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を発注してしまいました。週末にプログラムを組んで耐久試験を実行してみようと思います。

kobagenkobagen 2010/10/06 06:50 ちょうど先日CDIで取得したSSがあります。>Onyx
http://www.exa5.jp/diary/img/img217_file.png
見た限り同じと言っていいかと思います。
(Amigos=IDX100M01、Barefoot ECO=IDX110M01で同一ファミリーっぽいですし)

一つ質問なのですが、JSmonitorのTECで表示される使用量の算出方法はAvarage Erase Countの変化からでしょうか?

余談:
リードオンリーだとして、気になるのはどういう風にHostに返してるかです。たとえば昔のHDDにあったWPジャンパの様に書き込みにエラー返しちゃうだけなのかどうか。それならばWindowsで見る・ブートするためには普通VoomやTableauなどの(主にフォレンジックに使われる)Write Blockブリッジを介してやらないと無理だったような記憶があります。
#ただ、あの状況だとデータリテンションエラーが発生してるのか個人的には判断しかねます。

kei100kei100 2010/10/06 12:47 Lansen様、お久しぶりです

>たとえば昔のHDDにあったWPジャンパの様に書き込みにエラー返しちゃうだけなのかどうか。
Windowsの動きを見た限りコレっぽいですね
VPCでVHDをうっかり読み取り専用にした時の症状と全く一緒ですし

LansenLansen 2010/10/07 01:21 >kobagenさん
情報ありがとうございました。本文にも書きましたが、早速Onyxを発注しました。
JSMonitorは、デフォルトではAverage Erase Countの履歴からTECを計算します。JSMonitorの設定(タスクトレイのアイコンを右クリックし、メニューから"設定"を選ぶ)を変えると、Maximum Erase Countから計算することも可能となります。

>お二方
そういえば手持ちのUSBメモリに書き込み禁止スイッチがあったなあと思って試してみたんですが、NTFSでもFAT32でも正常にリードオンリードライブとして中身を参照できています。リードオンリーになった東芝のSSDは、このようなドライブとは挙動が異なるみたいですね。

asukaasuka 2010/10/07 10:37 USBメモリだと、OSからはRemovable deviceとして認識されていませんか?
それだと、Fixedとして認識されるSSDとは、OSからの扱いが代わりそうな気が…
XPなら、Hitachi Microdrive用のfilter driverなんかをどっかから拾ってきて、
USBメモリに適用したらFixedとして認識するかもしれませんね

LansenLansen 2010/10/08 00:57 >asukaさん
あ、すいません。上で試したのはSHD-U32GSという製品で、(なぜか)固定ドライブとして認識されます。
メーカーのBuffaloでは、SHD-U32GSをUSBメモリではなく「シリコンディスク」と呼称しています。
http://buffalo.jp/products/catalog/storage/shd-us/
USB接続で固定ドライブ、ということでBotchyWorldさんの状況と同じになるかと思いきやそうではありませんでした。

そういえばDeviceIoControlでドライブがリードオンリーかどうか調べる方法があったような気がするなあと思って検索してみたのですが、"IOCTL_DISK_IS_WRITABLE"というそのものズバリなControlCodeがありました。
http://msdn.microsoft.com/en-us/library/aa365182%28VS.85%29.aspx
試してみたところ、書き込み禁止モードにしたSHD-U32GSではしっかりFALSEが返ってきて、仕様通りGetLastErrorの戻り値が"ERROR_WRITE_PROTECT"になっていました。
もしBotchyWorldさんの使ったUSB-SATA変換チップが常にIOCTL_DISK_IS_WRITABLEに対しTRUEを返すようになっていたら、OSは書き込みができると認識しているのに実際はできず、訳分からないことになりそうな気がします。Windowsで認識できなかったのは案外そんな理由だったりするかも?

kakashikakashi 2010/10/08 08:56 耐久実験では書き込みスピードの劣化に注目されるかもしれませんが、
読み出しスピードの劣化にも注意を払われるといいと思いますよ。

EMOEMO 2010/10/09 13:21 ご無沙汰してます。
かなり長丁場のテストになりそうな気がしますが、期待してます(無責任に)。

asukaasuka 2010/10/09 13:35 おぉ、Disk on keyみたいな形状でも、Fixedとして認識される製品もあるのですね(良いことを知った)
diskpart使うなり、他のUtil使うなりでなんとかなりそうな気もするけど、diskadminで深く考えないで扱える事を考えると、1つ持っていても良い気がしてきた。
さて、NotePC用にSSDを新調するとしたら、今だと何が良いのだろ?Intelにしておくのが無難かな?

LansenLansen 2010/10/09 22:31 >kakashiさん
NANDはウェアに応じて読み書き・消去の速度が変わると言われてはいますが、あまり実在の製品で調べた例は見たことがないですね。確かに興味深いかもです。

>EMOさん
データ保持エラーについてまで調べようとするとかなり時間がかかりそうです。まあ基本放置でいいので楽と言えば楽かも?
ちなみに僕もはやぶさのプラモ作りました。といってもAmazon限定のメッキ版を素組しただけですが…
最初はある程度改造しようと思ってたんですが、EMOさんのBlogを見てスッキリ諦めました(笑

>asukaさん
EeePCなどのために、SDカードを固定ドライブに認識させるソフトとかもありますね。
>さて、NotePC用にSSDを新調するとしたら、今だと何が良いのだろ?Intelにしておくのが無難かな?
やっぱり無難なのはIntelか東芝でしょうね。Windows 7ならRealSSD C300やSamsung 470シリーズでもいいかもです。

ひよひよひよひよ 2010/10/13 23:23 これは期待のプロジェクトですね!!
EMOさんと同じく無責任に楽しみにしております。

LansenLansen 2010/10/14 23:24 どうもです。
まあ思った通りに行くとは限らないので、あまり期待しないで見ててください…

トラックバック - http://d.hatena.ne.jp/Lansen/20101005/1286297708