東芝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など、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を発注してしまいました。週末にプログラムを組んで耐久試験を実行してみようと思います。