JSMonitor使用時での初故障報告
タイトルの通り、JSMonitor使用時におけるSSDの初故障報告をいただきましたので、紹介させていただきます。
今回報告していただいた方は、SSDを通常の用途で使用していたのではなく、SSDの書き込み耐久テストを行っていたとのことです。そのため、通常の用途より短時間で多量の書き込みが行われています。
テスト条件・方法は、下記に引用します。
テスト環境
CPU Phenom8450e
マザー A-N78HD
メモリ UMAX 2GBx2
HDD OS用 WD1200BEVE（120GB ATA)
OS Windows XP SP3
テストはExcelのVBAによる半自動処理
SSD Patriot 32GB SATA(PE32GS25SSDR)まず初期設定として
4K〜256Kのテキストファイルで15GB書き込み
その後、空いている領域に、HDDにバックアップ保存しておいた
4Kファイル16Kファイルのフォルダをコピー後消去の繰り返し4Kファイル(2GB分のフォルダ)のコピー
コピー1回(2GB分)の平均作業時間 1時間15分程度
コピー1回での ブロック消去回数 6.50個
計 306回 608G 642Mバイトくらい 作業時間15日20時間程度
延べ 約1億6000万ファイルAverage Erase Count 2007に達した所で作業を変更
16Kファイル(2GB分のフォルダ)のコピー
コピー1回(2GB分)の平均作業時間 12分程度
コピー1回での ブロック消去回数 1.48個
計411回 821G 433Mバイトくらい 作業時間3日9時間程度
延べ 約5400万ファイルこの辺りで作業ログは途切れ、テスト用のマシンは再起動を起こしていた。
なお実験に使用したSSDは現在Bios上では認識出来るが接続した状態ではOSが立ち上がらなくなった。
何回かの再起動の後、一度だけ認識する事が出来たが。
その時JsMonitor起動は確認した。
だが、SSDの中身を見ようとエクスプロ−ラーを立ち上げると、OSがフリーズしてしまい中身を見る事ができない状態になり、以後沈黙している。
最終状態でのログファイルもいただいたので、最後の部分を下記の表に引用します。
| 時刻 | AEC | MEC | GBC | SBC | EFN | EC | EB | EAddr | |
| 2009-Jan-12 05:04:21 | 2593 | 2763 | 8164 | 520 | 1 | 5 | 0 | 3 47 6 | |
| 2009-Jan-12 05:14:21 | 2594 | 2763 | 8164 | 520 | 1 | 5 | 0 | 3 47 6 | |
| 2009-Jan-12 05:24:21 | 2596 | 2763 | 8164 | 520 | 1 | 5 | 0 | 3 47 6 | |
| 2009-Jan-12 05:34:21 | 2597 | 2764 | 8164 | 520 | 1 | 5 | 0 | 3 47 6 | |
| 2009-Jan-12 05:44:22 | 2598 | 2768 | 8156 | 512 | 3 | 2 | 1 | 7 228 8 | |
| 2009-Jan-12 05:54:22 | 2600 | 2768 | 8148 | 504 | 5 | 2 | 1 | 1 154 68 | |
| 2009-Jan-12 06:04:22 | 2601 | 2768 | 8140 | 496 | 7 | 2 | 1 | 4 23 46 | |
| 2009-Jan-12 06:14:22 | 2602 | 2768 | 8132 | 488 | 9 | 2 | 1 | 6 14 35 | |
| 2009-Jan-12 06:24:22 | 2603 | 2769 | 8052 | 408 | 29 | 2 | 1 | 4 129 15 | |
| 2009-Jan-12 06:34:22 | 2605 | 2769 | 7960 | 316 | 52 | 2 | 1 | 6 247 1 | |
| 2009-Jan-12 11:17:09 | 2617 | 2769 | 7684 | 40 | 121 | 2 | 1 | 3 241 122 |
略語は以下の通り。
MEC = Max Erase Count(最大消去回数)
AEC = Average Erase Count(平均消去回数)
GBC = Good Block Count(使用可能ブロック数)
SBC = System Block Count(システム領域ブロック数)
EFN = ECC Fail Number(誤り訂正発生回数)
EC = ECC Channel(最後に誤り訂正が起こったチャンネル番号)
EB = ECC Bank(最後に誤り訂正が起こったバンク番号)
EAddr = ECC Address(最後に誤り訂正が起こったアドレス)
ログの時刻が最後に飛んでいるのは、そこでマシンの再起動が発生したためとのことで、再起動後もう一度JSMonitorを立ち上げたのが11:17:09のようです。
05:44:22以降、急激に誤り訂正の発生回数が増加し、それに伴いGood Block CountとSystem Block Countが減少していっているのが分かります。
ここで、誤り訂正とブロック数の関係について解説しておきます。
ECCとは誤り訂正符号のことで、NANDフラッシュのデータ化けを検出し、訂正するために付加されている冗長なデータです。一般的に、SSDは誤り訂正の発生をNANDフラッシュの破損とみなし、誤り訂正が発生したブロックを以降使用不可能な状態にします。
このように、誤り訂正が発生するたびに使用可能なブロックの数(Good Block Count)は減るわけですが、OSから使用可能なディスク容量が変化してしまうと困ったことになってしまいます。そこで、OSから使用可能なディスク容量を一定にするため、SSDには予備ブロックがあります。その予備ブロックの数がSystem Block Countであり、OSから使用可能なブロック数はGood Block CountからSystem Block Countを引いた数になります。
上記の表を見ると、誤り訂正が1回起こるたびにGood/System両方のブロック数が4つずつ減少しているのが分かります*1。同時に、Good Block CountからSystem Block Countを引くと、どのタイミングでも7644になっています。
次に、誤り訂正がSSD上の"どこ"で起きているかについてです。
上記の表では、最初の誤り訂正はChannel番号5、Bank番号0のフラッシュチップで発生していますが、05:44:22以降検出された誤り訂正は全てChannel番号2、Bank番号1のフラッシュチップで発生しています。すなわち、記録された誤り訂正は全て同じフラッシュチップ上で発生しているということです。
なお、Bank,ChannelとはSSD上のフラッシュチップの管理単位です。
Channelとは、コントローラが同時アクセスするフラッシュチップの数で、JMF601は4, JMF602は8となっています。JMF602の場合、各フラッシュチップ単体の最大読み込み速度は約20MB/s, 最大書き込み速度は10MB/s強しかありませんが、8個のフラッシュチップに同時に読み書きを行うことにより、全体では読み込み約160MB/s、書き込み約90MB/sを実現しています。
Bankとは、フラッシュチップが何セットあるかを示しています。例えば、上記のPE32GS25SSDRの場合、Channel=8, Bank=2となっていますが、この場合フラッシュチップは8x2=16枚あります。
さて、今回の件の解釈ですが、個人的な推測では、これはフラッシュチップの故障なのではないかと思います。
最大2769回という書き込み回数はまだ少ない回数ですし、誤り訂正の発生回数はあまりに急激に見えます。また、上述のように記録された誤り訂正は全て同一のフラッシュチップ上で発生しています。
実際に、Max Average Countが4000を越えても誤り訂正が一度も発生していないという事例もありますし、BotchyWorldさんの実験では、よく言われている書き換え制限回数10,000回には届いていないものの、故障までに7,500回以上の書き換えが行われています。
そもそも、メーカがよく公称している"10,000回の書き換え耐久性"というのが実際に何を示しているのかがよく分かりません。破損までに必要な書き換え回数の平均が10,000回なのか、99%のNANDフラッシュが10,000回の書き換えで破損するのか、など色々な解釈ができてしまいます。
いずれにしても、ユーザサイドからできる検証は限られているので、メーカ側から詳しい資料が公開されないかと期待しています。
JSMonitorの今後のアップデートについて
今回の件を受けて、次のバージョンでは"SSD故障警報"を実装しようと思います。
すなわち、短期間に同じフラッシュチップで誤り訂正が発生した場合、故障の可能性がある旨を警告するというものです。現在の実装でも誤り訂正発生時に警告ダイアログがでますが、より分かりやすい形で警告を出す必要があると思います。
現在の誤り訂正情報の表示について
現在のバージョンでは、"Last ECC Information"という項目で8つの生データを表示しています。
なぜこの分かりにくい状態にしているかというと、データシートの情報が間違っている可能性があるためです。トランセンド社のデータシートの27ページTable3に誤り訂正に関するSMARTの仕様が出ています。これによると、最初の1バイトがECC Fail Number、2バイト目以降がアドレスとなっていますが、今までご報告をいただいた3つの例は、いずれもアドレスが3バイト目から始まっているようです。
おそらく、ECC Fail Numberは1バイト目と2バイト目の合計2バイトなのではないかと思います。Free Block Countは128GB製品で2000程度あるので、誤り訂正は255回以上起こる可能性があり、2バイトが必要となります。
ファームウェアのバージョンや製品によって異なる可能性もあるため、今までは前述のように生データのまま表示していましたが、やはりこの情報は非常に重要であるため、次のバージョンからは分かりやすく表示する予定です。
*1:なぜ誤り訂正一回につき4ブロックずつ使用不可能になるのかはよく分かりません。どなたか教えていただければ幸いです。
