今回テストに使用するのは、
（推定）消去ブロック サイズ(MB)
SanDisk 2GB (new) 2MB 1886
SanDisk 4GB (new) 2MB 3781.5
Kingston 4GB 2MB 3780
Transcend 4GB 2MB 3926
カードリーダ：M121 x4
USB HUB: GH-UHK204SS (Self Powered)
マシン: 玄箱/HG Linux (ppc)
これに加えて、前回テストに使用したカードをテストの有効性をチェックするために使用。
（推定）消去ブロック サイズ(MB)
SanDisk 2GB (old) 512K 1938.5
A-DATA 1GB (broken) --- 971.5
カードリーダ：MA8123 x2
USB HUB: GH-UHK204SS (Self Powered)
マシン: 玄箱/HG Linux (ppc)
A-DATA 1GB は、壊れてボロボロになったもの。SanDisk 2GB もボロボロのはず。カードリーダのテストも兼ねていて、最後までやるかどうかはわからない。
MLC タイプの方は、だいたい 512 x 40 = 20480 の 4K Write に 60分〜80分かかっている。iops になおすと 4.3 iops 〜 4.7 iops 。想定した時間どおり。
今回使用したプログラムは、http://nmj.sumomo.ne.jp/arc/flashtest8.c
今回あらたに作成し、チェックを厳しくしている。
プログラムには、初期化-チェック-実行の 3 フェーズがある。
初期化は、カードを all 0 で初期化して、テスト対象のエリアなどのパラメータをカードに書き込む。
チェックは、書き込み済みのデータを全部チェックして正しいかどうかのチェックをする。チェックが通らないと 実行のフェーズには行かない。( 再開するには、修正 モードで実行する )
実行では、2MB x 40 ヶ所の 80MB のエリアを対象に、512x40 回の Write を行い、その後正しく書けたかどうかのチェックをする。これを 100 回繰り返したら、エリアを移動する。エリアを移動するときに、すべてのエリアが正しいかどうかチェックしなおす。
なお、今回のテストはファイルシステムを通さずパーティションを対象にするようにしている。理由は、ファイルシステムデータ（メタデータ）が壊れるとなにもできなくなるため。
あと、ついでなので Windows MinGW でコンパイル - 実行できるようにしている。責任は持たないが興味がある方はどうぞ。
テスト期間は 1〜2 ヶ月の見込み。結果は追記する予定。
補足：プログラムの説明
ひとつのエリアは、2MB x 20 = 80 MB と書いたが、2MB は、4KB x 512 。次のようになっているわけだ。
00 [000][001][002][003] ..... [510][511]
01 [000][001][002][003] ..... [510][511]
:
38 [000][001][002][003] ..... [510][511]
39 [000][001][002][003] ..... [510][511]
これを次の順番で書き込んでいく
00 [001][041] ....
01 [002][042] ....
↓ ↓
18 [039][079] .....
19 [040][080] .....
全部書き込んだら、READ して値が正しいかを確認。
これを 100 回繰り返すので、1 つのエリアに対して、
40 x 512 x 100 = 2048000 (回)
の 4K WRITE を行うことになる。エリアの数は 4GB で 約 50 個。
x 50 とすると、全部で 102400000 (約 1 億回)の WRITE を行うことになる。
消去ブロックの数は 4G で 2000 個弱のはずで、1 ブロックあたり、5 万回書くことになる。完全なウェアレベリング制御が実現できたとしていたとしても、1 万回が限界ならば、1/5 までの段階でどこかにエラーが見つかるはず。
それまでにかかる時間はどれぐらいかというと、4KB の WRITE が 4.5 IOPS だとして、1/5 の 2000 万回でエラーになるとすれば、
2000万 / 4.5 / 60 / 60 / 24 = 51.44..
約 50 日ということになる。
正しいデータかどうかの確認方法
まず、N 回目の WRITE の 4KB 内の値は、タイムスタンプを除いて一意に決まるようにしている。だから、N 回目のWRITE のデータが入っていることが分かれば、正しいデータかどうか判別できる。
書き終わってしまった エリアについては、100 回目のループの結果だから 簡単に内容が分かるのだが、今書いているエリア は どこまで書いたかの情報がないと、正しく判別するのは難しい。
面倒なので、N 回目という情報を 2 ヶ所に書いて、その 2 つの値が同じなら、N 回目の WRITE だと決め付けるようにしている。N さえ分かれば、それに対応するデータが決まるので、正しいかどうか判断できる... ということにしている。
コマンドラインオプション
flashtest8 [-i [-a A] [-z Z] [-n N] [-l L]] [-c [-d|-f]] [-r] デバイスファイル名
-i 初期化をする
初期化時(のみ)に以下のパラーメータを設定できる。
-a エリアの最大数 (default 40)
-z ゾーンのサイズ (default 2M)
-n ゾーンの数 (default 40)
-l ループの回数 (default 100)
-c チェックをする
-f エラーがあった場合正しい内容に書き換える
-d エラーがあった場合、ダンプする (未実装)
-r テストを実行する
デバイスファイル名
Linux の場合 : /dev/sde1 などのブロックデバイスファイル
Windos の場合: e: などのドライブレター
A-DATA 1GB (broken) でデータ化け発見か
97536 回 Write したところで... Write エラー。
調べてみると、USB レベルでエラー(リセット) が起きて、scsi デバイスが Offline されている。その結果 Write エラーになった模様。--- どうも カードリーダ(MA8123) とHUB(GH-UHK204SS)の相性が悪く、負荷が高いとこういうことが起きるようだ。
それはともかく、再開したら 77056 回目のデータが化けていることが発覚。でも、ちょうど 20480 回の差なので、まさに最後に書いたデータではないかと思える。-- どうもチェックのコードにバグがあるようだ。
で、fix して再開したところ ... しばらくして また I/O エラー。
カードリーダを M121 に変更して様子を見ることに。
SanDisk 2GB (old) が壊れた！
01/22 15:35:16 : 1720320 area 0 loop 84
01/22 16:25:27 : 1740800 area 0 loop 85
find_last:read: Input/output error
compare error 1738595 at 00047c8000
なんてエラーが出て止まっていた。また、カードリーダ(MA8123)のせいかと思って、カードリーダを変えてみたが、やはり I/O エラーが起きる。
dmesg で見てみると .. こんなエラーが多数。
sd 36:0:0:0: SCSI error: return code = 0x8000002
sda: Current: sense key=0x3
ASC=0x11 ASCQ=0x0
end_request: I/O error, dev sda, sector 147023
-c オプションで調べてみると ..こんなエラー
find_last:read: Input/output error
last count = 1740799
check all start
check_area:read: Input/output error
invalid block (0,35,456)
check all -- 1 errors found
microSD 耐久テスト結果で書いたように、通算 6 億回書き続けて壊れなかったカードが、こんなわずかな回数(といっても 3日間書き続けているけど)で壊れるとは ...
たぶん、既に壊れていたがチェック方法が悪かったため気が付かなかったのだろう。( read エラーになったブロックに上書きしてしまうと、自動的に代替してエラーに気が付かないはず。)
それはともかく... SanDisk 2G(old) では、ハードディスク と同じように read で I/O エラーを返してくれる。化けたデータを返す カードと比べれば、壊れたことが分かって安心だ。
ついでなので、以前 壊れてしまった キングストン → 「microSD の壊れ方(キングストン編)」 でどうなるか、SanDisk 2G(old) と入れ替えてやってみることにする。
たぶんこいつは、SanDisk と同じように すみやかに read エラーになるはず。
やってみたところ ....
1 loop 20480 回の Write の後のチェックで、I/O エラー だらけになった。さすがに、これはダメになりすぎているようだ。
ちなみに、ちょっとずつプログラムに手を加えている。
今の最新は、http://nmj.sumomo.ne.jp/arc/flashtest8b.c
09/02/09
Kingston 4GB が I/O エラー
2MB のゾーン x 40 = 80GB のエリア 1 つを書き終わるといままで書き込んだすべてのエリアをチェックしているのだが、エリア0,1,2,3 を書き込んだ後で、I/O エラーが出て プログラムがアボートした。
書き込んだ 回数は、合計で 819 万回 (512 x 40 x 100 x 4)。
この結果から判断すると、Kingston (= 東芝) の安microSDHCは、ウェアレベリングどころか、代替すらまともにやってくれないように見える。（ひょっとして ハードディスクと同じように、上書きしたときはじめて代替する？）
I/O エラーが出たゾーンは、
エリア 0 0 個
エリア 1 26 個
エリア 2 14 個
エリア 3 0 個
推測するに ... 先頭からある程度は FAT があるはずだから耐久性が高くなっていて、エリア 0 はノーエラー。あとのエリアは 限界を超えて書き込んだだめに、時間が立つにつれて 読めなくなってくるという状態ではないかと思う。後日 再度チェックしてみることにして、こいつはテスト終了。
他のカードは元気に動作中。（ ボロボロなはずの A-DATA 1GB (broken) も）
ちなみに、今の最新は、http://nmj.sumomo.ne.jp/arc/flashtest8c.c
エラーが起きた場所を表示するように修正。
09/02/11
A-DATA 1GB (broken) がデータ化け
エリア0,1,2,3,4 を書き込んだ後で、コンペアエラー プログラムがアボートした。
で、チェックしてみたところ、正しいデータが読めたり、データ化けしたデータが読めたり する状態になっている。
化けるのは特定の場所みたい。
エリア 0 ゾーン 39 --- 5 回のチェック中 3 回エラー
エリア 1 ゾーン 7 --- 5 回のチェック中 1 回エラー
どういう風に壊れていくのか分かってきたように思う。たぶんしばらく時間をおけば さらに壊れているところが増えるのだろう。
そう言えば .. Kingston 4GB はどうなったのか？
2/9 2/12
エリア 0 0 個 1 個
エリア 1 26 個 35 個
エリア 2 14 個 25 個
エリア 3 0 個 0 個
合計 40 個 61 個
こいつも増えてきている。
ちなみに、今の最新は、http://nmj.sumomo.ne.jp/arc/flashtest8d.c
09/02/27
SanDisk 2GB (new) が I/O エラー
エリア 7 の loop 43 で I/O エラー発生でプログラムがアボート。
チェックしたところ、エリア 7 で read エラーが一ヶ所。
書き込んだ回数は、合計で 1521万回。エリア 7 loop 43 。
1/20 に開始したから、かれこれ 37 日も実行していたわけだ。確かに壊れても良さそうな頃合。
ちょっと計算してみよう。
2GB で 消去ブロックサイズが 2MB だとすると、1000 個のブロックしかない。きれいに ウェアレベリングできたとしても 平均 1.5 万回も書き込んでいる。
やはり壊れる頃合だ。MLC なので 1.5 万回も書いたら壊れてもまったく不思議はない。
さて、問題はこれからどうなっていくか。今のところ リードエラーは、1 ヶ所だけだが、やはり増えていくのだろうか？
そういえば Kingston 4GB。ちょっと前にチェックしたところ エラーが 80 ヶ所に増えていた。たぶんさらに増えているはず、あとで改めて チェックしてみることにする。 ( I/O エラーが起きる場合、何回もリトライなどしているらしく、全部をチェックし終わるまですごく時間がかかる。 )
A-DATA 1GB (broken) がデータ化け
エリア 0 ゾーン 39 --- 5 回のチェック中 1 回エラー
エリア 1 ゾーン 7 --- 5 回のチェック中 3 回エラー
エリア 1 ゾーン 15 --- 5 回のチェック中 1 回エラー
エリア 1 ゾーン 31 --- 5 回のチェック中 5 回エラー
エリア 2 ゾーン 31 --- 5 回のチェック中 1 回エラー
順当に増えている。
Kingston 4GB read エラー数
2/9 2/12 2/27
エリア 0 0 個 1 個 5 個
エリア 1 26 個 35 個 36 個
エリア 2 14 個 25 個 35 個
エリア 3 0 個 0 個 27 個
合計 40 個 61 個 103 個
エリア 0 以外全滅に近くなってきた。
09/03/16 : 追記
Kingston 4GB read エラー数
2/9 2/12 2/27 3/11
エリア 0 0 個 1 個 5 個 18 個
エリア 1 26 個 35 個 36 個 37 個
エリア 2 14 個 25 個 35 個 39 個
エリア 3 0 個 0 個 27 個 32 個
合計 40 個 61 個 103 個 126 個
エリア 0 もだんだん読めなくなってきている。
SanDisk 2GB (new) は、 1 ヶ所のみ。
エリア 7 の zone 10 が読めない状態。
A-DATA 1GB (broken) のデータ化け
エリア 0 ゾーン 39 --- 5 回のチェック中 5 回エラー
エリア 1 ゾーン 7 --- 5 回のチェック中 5 回エラー
エリア 1 ゾーン 15 --- 5 回のチェック中 2 回エラー
エリア 1 ゾーン 23 --- 5 回のチェック中 5 回エラー
エリア 1 ゾーン 27 --- 5 回のチェック中 2 回エラー
エリア 1 ゾーン 31 --- 5 回のチェック中 5 回エラー
エリア 1 ゾーン 35 --- 5 回のチェック中 2 回エラー
エリア 2 ゾーン 7 --- 5 回のチェック中 1 回エラー
エリア 2 ゾーン 31 --- 5 回のチェック中 2 回エラー
データ化けする所が増えている。それだけではなく、データ化けする所の読める確率がだんだん落ちてきている。
追記 09/05/07 Transcend 4GB がついにエラー
1/20 から3 ヶ月以上 Write しつづけて、5/5 についに壊れた。
エラーになるまでの Write 回数は 5940万回。 （推定）消去ブロックは 3926個(2MB)なので、平均 1.5 万回の書き込みで壊れたことになる。
ちなみに、エラーの種類は compare error ( データ化け ) 。A-DATA と同じような感じ。
5/7 時点で、8 ヶ所の compare error を検出。日がたつにつれ、このエラーの数が増えていくはず。
ところで、SanData 4GB はまだ元気。--- といっても書き込みが若干 遅く まだ 4334 万回しか書き込んでいない。
