2009年01月20日

microSD (MLC) 耐久テスト開始

テスト用のプログラムが完成し、予備テストも OK だったので、耐久テストを開始した。

今回テストに使用するのは、

(推定)消去ブロック サイズ(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 万回しか書き込んでいない。
posted by すz at 02:02| Comment(0) | TrackBack(0) | microSD関係

2009年01月14日

テスト用 4G microSDHC 購入

MLC の耐久テスト用として、ずいぶん安くなってきている 4GB の microSDHC をいくつか購入した。

テスト方法はまだ考え中だが、どんなものなのか性能をいくつか調べて考察してみた。

まずは、CrystalDiskMark 2.2 の結果から。

SR SW 4KRR 4KRW size
SanDisk 4GB 23.807 15.514 6.117 0.040 3886.5()
(class 2 bulk)
Toshiba 4GB 23.686 12.419 5.331 0.017 (3780)
(microSD,SD-C04GR5W4)
Kingston 4GB 23.686 12.513 5.287 0.018 (3780)

Transcend 4GB 20.227 8.374 7.139 0.025 (3926)
(TS4GUSDHC6)
-- (備考) --
SR -- Sequential Read (MB/sec)
SW -- Sequential Write (MB/sec)
4KRR -- Random Read 4KB (MB/sec)
4KRW -- Random Write 4KB (MB/sec)
size -- MB 単位 ()は Windows で表示されるサイズ

測定環境: Aspire One (カードスロット)


Toshiba と Kingston ははっきり言って同じもの。性能も同じだし、サイズも同じ。なので、Tosiba のテストはやめることにする。あと、SanDisk の 4KRW は microSDHC/SDHC としては、かなり良い値。

さてテストの内容は考え中なのだが、前回と同じように N KB おきに 4KB(or 8KB)を書くのをベースにしようと思っている。

まずは、いったいどれぐらいの性能なのか ... N を変化させて 調べてみることにした。

SanDisk 4GB
32k 101.812 iops 407.248 KB/sec
64k 86.347 iops 345.388 KB/sec
128k 65.165 iops 260.662 KB/sec
256k 36.524 iops 146.097 KB/sec
512k 20.269 iops 81.075 KB/sec
1024k 9.700 iops 38.798 KB/sec
2048k 9.282 iops 37.128 KB/sec
4096k 9.249 iops 36.997 KB/sec
Kingston 4GB
32k 114.303 iops 457.214 KB/sec
64k 88.156 iops 352.622 KB/sec
128k 51.089 iops 204.357 KB/sec
256k 29.376 iops 117.506 KB/sec
512k 15.896 iops 63.584 KB/sec
1024k 8.294 iops 33.177 KB/sec
2048k 4.267 iops 17.069 KB/sec
4096k 4.257 iops 17.027 KB/sec
Transcend 4GB
32k 115.109 iops 460.436 KB/sec
64k 67.944 iops 271.778 KB/sec
128k 40.528 iops 162.113 KB/sec
256k 22.301 iops 89.204 KB/sec
512k 11.722 iops 46.886 KB/sec
1024k 5.964 iops 23.857 KB/sec
2048k 5.966 iops 23.863 KB/sec
4096k 5.989 iops 23.954 KB/sec

テスト環境: Linux(ppc) , カードリーダ SD/MMC Reader


テスト結果を見るとわかることがいくつかある。N が小さいと性能が高いが、N を大きくしていくと、CrystalDiskMark の 4KRW より若干低い値に収束する。

消去ブロックサイズ 以上だと同じ性能だが、1/2 では 2 倍前後、1/4 では 4 倍前後の性能のように思える。-- どのカードも 消去ブロック内の Write はまとめて行っているのだろう。

そう考えると SanDisk , Transcend の 消去ブロックサイズ は 1MB 。Kingston(Toshiba) は 2MB ということになる。

そして(もっと重要なことだが)耐久テストにかかる時間の見積もりができる。

仮に 消去ブロックサイズが各々 1万回の書き込みに耐えると仮定する。全部の消去ブロック数も分かるし、iops から書き込み 1 回の時間も分かるから見積もりができるのだ。

これをもとに計算すると ...

SanDisk 4GB 3886.5 x 10000 / 9.700 (sec) = 46.27 (日)
Kingston 4GB 3780/2 x 10000 / 4.267 (sec) = 51.26 (日)
Transcend 4GB 3926 x 10000 / 5.964 (sec) = 76.19 (日)


なかなか時間がかかるが、前回よりは短い。テストの内容さえ確定すれば、十分テスト可能だ。

問題はテストの方法。

いままでの結果から判断すると、Write は限界を超えてもエラーにならない。Read してチェックするにしても 書き込んだすぐ後は正しいデータが読めてしまう。しばらくして読み直すと 壊れていることが分かるのだが、(しばらく)という時間がどれぐらいであるべきなのか 全然わからない。

いまのところ、次のようにしたらどうかとは考えている。


1. 2MB おきの 40 ヶ所 (80MB のエリア)に 4KBを書いていく。
2. 全部書き終わったら 4KB ずらして 同じことをする。
3. 512 回繰り返すと全部埋まるので、まとめて Read してデータをチェックする。
4. それを 100 回繰り返すと、2MB ブロックの場合で、5.12 万回、1MB の場合で 2.56 万回書き換えたことになる。

5. 4 まで終わったら エリアをずらす。その際に過去に書いたエリアのデータを 全部 Read してチェックする。
6. エリアの数は、40 個ぐらいだが、全部書ききる前に壊れるはず。

書き込み方法と対象:
 - Linux で O_DIRECT で、/dev/sdX1 に対してテストする。
  (ブロックデバイスに対して O_DIRECT が使えるので、
ファイルシステムを通して使うより書き込みを
確実にコントロールできる。)

- Windows MinGW で使えるプログラムにする予定。
(テスト自体はしないが、一応)

再開モード:(+ 壊れたかどうかの確認)
 - 途中で終了してしまうことは、過去になんども起きている
からちゃんと対応する。

 - 一時的な Read エラーへの対処
USB HUB とかに問題があってもエラーが起きる。
Read エラーの場合は、再開モードで正しければ再開する
  ようにする。

- 一時的な Write エラーへの対処
USB HUB とかに問題があってもエラーが起きる。
  正しくないデータがあった場合 -- 通常は、エラー内容を
表示して終了させるが、正しいデータを書き直して
  再開できるモードもつける。

 - 書き込み途中でのアボート(電源断とか)への対処
4KB の 最初と最後にシグネチャを埋め込み Write 自体が
完了しているかどうかチェック。シグネチャーが不一致なら
Write が完了していないと判断して、エラー扱いにはしない。



おまけ

今回使ったプログラム -- ( flashtest_tobi.c )

Windows MinGW 用の コードも入れておいた。


gcc -O -o flashtest_tobi.exe flashtest_tobi.c -lwinmm

でコンパイルして

flashtest_tobi -d -f e:

などとすると実行できる(e: はドライブレター)。
ただし、e: ドライブは破壊されるので、間違えないよう注意。
危険なプログラムなので、バイナリは添付しない。試したい人は MinGW をインストールして自分でビルドのこと。

ちゃんとデバッグできていないかも知れないが、大体同じような値が表示されているので大丈夫だと思う。

なお、-d は O_DIRECT の意味。Windows では、FILE_FLAG_NO_BUFFERING を使用。
-d なしだと、O_SYNC の意味。Windows では FILE_FLAG_WRITE_THROUGH を使用。




追記:2GB microSD も測定してみた。
microSDカードの書き込み耐性について
などの記事で使用した 1GB/2GB のカードの性能を同じように測定してみた。


A-DATA 1GB
32k 15.591 iops 62.364 KB/sec
64k 13.407 iops 53.626 KB/sec
128k 11.795 iops 47.181 KB/sec
256k 8.616 iops 34.465 KB/sec
512k 10.678 iops 42.712 KB/sec
1024k 14.211 iops 56.842 KB/sec
2048k 17.479 iops 69.918 KB/sec
4096k 19.474 iops 77.897 KB/sec

A-DATA 2GB
32k 33.156 iops 132.626 KB/sec
64k 28.289 iops 113.154 KB/sec
128k 25.793 iops 103.173 KB/sec
256k 12.165 iops 48.662 KB/sec
512k 8.342 iops 33.369 KB/sec
1024k 5.977 iops 23.906 KB/sec
2048k 8.216 iops 32.862 KB/sec
4096k 10.280 iops 41.118 KB/sec

SanDisk 2GB
32k 43.422 iops 173.686 KB/sec
64k 44.984 iops 179.937 KB/sec
128k 27.064 iops 108.254 KB/sec
256k 14.314 iops 57.257 KB/sec
512k 6.787 iops 27.150 KB/sec
1024k 6.477 iops 25.908 KB/sec
2048k 6.348 iops 25.390 KB/sec
4096k 7.077 iops 28.307 KB/sec

Kingston 2GB
32k 115.075 iops 460.299 KB/sec
64k 70.423 iops 281.690 KB/sec
128k 39.386 iops 157.542 KB/sec
256k 20.350 iops 81.400 KB/sec
512k 10.511 iops 42.043 KB/sec
1024k 10.377 iops 41.507 KB/sec
2048k 10.077 iops 40.306 KB/sec
4096k 9.748 iops 38.994 KB/sec


消去ブロックサイズは 256KB だろうと思っていたのだが、この結果をみると、SanDisk , Kingston は明らかに 512KB 。
どうも回数の計算は 1/2 として考えなければならなさそうだ。

A-DATA 1G,2G はよく分からない特性。1Gを例にすると、間隔256KBが最も遅いが、そこから 間隔を大きくしていくと性能が上がっていく。 当時も思ったが他のメーカのものとは全然制御が違うようだ。





09/01/15 追記

実は、上で使った SanDisk 4GB は、結構高かったときに買ったもの。最近のものは変わってしまっているのかどうか知りたかったので、4GB , 2GBを購入してみた。(GENO で 4G 599円、2G 399円)

CrystalDiskMark 2.2 の結果
SR SW 4KRR 4KRW size
SanDisk 4GB old 23.807 15.514 6.117 0.040 3886.5()
SanDisk 4GB new 23.701 8.639 5.352 0.022 3781.5(3778)

SanDisk 2GB new 11.985 6.710 4.355 0.022 1886(1884)

Write 性能がほぼ 1/2 になってしまっている。2GB もなんかひどい。

次に、flashtest_tobi で調べてみた。

SanDisk 4GB new
32k 156.740 iops 626.959 KB/sec
64k 88.652 iops 354.610 KB/sec
128k 57.372 iops 229.489 KB/sec
256k 35.039 iops 140.154 KB/sec
512k 19.015 iops 76.060 KB/sec
1024k 8.342 iops 33.369 KB/sec
2048k 4.794 iops 19.175 KB/sec
4096k 4.726 iops 18.904 KB/sec

SanDisk 2GB new
32k 84.890 iops 339.559 KB/sec
64k 63.452 iops 253.807 KB/sec
128k 46.948 iops 187.793 KB/sec
256k 33.003 iops 132.013 KB/sec 
512k 18.426 iops 73.706 KB/sec
1024k 8.275 iops 33.099 KB/sec
2048k 4.829 iops 19.316 KB/sec
4096k 4.684 iops 18.735 KB/sec

なんと、4GB も 2GB も (推定)消去ブロックサイズが 2MB になっている。
まぁどちらも MLC なのは間違いなさそうだ。

次のテストは、この 4GB と 2GB にしよう。
江戸の仇を長崎で討つようなものだが、次回は SanDisk 2GB が真っ先に壊れそうだ。

ついでなので ... お気に入りの SDHC A-DATA turbo を最近追加購入したら性能がだいぶ落ちていてがっかり。
... 値段が倍ほども違うので仕方ないとは思うのだが... 15MB/sec 以上でる 安 microSDHC/SDHC が減っているのは残念な傾向だ。

CrystalDiskMark 2.2 の結果
SR SW 4KRR 4KRW size
A-DATA 16GB old 23.245 16.615 7.523 0.035 15740(15736)
A^DATA 16GB new 22.075 11.315 6.895 0.024 15334(15530)

ちなみに、両方とも turbo。 カードのデザインも同じ。ただ、裏面のスタンプの字の大きさが違う。(新型は字が小さい)
posted by すz at 00:06| Comment(0) | TrackBack(0) | microSD関係

2008年12月19日

microSD 耐久テスト結果

2008年04月16日のmicroSD の壊れ方(キングストン編)の記事の後、実は ずっとテストを続けていた。

テストの対象は、上海問屋 1GB(A-DATA)と SanDisk 2GB。


      最後の更新 書き込み回数(合計) 
上海問屋 1GB 9月27日 合計 3.6112 億回
SanDisk 2GB 9月19日 合計 6.0000 億回


テストの内容は、256 KB おきの 40 ヶ所をサイクリックに書き込むというもの。だから SanDisk なら一ヶ所あたり 1500 万回書き込んだことになる。

結果は、SanDisk はノーエラーだった。上海問屋 1GB (A-DATA) は、2-3 回 Read データが違うというエラーになった。あらためて読み直して見ると正しい値が読めたので、テストを再開している。

回数の上限は、合計 6 億回にした。上海問屋 1GB は途中でテストが止まったので回数が少ない。最終的には、いいかげん飽きたのでテストを中断している。

SLC でも 物理的書き込みの上限が 10万回ぐらいだから、使っている領域とスワップするという高度なウェアレベリング機能が SanDisk と A-DATA には、組み込まれているようだ。

ところで、キングストンのテストでは、正しく書けたのに、(ほんの少し)後で読んでみると違うデータになるという現象になった。その結果から、劣化するとデータを保持できる時間が短くなっていくのではないか?と思える。

高度なウェアレベリング機能が働けば、全体的に劣化するわけで、しばらくすると正しいデータが読めないところが (全体のうち)どこかに出てくるかも知れない。

テスト終了から 3 ヶ月たったので、いちど データをチェックすることにしてみた。

SanDisk 2G

まず、1つのブロックを 平均何回書き換えたのか見積もってみることにする。

消去の単位は、 256KB だとする。そう仮定すると この microSD は、全部で 7754 ブロックある。

6億 / 7754 = 7.73 万回


ひょっとしたら、もうすこしで限界に達するのかも知れない。

データのチェック

DISK 全体をチェックしたが、不正なデータは存在しなかった。

上海問屋 1G(A-DATA)

消去の単位は、 256KB だとする。で 3886 ブロック。( ただ、あまり自信がない。ひょっとすると 128KB かも。)

3.6112 億 / 3886 = 9.29 万回


サイズが 1/2 なので、消去ブロックサイズが同じなら こちらの方が厳しい条件。

データのチェック

なんというか、もうバケバケ。1,2 bit が化けるというレベルではない。わかりやすいように all 0000 と all ffff のデータを示すと次のようなかんじ。0 → 1 のビット化けもあるが、1 → 0 のビット化けの方が多いみたい。


*
0103000 4000 0000 0000 0000 0000 0000 0000 0000
0103020 0000 0000 0000 0000 0000 0000 0000 0000
*
0103060 0000 8000 0000 0000 0000 0000 0000 0000
0103100 0000 0000 0000 0000 0000 0000 0000 0000
*
0103140 0000 0000 0000 0000 0000 0080 0000 0000
0103160 0000 0000 0000 0000 0000 0000 0000 0000
*
0103420 0000 0000 0000 0040 0000 0000 0000 0000
0103440 0000 0000 0000 0000 0000 0000 0000 0000
*
0103560 0000 0000 0000 0000 0000 8000 0000 0000
0103600 0000 0000 0000 0000 0000 0000 0000 0000
*
0103700 0000 0000 0000 0000 0000 0000 0000 0080
0103720 0000 0000 0000 0000 0000 0000 0000 0000
         :
3022060 ffff ffff ffff ffff ffff fffe ffff ffff
3022100 ffff ffff 7dff ffff fbff ffff fbff ffff
3022120 ffff ffff ffff ffff ffdb ffff ffff ffff
3022140 ffff ffff ffff ffdf ff7f ffef ffff ffff
3022160 ffff ffff ffff fdef ebff fbff ffff efff
3022200 ffff ffff ffff ffff ffff ffff ffff ffff
3022220 ffff ffff ffff ffff ffff ffff ffff dfff
3022240 ffff fbff ffff ffff ffff ffff ffff fdff
3022260 ffff ffff ffff ffff ffff ffff dfff ffff
3022300 ffff ffff ffff ffff ffff ffff ffff 7fff
3022320 ffff ffff ffff ffff fdff bfff ffff ffff
3022340 ffff ffff ffff ffff ffff ffff ffff fffb
3022360 efff ffff ffff ffff ffff ffff ffff ffff
3022400 ffff ffff ffff ffff ffff ffff ffff ffff
3022420 ffff ffff feff ffff fffd ffff dfff efff
3022440 ffff ffff fbff ffff ffff ffff ffff dfff
3022460 ffff ffff ffff fdff f7ff ffff ffff efff
3022500 ffff ff7f ffff ffff ffff ffdf ffff ffff
3022520 ffff feff ffff fdff ffff ffff ffff ffff
3022540 ffff ffff ffff ffff ffff ffff ffff ffff


書き込んだところ以外のチェック

一応 all 0 の内容のファイルで、DISK 全体を埋めている。
これらの値が変わっているかチェックしてみると ...

テストに使ったファイルに いくつかデータ化けが見つかった。
その他については、大丈夫のようだ。


*
47103040 0002 0000 0000 0040 0000 0000 0000 0000
47103060 0000 0000 0000 0000 0000 0000 0000 0000
*
47103400 0000 0000 0000 0000 2000 0000 0000 0000
47103420 0000 0000 0000 0000 0000 0000 0000 0000
*
47103540 0200 0000 0000 0000 0000 0000 0000 0000
47103560 0000 0000 0000 0080 0000 0000 0000 0000
47103600 0000 0020 0000 0000 0000 0000 0000 0000
47103620 0000 0000 0000 0000 0000 0000 0000 0000
*


これはもう、壊れてしまったといってよいと思う。
だが、書き込んだすぐ後にチェックしても正しいデータが読め
ていたわけだから、いまのテストではいつ壊れたのかが分かっていない。

3 ヶ月後に読んだらデータが化けていたことに気が付いたわけだ。

そろそろ 4GB も安くなってきているので、テストしてみたいと思っているのだが、新しいテスト方法を考えないと、テスト自体の意味がないかも知れない。

おわりに

このテストは壊すまでやって、どういう風に壊れるのかを調べることを目的にしている。

だから「壊れたから安心できない」というわけではない。誤解しないように。

また、テストの結果から SanDisk は安心できると考えるのも誤解である。テストした製品はたぶん SLC で、今 出回っているものは MLC ではないかと思う。また技術も進んでいるだろうし、今の製品を判断する参考にはならない。
posted by すz at 15:26| Comment(1) | TrackBack(0) | microSD関係

2008年04月16日

microSD の壊れ方(キングストン編)

ついにキングストン 2GB (JAPAN)が書き込み限界に達した!

ほぼ 1ヶ月の期間をかけて断続的に書き込んできた。書き込みの方法を試行錯誤しているので何回で壊れたと明確に言えないところがある。それは後でまとめるとして、どういう風になってしまったのかについてまず書こうと思う。

注意:たぶん壊れ方は、使っているチップによって違う。最初にテストした miniSD(64MB) と実際違う。ここで書くのはあくまで、キングストン 2GB microSD (JAPAN)についてということに注意してほしい。
ちなみに、2GB (TAIWAN)は、たぶん A-DATA と同じ。


キングストン 2GB の壊れ方

USB アダプタで使うかぎりいくらでも書ける。(USBアダプタでリトライしている?)そして、しばらく時間が立った後 リードエラー。

ちなみに、テストプログラムで 発覚するのが、2秒持たなかったとき。そういう状態にまでなった後、チェックしてみると複数のブロックでリードエラーがおきる状態になっていた。


ウィキペディア NAND型フラッシュにあるように不良ブロックができたわけだが、代替ブロックをすでに使い果たした後は、その不良ブロックを無理やり使い続けているんではないかと思う。

代替ブロックがない以上、このようになるのはやむを得ないとは思えるのだが、書き込んだ直後に不良ブロックの検出をやっても必ずしも発見できるとは限らないのでは? と思ってしまう。
もしそうだとすると、たとえウェアレベリングをやっていたとしても書き込み不良が起きる可能性はわずかに存在するのではないか?
余談:
実をいうとハードディスクも書いたデータが読めるとは限らない。RAID5 にしていても、ハードディスクが壊れた後、再構築でリードエラーが発覚して、データを復元できなかったという話はある。
だから、RAID5 だから安心とは言えない。定期的にディスクを読み出して、見つけた不良ブロックをつぶしていくような仕組みと併用してはじめて(それなりに)安心できる。

microSD だとメディアだから複数枚で RAID5 とかミラーリングは現実的ではない。ほんとうに大事なデータを保存するのに、カード内部でミラーリングしてくれる製品も(普通の製品とは別に)あれば嬉しいような気がしてきた。

さらなる余談:
買ってきたHDDはエージングしようというページを発見。microSD/SD カードもちょっとぐらいは、やっておいたほうが良いかも。問題のあるブロックが脱落してしまえば、しばらくは故障率が低いままで安定する ... ということになるんではないかと思う。たとえば 2GB の全体を 100回 write して チェックのため read するとして、write+read が 3MB/sec なら 18時間もかかる。メーカでこんなにテストしていないだろうから、意味はありそうな気がする。


FAT で使う場合どういう現象になるか?

ファイルシステムはファイルのデータ以外にファイルを管理するためのデータ(メタデータ)も持っている。→ FAT ファイルシステム覚え書き

FAT の場合だと、ファイルのデータに加えて、BPB (いわゆるSUPERBLOCK)、FAT、ディレクトリ・エントリの 3種類のメタデータを考察すればよい。


  • ファイルのデータが読めなくなった場合
    読めない以上しょうがない。でも被害はその1つのファイルだけ。
  • ディレクトリ・エントリが読めなくなった場合
    ファイルの中身は損害を受けていないが、アクセスできない。そういう場合、復旧ツールで中身だけは救い出せるはず。ただし、正確なファイルのサイズの情報が消失しているから、復旧できたとしても、余分な情報が後ろに付くはず。
  • FATが読めなくなった場合
    FAT は 2 つあってミラーされている建前になっている。片側がリードエラーになっても、もう一部が読めれば問題ないはず。...なのだが、FAT32 の場合 ミラーする・しないの設定がある。ミラーしていなければ、ファイルの中身にアクセスできないものが複数出てくる現象になるはず。
  • BPBが読めなくなった場合
    もっとも重要な情報がここに入っているので、普通全滅。ただし、書き換わらないかも。もしそうであれば、壊れることもないはず。
    ただ、BPBを含む 消去ブロックの 範囲で別のデータを書き換えているかも知れないので壊れないとも言い切れない。


基本的にリードエラーが起きてくれるほうが良いと思う。エラーにならずデータが化けたりすれば、気が付かなくて後で泣きを見ることになるかも知れない。ちなみに、データが化けるという現象は、microSD と違うレイヤ (USB アダプタとか HUB とか?)で起きる可能性がある。原因がはっきりしないので、ここでは詳しく書かないが、テストでそういうことも起きている。

こうなるまで、どれだけ書き込んだか


  • TEST1: FATで、8KB のデータを上書き 
    ※ ルート・ディレクトリ・エントリも書き換わる
    10万回の書き換えに 5分
    5620万回の書き換え。
    ※ あまりに速すぎるので、FLASHを1回1回書き換えているか怪しい
  • TEST2: EXT3で、1MB のデータを上書き
    ※ ファイルのデータのみ書き換わる
    1万回に 2時間弱
    156 万回
  • TEST3: EXT3で、256KB おきに 4ヵ所 32KB のデータを上書き
    ※ TEST2 と同等の効果のはず
    1万回(32KB x 4 x 1万回)に 51分 (5 万回時)
    合計1316万回 (1ヶ所あたり 329 万回)
  • TEST4: EXT3で、256KB おきに 40ヶ所 32KB のデータを上書き
    合計180 万回 (1ヶ所あたり 4.5万回)で リードエラー


もう TEST1 は忘れたほうが良いと思う。他のテストに比べ速すぎる。カード固有の最適化にうまくはまって FLASH をほとんど書き換えていないと考えることにする。

つぎに 消去ブロックのサイズを 256KB と仮定すると、TEST2〜TEST4 で、合計 2120万 ブロック書き換えた計算。これで 代替ブロック + 40ブロックをつぶしてしまったと考え、さらに、代替ブロックが、全体(7680 ブロック)の 3% の 230 ブロックあると 考えてみる。そうすると、1ブロックあたり 7.8 万回の計算。

まぁ妥当な結果ではないかと思う。ちなみに、キングストンは代替ブロック方式で、ウェアレベリングではないと思う。
posted by すz at 05:13| Comment(2) | TrackBack(0) | microSD関係

2008年04月11日

SDHCの仕様について

SDHC が 32GB までしか対応していないという話が気になっていたので、Physical Layer Simplified Specification (v2.00)をちょっと見てみた。

Block Write/Read コマンドの Start Address は、

n * 512 bytes (n: Integer)

という風に指定する。だから 物理レイヤでは、2G x 512 = 1TB までアクセス可能。

32GB が限界というのは SD として 32GB までの論理フォーマットしか決めていないというだけだと思う。

あと転送速度についてもチェックしてみた。

Default mode: 0 - 25 MHz, 上限 12.5 MB/sec
High-Speed mode: 0 - 50 MHz, 上限 25 MB/sec


という記載がある。すでに 150X (22.5 MB/sec)を売り文句にしている製品があるから、こちらのほうも仕様拡張が必要(に違いない)。

なのだが、CSD Register に TRAN_SPEED というのがあって、カードの上限転送速度を定義できるようになっている。

この定義、8.0 x 100M bits/sec (200 MHz, 100 MB/sec)まで決められている。( といっても決めていないだけで、その 10000倍までは定義可能そう。)

ただ、今の電気的仕様のまま x4 の 200MHz は無理そう。

補足:メモリの規格が目安になると思う。

     電圧 バスクロック
SDRAM 3.3V 133 MHz
DDR 2.5/2.6V 266 MHz
DDR2 1.8V 533 MHz
DDR3 1.5V 800 Mhz


...なのだが、

High Voltage SD Memory Card :
Operating voltage range: 2.7-3.6 V
Dual Voltage SD Memory Card :
Oerating voltage range: Low Voltage Range (T.B.D)


という記載もある。これをどうするかについて相当もめそうな気がする。


なんかいろいろ見ていると、NAND FLASH の電源はすでに 2電源になっていて、1.7〜1.95V, 2.6〜3.3V ぐらいが多いみたいだ。--- ということは、DDR2 相当 1.8V で、x4 の 200MHz あたりが妥当?



おまけ: CMD42 - Lock Unlock Function

SDカードには、パスワードでカードをロックする機能が定義されている。

オプション機能で、全部のカードでサポートされているわけではないのだが、ロックしたら、アンロックしないと データにアクセスできなくなる。もしパスワードを紛失したら、カードを消去(Force Erase)しなければならないらしい。

一般のUSB アダプタでこの機能をサポートしているとは思えないから、電子工作ネタになるかも。

さらにおまけ、... CMD42 でググると各社の仕様書がヒット。

追記 2011/11/28

Physical Layer Simplified Specification (v3.01) が出ていたので、メモ。

もともとの記事は、なにも情報がない状態で記述したもの。今はちゃんとした仕様書がある。

UHS-I という規格があって、転送速度のクラスが増えている。

Default mode: 0 - 25 MHz, 上限 12.5 MB/sec (3.3v)
High-Speed mode: 0 - 50 MHz, 上限 25 MB/sec (3.3v)

UHS-I (Ultra High Speed Phase I)
SDR12: 上限 25MHz , 12.5MB/sec (1.8v)
SDR25: 上限 50MHz , 25MB/sec (1.8v)
SDR50: 上限 100MHz , 50MB/sec (1.8v)
SDR108: 上限 208MHz , 104MB/sec (1.8v)
DDR50: 上限 50MHz , 50MB/sec (1.8v)

300MB/sec までの UHS-II については記載されていない。データ幅を 4bit → 8bit にするそうだからそれで 2倍。あとの 1.5 倍は、1.5v 化? そうなると DDR はたぶん使わないことに。が、いずれサポートして さらに倍の 600MB/sec までは行くのだろう。
posted by すz at 15:45| Comment(86) | TrackBack(0) | microSD関係

2008年04月04日

microSDでSSD

ちょっと妄想。

microSD は、とても小さく薄い。Flash 専用の LSI より小さいぐらいだ。それを一般の人が携帯用に買っている。まるで、LSI 単体が大量に売られているような状況だ。

いまは 2GB だが、4GB/8GB の普及が次に続くだろう。そうなると、やがて Flash メモリの中で microSD がもっとも bit単価が低くなるのではないだろうか?

さて、そうなってくると SSD を製造するのに、内部で microSD を使ったほうが安いとかいう状況になってこないだろうか。

SDカード用だが、かつて4枚挿しの SDB25SDという製品があった。今は、8枚挿しのこんなのとか、16枚の こんなのがある。

microSD を縦に挿すようなソケットがあれば、8x8 (8 並列 x 8)とかも作れてしまうのではないか。64 個もばらばらに挿すのは信頼性に不安があるというならば、8枚とか板に貼り付けて かつての SIM みたいにしても良いかも知れない。

2GB の microSD でも 64 個なら、128GB 。8GB なら 512GB だ。数年で 32GB も出てくるだろうから 2TB なんてのも無理な話ではない。

microSD を使ってうれしいのは、Flash の使いまわしができることだ。優秀なコントローラが出ればそれに乗り換えることができる。段階的に増設できればさらにうれしいかも知れない。

そういう製品が出てきてほしいと祈りつつ妄想を書いてみた。

追記:
GIGAZINE の情報、
PhotoFast から CR-9000という製品が出るらしい。SD カード 6枚挿し RAID0 が出来て 12980円らしい。
CrystalDiskMark の性能も公開されている。シーケンシャル I/O の性能は高いが、4KB Randam Write 性能は、0.063 といまひとつ。-- OS用Disk に使えないことはないと思うが、不満が出るかも知れない。
あと、SDHC (4GB 〜) 専用で、1枚から使用できるらしい。発売日は 6/28 。
それにしても、こういう製品が安価に出てくるのだから、microSD版(+より多くのカード)もいずれ出てくるかも知れない。

余談だが、こういうコントローラを個人で作ることは、おそらく可能だ。FPGA 使って 、IDE インターフェイスにまでできれば、IDE-SATAブリッジで SATA に変換することができる。信号線もそんなにたくさん必要ないから、FPGA も 表面実装品でいけそうだ。ちなみに、i-RAMも FPGA spartan3 XC3S1000 を使って IDE インターフェイスまでを実装している。SATA は ブリッジ。トランゼントの SSD も SATA はブリッジを使っている。(製品ページのデータシート参照)

追記:8並列 x8 とか書いたが、高速な SD Bus は、CLK を除く信号線(5 つ)は 1:1 で接続しなければならないらしい。電子工作レベルだと、TQFP144 か PQFP208 あたりが限界で、全部で 150 pin ぐらいしか信号線を使えないから、8-16 個を扱うのが精一杯かも。

追記:microSDの構造について

そんな情報はほとんどないのだが、ATP 製品に関するものが若干あったので紹介。

普通の SD でも、ウェハーの裏側を削って 0.2 mm までに薄くするなんて書いてある。1mm 厚の microSD で 4 層なら 0.2mm でも全然厚いから 0.1mm とかにするのかも。

追記:CF で SSD

メディアロジックAX25CF-Sが、engadjet本家 で紹介されている。リンク先を見ると 200ドルぐらい。

性能については、ここで紹介されている

センチュリー シリコンディスクビルダーCF RAID SATA SDB25CFS/ R5 として日本でも発売された。なぜか Amazon が安く17,622 円
これと、CF を組み合わせて、性能優先とか信頼性優先で SSD を組むのが今は良いように思う。32GB の (まともな)SSD は 5万円ぐらい。16GB のCFはピンキリで 7000円〜 30000円ぐらい。15000円の 16GB CF x2 でまともと言える SSD になるならば、おなじぐらいの価格性能比といえる。それなら、自由度が高い分 こちらのほうが良いのではないか。

microSD で SSD の話に戻る。
体積あたりの容量というものを考えてみると microSD の方が CF より大きい。bit単価も microSD の方が安くなっていくと思う。microSD を多数載せられるものがあれば、もっと良いのではないかと思ったのが、この記事を書いた動機だったりする。

最初は、垂直にさせるコネクタがあれば、沢山載せるのは楽勝とか思ったのだが、背が高くなってしまう。少々甘かったかも知れない。が、工夫しだいで沢山載せることは(物理的には)可能だと思う。


SSD とファイルシステム

今は、OS をインストールするような場合、SLC でないと話にならない状況らしい。前記事で書いたように、(microSD や) MLC の SSD は、ランダム Write 性能が極端に悪いのだ。

この問題は、ファイルシステムが、ランダム Write をしないように進化すれば解決する。そういうファイルシステム(コピーオンライト(COW) ファイルシステム)は現時点で存在するし、Linux では問題にならなくなるのは時間の問題だと思う。Windows でどうなるのか知らないが、やがてはそういう風になっていくのだろう。

そうなってしまえば、SLC にこだわる必要もなくなり、MLC の大容量という利点を享受できるようになる。

なにが言いたいかというと、MLC ベースのパラレル化で、シーケンシャル write を追求していくのが正しい方向だということ。SLC でなければダメだというのは、あくまで過渡期の話。いつまでも SLC が良いわけではないということを覚えておいてほしい。

補足:COWファイルシステムについて
ファイルシステムで、copy-on-write というのは、データを書き換えたときに、データを上書きするのではなく、新しいブロックを割り当ててそこに書く技術。データの場所を示す管理情報や空きブロックの情報も書き換わるわけだが、それらも上書きしないで新しいところに書く。そうすることで、ランダム Write をシーケンシャル Write にしてしまうのだ。前のデータを壊さないから スナップショットを作れるが、むしろ ランダム Write をしないことで性能を向上させるのが本来の目的。

ランダム Write が遅い SSD と Windows を組み合わせて使うには

これは単なる案。制限もあるし Linux の知識も必要だろう。

考え方は単純だ。シーケンシャル write が出ないように Linux を工夫してインストールし、その上で VM を使って Windows を動かす。

(たぶん)OS自体の起動を早くしたいという目的には向いていないだろうし、レスポンスが悪かったり、増設したデバイスが使えないとかいう問題が出るかも知れない。シーケンシャル write が出ないようにするにはどういう工夫が必要かも具体的にはわからないのだが... やってみれば案外簡単なのかも知れない。

実は、4G〜8G ぐらいの microSD に OS をインストールして、VMwarePlayer か VirtualBox で、どこでも myマシン環境を作ってみたいと思っている。Winows を動かしたいのではなく、Windows で Linux を動かしたいのだが。逆のパターンでもうまく動くのかも知れない。ちゃんと調べていないのだが、VMwarePlayer の仮想DISKファイル自体になんか工夫があったような気がするし、そもそも何もしなくても実用に耐えるかも知れない。ダメだとしても Linux 側で工夫の余地がいろいろある。

もし、ランダム Write が遅い SSD を買ってしまって途方に暮れているのなら試してみる価値はあるかも知れない。

microSD 上で Linuxを動かしてみる

WindowsXP 上の VMware Player の仮想環境で Vine-4.2 を動かしてみた。

まず、仮想ディスクを USB アダプタ経由の microSD に置くには工夫が必要。

仮想ディスクのサイズは 3.5GB (使用率 67%) 、仮想ディスクファイル自体は、2.6 GB。本来 FAT32 は、4GB まで OKのはずなのだが、これだと ファイルが大きすぎると言われ VMware が起動できない。リムーバブルメディアのNTFSフォーマットについてを参考に NTFS にすれば OK。


起動時間の比較

仮想ディスクの場所起動時間(秒)シャットダウン時間(秒)
C:ドライブ7318
NAS(玄箱/HG)7522
microSD(キャッシュON)9763
microSD(キャッシュOFF)9754

※ キャッシュON :ポリシーをパフォーマンスのために最適化


使った microSDは、A-DATA turbo 4GB 。CrystalDiskMark はこの程度

--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 19.503 MB/s
Sequential Write : 9.836 MB/s
Random Read 512KB : 19.397 MB/s
Random Write 512KB : 2.014 MB/s
Random Read 4KB : 6.087 MB/s
Random Write 4KB : 0.024 MB/s

Test Size : 100 MB


ちょっと使っただけだが、microsSD は、少々もたつく感がある。でも、あまり気にならない。
そして、キャッシュON/OFF であまり性能が変わらない。たぶん、Windows版 VMware は、(Windows のキャッシュを使わないようにして) DISK にちゃんと書き込むような I/O をしているのだと思う。 キャッシュONの操作は、NTFS をフォーマットするときだけ必要で、使うときは必要なさそうだ。

この程度でもまともに動くのは、ゲストOS の Linux が、たちの良い I/O をしてくれている and/or VMware がなにか最適化してくれている為だと思う。どちらが効果があるのかはわからない。

さて、microSD より NAS(玄箱/HG)に置いたほうが速い。その理由は、次の値で説明できると思う。

-------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 10.031 MB/s
Sequential Write : 8.809 MB/s
Random Read 512KB : 10.411 MB/s
Random Write 512KB : 9.126 MB/s
Random Read 4KB : 4.200 MB/s
Random Write 4KB : 2.418 MB/s

Test Size : 100 MB

Random Write 4KB がやたら速いのだ。C:ドライブでも 0.6 ぐらいなのに、その 4倍も速い。アプリで キャッシュを使わないようにしても、NAS 側の キャッシュまで制御できないのが理由。

あくまで予想だが、Windows を Linux 上のゲストOSとしてインストールする場合も、こういう関係になるはず。Windows がタコなI/O を出しても Linux が キャッシュを持っていてうまくやってくれると思う。

おまけの情報 -- 仮想ディスクを置いた microsSD は Windows が管理しているから、Linux からは 直接は見えない。でも別の USB DISK は Linux からみえて mount できた。さすが歴史あるVMだ、期待どおりに動いてくれる。

追記: microSD に WindowsXP をゲストOSとしてインストールしてみる

Transcend TS32GSSD25-M (MLC版)は ランダム Write がきわめて遅い SSD で、OS 用の DISK に使うには向いていない(とメーカ自身認めている)。あえて Windows XP をインストールすると 12時間以上かかり、立ち上げも 20分とか30分とかかかるらしい。CrystalDiskMark の結果は以下のような値で、microSD (A-DATA turbo 4GB )より若干劣るほどのレベル。


Transcend TS32GSSD25-M
--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------
Sequential Read : 20.955 MB/s
Sequential Write : 7.321 MB/s
Random Read 512KB : 20.961 MB/s
Random Write 512KB : 1.678 MB/s
Random Read 4KB : 5.468 MB/s
Random Write 4KB : 0.014 MB/s


では、VMware Player の仮想DISK を microSD (A-DATA turbo 4GB)に置いて、WindowsXP を インストールするといったいどれぐらいの時間になるのか実験してみた。


仮想ディスクの場所インストール時間(分)1回目立ち上げ時間(分)
C:ドライブ501.5
microSD801.5



ホストOS は WindowsXP 。上の予想はホストOS が Linux なら速いというものだった。が、ホストOSがWindowsで、WriteBack キャッシュを効かさない場合でも若干遅いレベルに収まっている。

TS32GSSD25-Mが 12時間もかかるのならば、7時間ぐらいかかりそうなものだ。にもかかわらず、1時間20分で済んでいるのは VMware の仮想 DISK ファイルの仕組みが関係していることになる。

ウィキベディアの コピーオンライトを見てみると、”BochsやQEMUといった仮想マシンの仮想ディスク装置で使われている。”という記載がある。VMware Player の仮想 DISK も スナップショット機能を持っている。そして ”スナップショット機能を備える論理ボリュームマネージャやファイルシステムの多くがその実現にCOWを用いている”という記載どおりに COW を持っていると思われる。

ウィキベディアには書いてないが、COW は ランダム Write をシーケンシャルにするという側面がある。(前のデータを上書きしないならば、新しい領域に書くということだ。ならば、ちらばった領域への Write が一ヶ所にまとまる傾向にあるはずだ。)

qemu のソースコードには、block-qcow.c 、block-qcow2.c 、block-vmdk.c などがある。これらが仮想ディスクファイルの管理をしているようだ。あまりサイズが大きくないので、ちょっと調べてみようと思う。ちなみに、qcow については The QCOW Image Formatというドキュメントもあるようだ。興味があるのは vmdk だが、どう違うとか参考になるかも。


追記: WindowsXP を Flash 向けに高速化するには(考察)

たとえば eeePC を 軽量化して高速化する方法として nLite というものがあるらしい(ググる)。ここでは、そういう方法ではなく、ランダムWrite の遅い DISK 自体を高速化するにはどうしたら良いか考察してみよう。

仮想マシンの方が高速になる(はずの)ケースを紹介したが、それは仮想ディスクの仕組みによるものだ。仮想マシンそのものは関係ない。WindowsXPで動く仮想ディスクソフトがあって、それがCOW機能(and/or スナップショット機能)を持っていれば、良いわけだ。

ちょっと探してみたのだが、残念ながらそれそのものは見つからなかった。しかし、TrueCryptという暗号化ソフトがあることを知った。

これには、リムーバブルディスクだけでなく、システムディスク(or システムパーティション)を暗号化する機能がある。もし、COW機能があれば、暗号化のオーバヘッドがあっても ランダムWrite が高速化されるのではないか ...

ちょっと microSD(A-DATA turbo 4GB)を暗号化してベンチマークしてみた。

--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 13.938 MB/s
Sequential Write : 6.270 MB/s
Random Read 512KB : 13.587 MB/s
Random Write 512KB : 2.813 MB/s
Random Read 4KB : 3.750 MB/s
Random Write 4KB : 0.038 MB/s

Test Size : 100 MB


シーケンシャル系が遅くなっている代わり、Random Write 4KB が速くなっている。ただ、期待するような性能レンジにはなっていない。おそらく Write が非同期になったために、高速化したのだろう。

さて、TrueCrypt はソースが公開されているらしい。そして、qemu には、qcow2 というスナップショットが取れる COW 仮想ディスク機能がある。この2つをマージすると求めるものが作れるのかも知れない。

注意: この記事だけを見て商業ソフト(シェアウェア含む)を作ってみようと思いつく人が出るかも知れないので、警告。
GPL のソースを元にプロプライエタリなソフトを作ることはできないことは言うまでもない。...として

COW にはさまざまな特許があるはず。特許をクリアしないで、商業ソフトを作るのは結構リスクがある。
もちろん オープンソースでもやばいのだが、オープンソースは(IBM など)正式に免責されたり、あるいは見て見ぬふりをされる傾向にあり、商業ソフトとは少々扱いが違う。なによりソースコードしか配布しない(= あとはすべて使う人の責任)という最後の逃げ道があるのだ。
posted by すz at 02:14| Comment(0) | TrackBack(1) | microSD関係

2008年04月02日

microSDの性能について

microSDカードの書き込み耐性についてその2 その3)を調べて来たが、ここでは集めた各社の 1G/2G microSD の性能について書いてみることにする。

シーケンシャル I/O

100MB のファイルを 作成し 読み込む性能を調べてみた。OS は Linux(powerPC 266Mhz) 、ファイルシステムは FAT16。



typewrite (MB/sec)read (MB/sec)size (256KB単位)
A-DATA 1G
=上海(オ) 1G
4.6715.293886
A-DATA 2G
=上海(オ)2G
7.9615.297788
キングストン 2G7.3515.517680
Photo Fast 2G7.3515.907680
SanDisk 2G bulk4.439.397754
Silicon Power 2G3.919.217754
トランセンド 2G5.167.987802


前の記事で、上海問屋オリジナルは A-DATA と同じと書いたが、このデータを見ると Photo Fast 2G = キングストン 2G、SanDisk 2G bulk = Silicon Power 2G のように見える。

さて本当だろうか? Photo Fast 、キングストン 確かに、裏面を見るとまったく同じ。SanDisk bulk と Silicon Power はぜんぜん違う。

ランダム I/O read

次に、100MB のファイルを使い 100MB 分ランダムに read する時間を調べてみた。単位は秒、I/O サイズは、1M,256K,128K,32K,4K。なお、ファイルシステムは、I/O の出方を制御するために ext3 にしている。



I/O サイズ→1M256K128K32K4K
A-DATA 1G
=上海(オ) 1G
5.9106.1436.4247.64124.212
A-DATA 2G
=上海(オ)2G
6.0086.2586.6807.70924.790
キングストン 2G5.6035.8876.2227.32425.970
Photo Fast 2G5.6635.8886.2257.32825.921
SanDisk 2G bulk10.31010.57910.98712.20132.568
Silicon Power 2G10.28710.56711.04012.16832.433
トランセンド 2G12.44112.65513.02314.20533.370


性能特性がまったく同じ -- これはもう断定してよいだろう。といってもこれは私が入手した製品に限った話。時期や入手先が違うとモノが違う可能性はある。

補足:SanDisk bulk 、Silicon Powerで 裏面の形状が違う以上、まったく同じという意味ではない。中身が同じという意味。

ちなみに、ここで測定した Silicon Power 2G は、2007年10月に入手したもの。最近入手したものは、形状が違う。--- でも、よくよく見れば SanDisk bulk と同じ。サイズ・性能も 同じだった。


そんなことより、注目すべきは、I/O サイズが小さいと性能がかなり低くなるということ。DISK では当たり前だが、Flash もそうなのか? 特に 4KB が遅い。これは OS や USB アダプタのオーバヘッドなのだろうか?

ランダム I/O write

最後に、100MB のファイルを使い 10MB 分ランダムに write する時間を調べてみた。I/O サイズは、read と同じ 1M,256K,128K,32K,4K。


I/O サイズ→1M256K128K32K4K
A-DATA 1G
=上海(オ) 1G
3.4305.6278.56213.032130.487
A-DATA 2G
=上海(オ)2G
3.4477.98112.80221.872245.856
キングストン 2G3.6409.09513.16432.675251.279
Photo Fast 2G3.7027.80112.22629.388222.333
SanDisk 2G bulk4.74110.77116.88152.974410.973
Silicon Power 2G5.32610.23815.50254.403401.552
トランセンド 2G6.30312.49118.04154.984411.061


read の 1/10 しか I/O していないので、同じような数字なら 1桁性能が違う。4KB は 遅い 4KB read と比べて さらに 2桁違うわけだ。

ここまで遅いとは思わなかった。microSD は、ランダム I/O の write が 超苦手である。(OS をインストールするような使い方だと) 書き込み耐性なんかよりもっと大きな弱点だと思う。

そういえば、SSD への Windows のインストールに 12時間かかったという話を見たことがある。小さなI/Oサイズでの write が多いのだろう。MLC(マルチレベルセル)Flash 一般の性質と見て良さそうだ。

SSD への Windows インストールが遅いというのは、これとかこれだった。

ちなみに、ある SSD 製品を Windows の OS 用に使うことを考えているなら、CrystalDiskMark 2.1 の Random Write 4KB 値をググると良さそう。この値が 0.1 MB/sec 以上でないと厳しいらしい。
例→ TS32GSSD25-M CrystalDiskMark 2.1
ちなみに、トランセンドのページには、TS32GSSD25S-M(MLC) と TS32GSSD25S-S(SLC)の2種類があって、OS をインストールするには、SLC の方を推奨すると書いてあった。

さて、各製品の特性を見てみると、A-DATA 1G が速いのが興味深い。シーケンシャル I/O の write は 2G の 1/2 なのに、4KB のランダムは 2倍。これはいったいどういう理由なのだろう?

あと、トランセンドは、Photo Fast = SanDisk bulk と特性が似ているように思う。ひょっとしたら使っている Flash チップが同じか 同一メーカのリビジョン違いなのかも。

なお、製品の性能の絶対値はあまり気にしなくて良いと思う。半年もすればモノ自体が変わって性能もぜんぜん変わってしまっているかも知れない。ランダム I/O の write が 超苦手であることだけ覚えておけば良いだろう。

ランダム I/O に使用したプログラム→ rndtest.c

おわりに

この記事の目的は、microSD の性質あるいは MLC(マルチレベルセル)Flash 一般の性質をつかむことを目的としている。そして個々の製品の比較は、どれぐらいのバリエーションがあるか調べることを目的にしている。情報はすぐに陳腐化する。いま現在参考にするのはともかく、半年ぐらいたってしまえば役に立たないと思う。

また、ランダム I/O 性能もこのデータのみがすべてではなさそう。微妙な最適化がなされていて、I/O パターンが違うと性能が違う場合がある。このデータでは、A-DATA と キングストンは同じような性能に見えるが、書き込み耐性の調査では、A-DATA が速かったり キングストンが速かったりする(しかも何倍も)。

性能の話はこれで終わり。書き込み耐性については、(とにかく壊れたらどうなるか見てみたいので)まだ続く...

追記

実は microSD というものは、MLC に決まっていると思っていたのだが ... A-DATA 1G/2G (Super) の メーカWebページには、SLC 採用と書いてあるし、Photo Fast 2G (EXTREME 150X)も東芝製SLCらしい。ということはキングストン(日本製) も同じはず。

確かに書き込みは速いようだが...それでも 4K の write はこの程度。それより SLC の書き込み耐性は MLC と 1桁違うらしいので、そっちの方がメリットなのかも。

追記:microSDとCFの違い

この一連の記事を書き始めるまでは、CF も microSD も似たようなものなのだろうと思っていたのだが、全然違うようだ。CF はプロあるいはセミプロのカメラマンの厳しいニーズがあって、相当に高性能な(あるいは高信頼な?)なものが出ている。A-DATA 16G speedy が 7000円弱で売られている一方、SanDisk EXTREME III 8GB が 2万円弱で売られていて(たぶん)人気を保っている。

CrystalDiskMark 2.1 の結果を拾ってきたのだがこんなかんじ。(条件はいろいろ違うので参考)


SanDisk EXTREME III 8GB:

--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
<../link.cgi?http://crystalmark.info/>
--------------------------------------------------
Sequential Read : 32.284 MB/s
Sequential Write : 24.065 MB/s
Random Read 512KB : 32.196 MB/s
Random Write 512KB : 11.053 MB/s
Random Read 4KB : 6.476 MB/s
Random Write 4KB : 0.151 MB/s
Test Size : 50 MB

A-DATA 16G speedy:
--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
<../link.cgi?http://crystalmark.info/>
--------------------------------------------------

Sequential Read : 14.871 MB/s
Sequential Write : 7.124 MB/s
Random Read 512KB : 14.885 MB/s
Random Write 512KB : 1.806 MB/s
Random Read 4KB : 7.859 MB/s
Random Write 4KB : 0.018 MB/s

Test Size : 50 MB


シーケンシャル性能がまったく違うが、Random Write 4KBはそれ以上に違う。カメラのニーズでこういう性能が必要とは思えないから、別のニーズ(産業用機器?)に答えるためだろう。

ちなみに、CF は 333倍速(50MB/sec)の表記のものがある。が、規格上は 888倍速(133MB/sec: UDMA6)まであるから、まだまだ持ちそうだ。→ ウィキベディア

あと、同じ容量でも値段がまったく違うこともあって、ニセモノの存在が大きな問題らしい。

性能とは関係ないが、ついでなので書いておくと、microSD は、取り扱いに気をつけるべき点が多々ある。

まず接触不良。接点の面積が小さいためか接触不良が起こりやすい。それに、あまりに薄いパッケージ(1mm)に積層されたチップが入っているのだから、力を加えるとか厳禁だと思う。-- やろうとは思わないが、割ることさえ簡単にできそうだ。さらにいうと端子がむき出しだし、静電気にも気をつけなければならない。あまりそれ自体を抜き差しせずに、ケイタイや各種変換アダプタに入れたまま使うのが正しい使い方のように思う。

ウィキベディアの SDカードを見ると、SDカードやminiSDカードは、基板にLSIを載せた構造らしい。たぶんモノによって強度がマチマチだと思う。microSD はどうか? そんなには差がないんじゃないかと想像。トランセンドは、データシートを公開していてそこには、

Bending 10N
Torque 0.10N*m , ± 2.5 deg max
Drop test 1.5m free fall

それが具体的にどういうことなのかよくわからないが、一応転載。

それに比べて CF は相当取り扱いが楽そうだ。コネクタもピンで耐久性ありそうだし、しかも露出しないようになっている。厚みも 3.3mm と結構あって丈夫そうだ。

eeePC の SSD

さらについで。 拾ってきたeeePC の SSD のデータ

--------------------------------------------------
CrystalDiskMark 2.1 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 34.195 MB/s
Sequential Write : 19.897 MB/s
Random Read 512KB : 33.885 MB/s
Random Write 512KB : 10.744 MB/s
Random Read 4KB : 7.676 MB/s
Random Write 4KB : 0.152 MB/s

Test Size : 50 MB


本体の SSD は、OS をインストールしても問題ない性能レベルのものだ。信頼性や耐久性についてはわからない。SSD のコントローラはシリコンモーション社製らしいが、詳しいことは知らない。

この記事によると、コントローラは Silicon Motion SM223。そして、SM223 は トライセンドのCF(266X)にも使われているとのこと。さらに、SSD にも SM223 が使われていることがあるらしい。

↑のページで出てくるPHISON社を見てみると、PS8005とか SD カードコントローラが見つかった。この会社データシートまで公開している。こういうものを使っていれば、(ピーク)性能は、Flash メモリの種類と数でだいたい決まりそう。ただ、信頼性や耐久性については ファームウェアで決まるものでデータシートを見てもわからない。




性能まとめ(+追記)

シーケンシャル I/O

100MB のファイルを 作成し 読み込む性能。OS は Linux(powerPC 266Mhz) 、ファイルシステムは FAT16(2Gまで)、FAT32(4G 以上)。



typewrite (MB/sec)read (MB/sec)size (256KB単位)
A-DATA 1G
=上海(オ) 1G
4.6715.293886
キングストン 1G
(TAIWAN)
4.7815.263886
A-DATA 2G
=上海(オ)2G
7.9615.297788
PQI 2G7.9414.307788
キングストン 2G7.3515.517680
Photo Fast 2G7.3515.907680
SanDisk 2G bulk4.439.397754
Silicon Power 2G3.919.217754
トランセンド 2G5.167.987802
KINGMAX 2G5.379.067658
A-DATA 4G14.0815.215354
SanDisk 4G11.3815.315546


ランダム I/O read

次に、100MB のファイルを使い 100MB 分ランダムに read する時間。単位は秒、I/O サイズは、1M,256K,128K,32K,4K。なお、ファイルシステムは、 ext3 にしている。



I/O サイズ→1M256K128K32K4K
A-DATA 1G
=上海(オ) 1G
5.9106.1436.4247.64124.212
キングストン 1G
(TAIWAN)
6.0486.1826.4978.63325.237
A-DATA 2G
=上海(オ)2G
6.0086.2586.6807.70924.790
PQI 2G6.2396.5016.7847.76725.122
キングストン 2G5.6035.8876.2227.32425.970
Photo Fast 2G5.6635.8886.2257.32825.921
SanDisk 2G bulk10.31010.57910.98712.20132.568
Silicon Power 2G10.28710.56711.04012.16832.433
トランセンド 2G12.44112.65513.02314.20533.370
KINGMAX 2G10.39510.73711.02312.35030.542
A-DATA 4G5.5675.9036.1677.20022.848
SanDisk 4G5.8226.0836.4167.66527.947




ランダム I/O write

最後に、100MB のファイルを使い 10MB 分ランダムに write する時間。I/O サイズは、read と同じ 1M,256K,128K,32K,4K。


I/O サイズ→1M256K128K32K4K
A-DATA 1G
=上海(オ) 1G
3.4305.6278.56213.032130.487
キングストン 1G
(TAIWAN)
3.4895.7168.81813.007132.447
A-DATA 2G
=上海(オ)2G
3.4477.98112.80221.872245.856
PQI 2G3.2588.41911.48122.750258.058
キングストン 2G3.6409.09513.16432.675251.279
Photo Fast 2G3.7027.80112.22629.388222.333
SanDisk 2G bulk4.74110.77116.88152.974410.973
Silicon Power 2G5.32610.23815.50254.403401.552
トランセンド 2G6.30312.49118.04154.984411.061
KINGMAX 2G6.55310.71616.08050.064372.829
A-DATA 4G2.7497.54211.66140.478312.626
SanDisk 4G3.2975.3309.81733.498272.333


補足
PQI , KINGMAX, A-DATA 4G, SanDisk 4G のデータ追加。これらはハブ経由で測定したので、若干低い値になっている。

データを見ると PQI = A-DATA 。裏面も同じ。KINGMAX は新たなパターン。

キングストン 1G (TAIWAN) を新たに追加。性能からみて A-DATA 1G と同じ。裏面も同じパターン。
posted by すz at 16:45| Comment(0) | TrackBack(0) | microSD関係

2008年03月26日

microSDカードの書き込み耐性(3)

前記事のmicroSDカードの書き込み耐性についてmicroSDカードの書き込み耐性(2)で、microSD が壊れるまで書き込みを続けようとしてきた。
だが、まだ壊すことができていない。

いくつかのコメントにあったが、損耗平均化アルゴリズム (wear leveling algorithms) で、書き込み先を分散することで、メモリ全体に書き込みが分散されるから、この程度の書き込みでは壊れないのだろうか?

そうであれば良いのだが、私は、メモリ全体に渡って書き込みを分散することはないと考えている。

その機能を作るとすると、MMU のようにマップが必要になる。2GB の メモリ全体をカバーするとすれば、65536 個のエントリが必要になる。それぞれのエントリには、マップ先を示す 16bit のエリアと 書き込み回数を記録する 24bit ぐらいのエリアが必要だろう。
合計で、384KB が必要で、更新頻度が高いから、RAM である必要がある。そして、その RAM は不揮発性であるか、カードの電源が OFF になってから FLASH に書き戻すとかする機能を持っている必要がある。

そこまでの RAM 容量と機能を持っているのはあまり考えにくい。そういう機能ではなく、書き込み頻度の高いところを見つけて、そこの書き込み回数を記録して、ある程度の回数になれば、壊れるまえに代替ブロックに置き換えるのではないだろうか?

別の見方もある。もし完全に平均化できる機能であれば、FLASH メモリの書き込み耐性の問題はクリアしているといえるのだ。もっと大々的に宣伝されているはず。そうでないから不完全な機能だと思えるわけだ。

PC 用 ハードディスクの エラーレートを知っているだろうか?たとえば、HGST Deskstar E7K500のデータシートには、1/10^14 だと書いてある。同じ土俵の数字ではないだろうが、10万ブロック x 10万回だと 1/10^10 。ハードディスクに遠くおよばないが、容量が 1/1000 だとして、容量あたりという考え方をすれば、ハードディスクの 1/10 程度にまでなってくる。

ちなみに、損耗平均化アルゴリズム (wear leveling algorithms)があることを スペックに明記しているのは、A-DATA だけ。他はハードディスクと同じような不良ブロックマネージメント機能だと思う。

ちなみに、代替ブロックは、OS から見えないところに専用のエリアがあるはずだ。どれぐらいの容量があるかはわからないが、たぶんメモリ全体の1〜5%程度だと思う。(自信なし)
    代替ブロックの場合もマップは必要で RAM である必要がある。
    エントリのサイズが増えるが、メモリ全体の 5% しかないなら、32KB ぐらいで済みそうだ。

    また、RAM は不揮発性である必要がない。代替する毎に書き込みしても、書き込み頻度はあまり高くない。


追記:↑の考察はそうとうに甘かったようだ。入れ替える方法ならば、メモリ全体を使える。詳しくは↓を参照のこと。

どういうテストをすれば壊れるのか?

キングストンなどは 5000万回も書いても壊れなかった。どんどん代替プロックが置き換えられているとも考えられるが、Write Back キャッシュになっていて、書き込んだ回数 != Flash に書かれた回数という可能性もある。

いろいろ考えたのだが、書き込んだら確実に Flash に書かれるように 1回の書き込みサイズを 1MB にすることにした。1MB ものキャッシュを持っているとは思えないので、大丈夫だろう。

それは良いのだが、1MB もの領域を書き込んで、確認のために読み込むとなると、相当時間がかかる。だいたい 1万回書き込むのに 1時間前後。100 万回でも 4 日のオーダになる。

ここまできたら意地である。何日かかろうともやってみようと思う。


  • プログラム、flashtest2.c
    - M,K の指定ができるように若干改造


このプログラムで、まずは、300万回書き込んでみることにする。

ターゲットは、いままで使ってきた 上海問屋オリジナル 2GB 、キングストン 2GB 、A-DATA 1GB 。


    現在の状況
  • 上海 2GB 121万回 エラーなし。
  • キングストン 2GB 118 万回 エラーなし。
  • A-DATA 1GB 116 万回 エラーなし。


6 日やってこの状況だ。300 万回まで一週間以上かかる。300万回をクリアしたとしても、まだまだ続ける予定。

結果は、このページの追記に記載する。

おまけ

実はコメントを見て驚いたことがある。

多くの人が、書き込みを平均化するのに、空きエリアから代替するブロックを取ってくると考えているようなのだ。

結論から言うとそのようなことは不可能だ

空きエリアは、OS のファイルシステムが管理する。そして、その情報を、DISK に書き込まずキャッシュするのが普通なのだ。

たとえ、microSD 側が、FAT ファイルシステムの構造を知ることができても情報が最新である保証がない限り、どこが空いているか確実に知ることはできない。つまり、最新の情報は OS しかもっていないから、どこが空いているか正確にはわからないのだ。

もし、使用しているエリアを使ってしまえばデータが化けてしまうわけで、そのような仕組みを入れることは不可能なのである。

ウェアレベリング機能

コメントで教えてもらったウェアレベリングをググってみた。

ウィキペディア の
NAND型フラッシュメモリ
がわかりやすいと思う。

実際の例として、業界初のメモリ管理機能内蔵フラッシュメモリがヒットした。
東芝も LBA-NANDというウェアレベリングをサポートしたチップを出している。

たとえば、ある一定の書換回数に至ると、自動的に書換え回数の少ない領域とデータとアドレスを入れ替えるというもの(特許になっていていくつか方式がある)らしい。

なるほど、入れ替えるならば、空きエリアなどファイルシステムが管理する情報に依存せず実現できる。

入れ替える単位は、たぶん ブロックサイズなのだろう。ブロックサイズが何KB かわからないが、4K ページ x 64 とすると、256 KB 。2GB なら、8000 個ぐらいある計算。8000 個を順番に使うのなら、20万回でエラーになるとしても、1MB を 4億回書かないと寿命に至らない。300 万回程度の書き込みでは何もおこらないだろう。

フラッシュメモリは何日で壊れる? ウェアレベリングの仕組みというページを見つけた。ここでは、SanDisk の CF の仕組みを解説しているのだが、OS が空きエリアを CF に通知しないとウェアレベリングに使うプール(Erase Pool)が増えない。非対応の OS だと 3% の代替ブロックが使えるに過ぎない。ウェアレベリングにもいろいろあるようだ。

空きエリアが多いほど... と考えている人は、ひょっとして SanDisk の CF の仕組みを想定しているのかも知れない。
普通に使う範囲ならば、空きエリアは関係なく、一度も使ったことのないエリアということになる。
パーティションきりなおして、小さくしておけば耐性があがるかも。

といっても、各社ウェアレベリングは特許にしているだろうから、方式はマチマチになると思う。一般化してしまうのは無理がありそう。日立の入れ替えるという方法がもっとも良いと思うが、日立の特許で他のメーカは使え(and/or わ)ないのかも。


あまり深く考えてなかったのだが、普通の不良ブロックマネージメント機能で、5% の代替エリアを持っていると仮定しても、2000万回書き換えられる計算。前のテストで、Write Error を起こしたことがある上海 2GB なら何らかのエラーになる可能性はあるが、300 万回ではなにも起きないかも。一応 300万回 x 2 の合計 600万回やってみてなにもなければ、テストをやめることにしよう。

やはり意地である。理想的なウェアレベリング機能でなければ、壊すことは可能そうだ。ただ 300万回では話にならなさそうだ。クリアしてしまったら、再検討してトライしてみることにする。

おまけ2
上海問屋オリジナル 1G/2G は、A-DATA my Super 1G/2G の OEM らしいことがわかった。

裏面に浮き出ているパターンみたいなのがそっくりだったので、デバイスのサイズを見てみたら、まったく同じだった。

1G 994816 KB
2G 1993728 KB

3種類調べていたつもりが、ほぼ2種類(一応 1G/2G の違いがある)だったとは、ちょっとショック。

おまけ3:手持ちの microSD の性能


write read size
A-DATA 1G 4.67 15.29 994816 (3886 x 256)
A-DATA 2G 7.96 15.29 1993728 (7788 x 256)
キングストン 2G 7.35 15.51 1966080 (7680 x 256)
Silicon Power 2G 3.91 9.21 1985024 (7754 x 256)

※ 上海問屋 1G は、A-DATA 1G と同じ性能 (2G は未測定 )

size の単位 KB
read/write の 単位 MB/sec ( 1024x1024 /sec )

テスト内容
write 100MB のファイルを write
- キャッシュを(ほぼ)書き出すまで
read 100MB のファイルを read
- いったん umount し DISK から読み出す
テスト環境 玄箱/HG Linux(自分改造版)
USB アダプタ SDMMC M121 (14cd/6700)
ファイルシステム FAT16
- クラスタサイズ 1G -> 16K / 2G -> 32K
microSDの性能についてに続く

追記

1MB では、秒間 3 回ぐらいしか書けない。これではラチがあかないので、もう少しなんとかしたい。

秒間 3回でも 1MB なので、3MB/sec で Write + Read していたことになる。転送性能から見てこれぐらいが精一杯。

一応 4K ページ・256K ブロックの Flash だと仮定しよう。
おなじ 1MB の領域を使うとしても、256 K バイトおきに、先頭の 数キロバイトのみ書き込みしていっても同じ効果になりそうだ。

中断して、新プログラムに変更することにする。


    1MB の write 最終状況
  • 上海 2GB 210万回 エラーなしで中断
  • キングストン 2GB 156 万回 エラーなしで中断
  • A-DATA 1GB 146 万回 エラーなしで中断



  • プログラム、flashtest4.c
    - n バイト間隔で m バイトの書き込みとチェックができるよう変更
    - チェックの方法を書き込む前に、前のデータが期待するものかどうかをチェックするように変更。



    現在の状況 (1MB に対し 256KB 毎に 32KB の write 4回分)
  • 上海 2GB (= A-DATA 2G)
     1万回に 4分 40 秒
     1万回に 16分 20 秒  (42万回時)
     593 万回から 最初の USB アダプタに変更。 (1万回に 23分)
     754 万回 時に、データ化け(例によって USB アダプタの問題)
     →そのまま中断
  • キングストン 2GB
     1万回に 36分
     1万回に 51分 (5 万回時)
     329 万回(中断)
  • A-DATA 1GB
     1万回に 5分 40秒
     1万回に 16分 20 秒 (41万回時)
     1000 万回 ノーエラー終了


これだと、上海/A-DATA は、一日で 250 万回ぐらいになりそうだ。とりあえず 1000万回を上限にテストをスタート。

まだはじめたばかりに近いのに、どんどん遅くなっている。ひょっとして、エラーが頻発していたりするのだろうか?

ようやく 1/2 の 500万回まできた。性能は安定しているようだ。
しかし、なにも起こらない。最後まで行ってしまう予感。


キングストンは遅い。こういう書き方をされるのは苦手なようだ。

追記

ここに来て、上海/A-DATA (1G/2G, Super) は、SLC であるということを知った。そして、キングストン 2G (日本製)も。

SLC は MLC と比べて書き込み耐性が 1桁違うらしい。なかなか壊れないのもそれが理由かも知れない。

ちなみに 8GB は確実に MLC 。4GB もたぶん MLC 。SLC だけを調べてなにかわかったとしても 4G/8G の特性まで一般化できない。

4GB のテストは、4GB が1500 円を切るようなことがあればやってみることにして、今は 2GB 。SanDisk 2GB bulk は、A-DATA とも キングストンとも特性が違うようなので、(このテストが終わったら)試してみようと思う。

それはともかく、あまりになにも起きないので、上海 2G に対して、最初に使った USB アダプタに切り替えてみようと思う。

USB アダプタ SDMMC M121 (14cd/6700) について

少しばかりコレについて説明しておこうと思う。

14cd/6700 は、USB のベンダID/プロダクトID。SDMMC M121というのは、USBからみえるベンダ名。相当変であるが、USB アダプタのチップがそう言ってくるわけで、とりあえずこれを名前にしている。
ちなみに、このベンダには、14cd/6600 というのがあって、それは、ベンダ名: Super Top プロダクト名:USB 2.0 IDE DEVICE を返すらしい。しかし、Super Top というベンダの Home Page は見つけられていない。


実際の製品としては、FUJITEK microSD超小型カードリーダー。それ以外の FUJITEK アダプタにもこのチップが使われている。また、GREEN HOUSE GH-CRMR1-S*Aシリーズも同じもの。なんと 0.82g の軽さ -- microSD を装着しても 1.22g 。

このアダプタ、これだけのテストでエラーを出していないし、小型なので気に入っている。ただいくつか不満な点もある。

ひとつは、最大性能があまり高くない(らしい)こと。Photo Fast とか 150x (22.5MB/sec)らしいが、read で16MB/sec ぐらいまでしか出ていない。たぶん 最大クロックが十分ではないのだろう。実用上はぜんぜん問題ないが、性能テストするには不十分なのだ。

もうひとつは SDのイレーズ機能がないらしいこと。パナソニックの SDformatter には、イレーズするという機能がある。しかし、この USB アダプタだと "デバイスにイレーズ機能がありません" と言われてしまう。ひょっとして、A-DATA などイレーズすることで、ウェアレベリング機能に対して空きエリアをリセットできるのではないかという気がしていて、イレーズをやってみたいのだが、それが出来ない。まぁイレーズ機能があるアダプタなど パナソニック純正以外にあるのかどうかも判らないのだが、少々残念。

電子工作ネタ
一般のUSB アダプタでは完全に初期化できないなら、イレーズコマンドを発行して SDカードを初期化し、フォーマットする。そういう装置を作るのもいいかも知れない。



A-DATA 1G 1000万回達成

なにもおこらず 1000万回達成してしまった。キングストンは遅く その時点で、329万回まで。A-DATA 2G はエラーが出るアダプタで、やはりというか754 万回にエラーが出た。

ちなみに、1MB 相当ということにしたので、4ヵ所書いて 1回 にしている。トータルでは 4000万回書いたのだが、なにも起きなかった。

これで終わりにしたいところだが、テストしたカードは実用目的には使えないし、マシンも遊んでいるので当面続けようと思う。

実は HUB を買ってきた。テストを 1台に集約して、ずっとテストし続けられるように。カードも SanDisk 2G を追加。テスト方法も少々変更する予定。1MB (4ヵ所) から 10MB (40ヶ所)に広げてみる。

地味な話題なので、経過報告は、ここに追記していく。


    10MB に対し 256KB 毎に 32KB の write
    (前回と違い 1 write を 1回と数える)

    現在の状況
  • 上海 2GB (= A-DATA 2G)
     4万回に 15分 ( 192万回時 )
     8000 万回(断念)

  • キングストン 2GB
     4万回に 36分 ( 72万回時 )
     180 万回 で リードエラー (ついに限界)
     その後、書き込みはできるが、すぐ読めなくなることを確認。
     ファイルを変更してテストをしてみることに。
    → 166 万回で リードエラー
    (終了) 
  • A-DATA 1GB
     4万回に 56分 ( 44万回時 )
     204 万回 で リードデータ不一致 (電源不安定が原因)
     2820 万回(実行中)
     
  • SanDisk 2GB bulk
     4万回に 50分 ( 52万回時 )
     72 万回 で リードデータ不一致 (電源不安定が原因)
    168万回で ライトエラー (〃)
    208万回で ライトエラー (〃)
     3312 万回(実行中)



  • キングストンが若干速くなり、A-DATA 1G がすごく遅くなっている。上海 2G (A-DATA 2G) は変わらず。4ヵ所→40ヶ所に変更したのが関係しているのかも。
  • ちなみに、前記事コメントに従い、空き領域を 0 にしている。(一応ほとんど1回は書いたという状態)
  • USB アダプタはすべて、SDMMC M121 (14cd/6700)


SanDisk 2G が 72万回でデータエラー!

なんと 72万回で 書き込んだはずのデータと一致しないというエラー!

で、ファイルを読み込んでチェックしてみたが、正しい。こういうのは想定外だ。何度かおきるだろうから、再実行して様子見。

キングストン 2G が 180 万回で リードエラー!

お、あらためてファイルを読み出してみると、やはりリードエラー。

dmesg では複数のセクターでエラーが記録されている。

セクタ# (256KB 単位)
2131672 4163 -- テストでのエラー
2120888 4142 -- ↓ ファイル読み出しでのエラー
2120896 4142
2120896 4142
2121400 4143
2121408 4143



microSD (というか NAND Flash)は、一般に ECC を持っている。→ ググる
だから、書き込んだデータが化けてしまったとき正しいデータでなかったらエラーになる。
このテストでエラーになったということは、書き込んだ直後はエラーでなかったものが、2 秒後には化けてしまったということ。
そして、複数の場所で リードエラーがおきたということは、テストで気が付かなかっただけで、ほかのところも疲労しているということ。

ちょっと気になったので、テスト中のほかの microSD も確認してみたが、リードエラーが起きたのは、これだけだった。

ALL 0 のデータを書き込んでみたら書けたので、再度テストしてみたが、途中で止めて ファイルを読み出してみるとやはりリードエラー。代替もできない状態で 劣化したブロックを使っているようだ。

では、疲労していないはずのほかのファイルに対してテストするとどうなるのか? 代替ブロックはもうないはずで、メモリ自体の耐久性がわかるはず。

ところで、書き込み直後は OK でも 2秒後には read error になるケースが出てきた。このテストでは、ほかにもそういうところが出てきている末期的状況になるまで気が付かない。それでは困るので少々工夫しようと思う。

4万回毎に どこまで進んだか表示するようにしているが、このときに デフォルト 1分間の sleep を入れる。こうすることで、その間データを保持できないところがあれば発覚するようにした。

プログラム→ flashtest5.c

本来は、もっと長期間持たなければダメとしたいところだが、それではテストにならない。かなり劣化が進まないと確認できないことに注意。

SanDisk 2G が 通算168万回で ライトエラー!

dmesg で見てみるとジャーナルの I/O でエラーになっている。

それにしても、なんかこれだけ変なエラーがおきている。データ化けもそうだが、ライトエラーなんてものが起きるのはおかしい。ひょっとして、接触不良とかではないか。

一回取り外して、抜き差しして テストを再開してみることに。

通算208万回でもライトエラー。dmesg のエラーを冷静に見ると...USB レベルのエラーが先に起きている。

原因として、HUB のこのポートだけおかしいとか、USB アダプタがおかしいとか、あるいは microSD がレスポンスを返さないから USB アダプタの動作が変になったとか。まぁいろいろ考えられる。

とりあえず、USB アダプタを変えてみる。安物だから 不良品だったのかも知れない。

A-DATA 1G が 204万回でデータエラー!

SanDisk 2G で最初に起きたデータ不一致と同じ現象。これはもう Hub か、Hub を使ったことでタイミングが変わったのが原因だろう。いずれにせよ USB レベルの問題で microSD は関係なさそう。

とりあえず再開

実は、使用している Hub は AC アダプタがつけられるタイプで、AC アダプタ(5V 2A)で電源を供給したら、この現象は収まったようだ。
よくよく考えたら、ホストマシンは 玄箱/HGで ACアダプタタイプに改造したもの。5V の供給は DISK も含め 全部で 2A 。たぶん 5V の供給が不足して不安定になったのだろう。


それにしても、Hub をつけて 4 つ同時実行にしたらいろいろ起こりすぎる。データ不一致が起きても、1回ぐらいは再読み込みして続行しないと 放置して結果だけ見るようなことができない。

再度、少しばかりプログラムを変更することにしよう。
プログラム→ flashtest6.c

キングストン 2G が 166 万回で リードエラー!

ファイル名を変更してから 166 万回の write -- 1/40 すると、 4.2 万回。

最初の リードエラーのように あとで読み出すと複数(今回は 2ヶ所)のリードエラーが起きた。

キングストン系については、代替ブロックを使い尽くしてしまえば、書き込めても、読めないところが増えだす。
そして、読めるか読めないかは時間が立たないとわからない。

ただし、かなりの量の書き込みをしないと、代替ブロックを使い尽くすところまでは行かない。

記録を集めれば、通算何回 write したかは分かるのだが、テスト方法を何度も変更しているので、基準になるような数字にはならない。

新しいので、やってみても良いとは思っている。が、またテスト方法を再検討するようなことになると無駄になるので、他のカードがどうなるか見てから決める予定。


書き込んだ直後では本当にデータが保持できるのかどうか分からないような特性だと、どういう基準で、代替ブロックに変えるのか気になってくる。書き込み上限回数を設定しているのなら問題なさそうだが、書き込みでエラー検出のみだと、メディア全体が寿命に至らなくてもリードエラーが出てくる可能性があることになる。

読めなくなるのが、ファイルのデータなら1つのファイルが途中までしか読めないようなことになるのだが、ディレクトリエントリならそのディレクトリが全滅するかも知れない。ただし CHKDSK とかで復旧できそう。FAT なら ミラーがあるので大丈夫 --- 昔はそうだったと思うのだが、今は違うはず。アクセスしていないのに読めないファイルが出てくるんじゃないかと思う。そして、SUPERBLOCK (= BPB) なら全滅。

さて、このタイミングで他の カードが読めなかったりしないかチェックしてみた。が、大丈夫のようだ。

なかなか 上海(A-DATA) 2G は壊れない。連続書き込みという使い方では丈夫なようだ。性能も良い。ただし、製品の一つの面しか評価していないことに注意が必要。たとえば書き込んでいる最中、あるいは書き込み終わったすぐあとにカードを抜いたりするのに弱いとか弱点があるかも知れない。

A-DATA 2G が 8000万回達成!

8000 万回までやってみたが無問題。完成度が高い ウェアレベリングが実装されているのだろう。



さらにテスト中

A-DATA 2G はやめてしまったが、A-DATA 1G と SanDisk 2G は実はまだテストをやっている。

でそれぞれ既に 1億回突破。壊れるような気がしないが、まぁやれるだけやってみる。


  • A-DATA 1GB
     4万回に 56分 ( 44万回時 )
     204 万回 で リードデータ不一致 (電源不安定が原因)
     1億2176 万回(実行中)
     
  • SanDisk 2GB bulk
     4万回に 50分 ( 52万回時 )
     72 万回 で リードデータ不一致 (電源不安定が原因)
    168万回で ライトエラー (〃)
    208万回で ライトエラー (〃)
     1億7396 万回(実行中)
posted by すz at 02:12| Comment(121) | TrackBack(0) | microSD関係

2008年03月07日

microSDカードの書き込み耐性(2)

microSD (や SD/miniSD)は、いったいどれぐらい書き換えられるものなのだろう? 実際に調べてみることにした。


誤解のないように説明しておくと、知りたいのは局所的に書き込み回数が多い場合どうなるのかということ。書き込み回数が多い場所はどうしてもできる。そこが 10万回〜数十万回でダメになるのかどうか? もっと書き込めるならいったいどこまで書き込みできるのか? このことについて調べている。

また、ダメになった後はどうなるのか?というのも知りたいのであわせて調べている。


前記事では、こういう動機で 準備として 不要になった 64MB miniSD でテストを行い、次に 最初のテストとして 上海問屋オリジナル 2GB microSD のテストをした。

結果だけ簡単にまとめておくと

  • 64MB miniSD

    10万回の書き換えに 1時間弱
    510万回の書き換え後 write エラー
    write エラー後は、どこを書き換えても すぐに write エラーが発生し使えなくなった。

  • 上海問屋オリジナル 2GB microSD

    10万回の書き換えに 30分ぐらい
    1820万回の書き換え後 write エラー
    write エラー後も書き換えることができたが、20万回で 2回目のwrite エラー
    他の場所を書き換えてみたが、25 万回で write エラー
    (※)最初の write エラー までに 2 回、
    書き込み内容が化ける現象が発生した。(原因不明)
    (その後のテスト)
    10万回の書き換えに 13分 (アダプタ SDMMC M121)
    性能 100MB 書き込みに 38.9 秒 (2.6 MB/sec) (注)壊した後
    性能 100MB 書き込みに 14.1 秒 (7.0 MB/sec) (注)未使用領域



書き込み内容が化ける件については書き込み耐性とは関係なさそう、でもイヤな問題なので別途考察することにしよう。

2つ目のターゲットは、キングストン 2GB miroSD。カードにJAPAN の文字がある。キングストンは東芝製のチップを使っているらしい。

  • キングストン 2GB microSD(現在テスト継続中)

    10万回の書き換えに 14分
    5620万回の書き換えOK。(テストが無意味だった可能性高)
    (※)最初の write エラー までに 3 回、
    書き込み内容が化ける現象が発生した。(原因不明)
    2420万回から、USB アダプタ変更(SDMMC M121)
    → 10万回の書き換えが 5分に短縮
    性能 100MB 書き込みに 14.2 秒 (7.0MB/sec)



そう、書き込み内容が化ける問題が、こいつでも起きてしまったのだ。

起きたのは 510 万回書き換えた後。化けたパターンは、

PAGE: 8 (2048)
00: 68 1f 63 63 63 63 63 63 63 63 63 63 63 63 63 63
01: 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63

2回目は、1710万回書き換えた後。化けたパターンは、

PAGE: 4 (1024)
00: 1d 78 94 94 94 94 94 94 94 94 94 94 94 94 94 94
01: 94 94 94 94 94 94 94 94 94 94 94 94 94 94 94 94

3回目は、2420万回目。パターンも同じような感じ。

(1回目だと)全部 0x63 であるべきところが、0x68,0x1f になっている。
512 バイト単位で、先頭の 1〜2バイトが化けるというのがこれまで起きた4回の共通パターン

今回のテスト環境は、玄箱/HG にインストールした Linux(PPC)。
OS が Linux であるということと、USB のカードアダプタが同じというのが共通点。

前記事では、Linux や Vmware を疑ったが 、少なくとも Vmware は関係ない。Linux も PPC (Big-Endian)になったので大分違うとはいえる。Linux の ファイルシステム(vfat)のバグという可能性が残るが、随分使われているものだから、たぶん違うだろう。

今疑っているのは、カードアダプタ。microSD カードの中身がたまたま同じところの製品で特性が似ていたという可能性はあるが、microSD を疑うのは保留。このテストが終わったら複数のカードアダプタでテストしてみることにする。幸い 書き込み耐性の評価に使ったカードでも 完全に壊れたわけではないので、使わなかった領域を使ってテストできる。テスト用のプログラムも広い領域を使うようなものにすることにする。

とりあえずプログラム作成→flashtest2.c
ちょっと変更して、データを書く位置を ずらしていくようにした。
ずらすサイズ (個数)を 1000 にすれば、10万回しか書けなくても 全部で1億回の転送ができる。
それは良いのだが、vfat だと ディレクトリエントリが何度も書き換えられるので都合が悪い。ext3 で使ってみることにする。

sar -d で確認。

 DEV tps rd_sec/s wr_sec/s
20時50分01秒 dev8-0 412.34 1647.75 1652.56
21時00分01秒 dev8-0 414.59 1656.76 1661.53
21時10分01秒 dev8-0 415.52 1660.48 1665.27

秒間 103 回の write + read が出来ている計算で、100000回なら 970 秒 15 分ぐらいで済むはずだ。で実際も 15分弱で終わっていて、プログラムでの read / write しか出ていないことを確認。

これで、3000万回ぐらいやってみて、無問題なら結構安心。
最初に使ったアダプタが悪いか、疲労してきた microSD の特性か
と思うことができる。
→ 3000万回の転送は無問題だった。

一応、 最初に使ったアダプタで同じことをやるつもり。それで無問題だったら、疲労してきた microSD の特性だと思うことにする。
→ あまりに遅いので、300 万回でキブアップ。


USB アダプタによってこんなに性能が違うとは思ってみなかった。信頼性もかなり違うかもしれない。

どういう違いがあるのか。/proc/bus/usb/device の情報を書いておく。

最初に使っていた USB アダプタ (microSD 専用)
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=058f ProdID=6335 Rev= 1.02
S: Manufacturer=Generic
S: Product=Mass Storage Device
S: SerialNumber=058F011111B1
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=250mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms

2番目に使った USB アダプタ (microSD/SDHC 専用)
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=14cd ProdID=6700 Rev= 2.01
S: Manufacturer=SDMMC M121
S: Product=USB 2.0 SD/MMC READER
S: SerialNumber=845340272046
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms



2番目に使った USB アダプタは、
おそらく、このページにある fujitek のもの(380円)と同じ(ブランドは違う)。ちなみに、480円のへんな形状のUSB/SD変換アダプタを買ってみたのだが、同じチップを使っていた。

最初に使ったものは、MxPS(パケットサイズ)= 64 だったりして、性能的にあまりよくないものだということはわかった。
普通の USB A タイプコネクタで、本体が 結構厚い。コネクタメーカの microSDコネクタを使っていて、物理的な信頼性は高いかんじで、お気に入りだったが、性能や信頼性に問題があるとなると使いたくなくなってしまった。

2番目に使ったものがお勧めかというと、わからない。あまりに小さいので、少々使いづらい。また、あまりに薄いと接触不良がおきやすかったりするかも知れない。ついでに書いておくと、対応は、8GB までらしい。

さて、キングストン 2GB microSDは、なかなか壊れない。もうやめたいが、壊れた後どうなるのか興味があるので、もう少しがんばってみようかと思う。ひょっとして実際Flashへの書き込みはもっと少なくて壊れないとか想定外の理由があるかも知れないが、高速だし、なかなか良い製品だと思う。

それとは別に実はもう1つ microSD のテストを始めている。ターゲットは、A-DATA 。A-DATA の は、不良ブロックの代替だけではなく、損耗平均化アルゴリズム (wear leveling algorithms) に対応していることが書かれている。それだけでなく、FW を更新できるなんて一般ユーザには関係なさそうなことまで書かれている。ひょっとして特性も違うのかも知れないなんて思ってしまったものだから調べないわけにはいかなくなった。ちなみに、壊すことを前提に購入したので、安い1GB にした。


  • A-DATA 1GB microSD(テストが無意味だった可能性高)

    10万回の書き換えに 10分 (アダプタ SDMMC M121)
    1480 万回 OK 。
    性能 100MB 書き込みに 20.5 秒 (4.9MB/sec)



キングストン 2GB microSDが、なかなか壊れないので、microSD 自体でキャッシングされているのではないか?という疑念がわいた。

プログラムを若干変更。→ flashtest3.c

その上で、ファイルに対して 8KB x 1 の書き換えを行っていたのを 8KB x 5 に変更。8KB を10万回書く時間は 5分から 30分になった。

その後何回か試したところ、30分は 1回のみ。疑念は気のせいということに。


次に別の疑念がわいた。SDMMC M121は、まだ1回も write error を出していない。内部でリトライしているかも知れない。ダメになった上海問屋オリジナルを使ってどうなるか見てみることにした。

→ 280万回書き換えてエラーなし。その後 第三のアダプタに変更したが、計 400万回書き換えてエラーなし。
最初のアダプタで write error が出だしたのがうそのようだ。

100MB のファイルを書く時間を見てみるとかなり遅くなっているようだし、疲労しているとは思うのだが...

どうもいままでのテストの方法が甘かったようだ。

書き込むサイズを大きくしていって、時間がどれぐらいかかるか
調べてみた。以下は、1000回 write+read する時間(単位 秒)。

上海 2G キングストン 2G A-DATA 1G
8KB 7 7 7
16KB 12 100 11
32KB 19 100 21
48KB 91 100 30
64KB 138 100 41
96KB -- 100 60
128KB -- 200 95

上海 2Gは、48KB になると急に遅くなる。ルートディレクトリエントリの 8KB と ファイルへの write の 2 ヵ所しか書き換えていないため、2 個のバッファが WB(Write Back) キャッシュとして作用するのではないか? 消去ブロックサイズは 32KB ですなおな設計になっているような感じだ。すくなくとも今までのテスト write 回数 = Flash 書き換えになっていない。

キングストン 2G は、16KB から遅くなる。その後サイズを大きくしていっても時間は同じ。8KB以下のサイズでは WB キャッシュを持っていたりしそう。サイズを変えても 96 KB まで時間が同じということは、消去ブロックサイズがこのあたりなのだろう。

A-DATA 1G は、リニアに時間がかかるだけ。これまたよくわからない。128KB より多い量の WB キャッシュを持っていると考えるべきなのかも知れない。

とにかく、いままでのテストはダメだったようだ。上海 2G と キングストン 2Gは、48KB で write するようにすれば 内部の Flash が書き換わりそうだから、サイズを変えてテスト継続することはできる。ただ、テスト方法をもっと練ってやりなおしたほうが良さそうだ。

この記事の更新はここで終わりにしようと思う。次はリベンジということで、新たに記事を起こす予定。


おわりに

最後に、なぜ microSD に対して書き込み耐性のテストに踏み切ったのは何故かについて書いておこうと思う。

もちろん、常々興味があった。そして十分安くなったから。というのは背景にある。ここで書くのはそれ以外の理由。

なぜ microSDなのか

これから、大容量のものは別にして、2GB までのものは、microSD に収束していくだろう。今調べるなら、他のメディアを調べる意味はなく、microSD を調べるべきである。

もちろんこういう要素が大きいのだが、私の中では、もっと重要な理由がある。

それは、”CF や USB メモリ、SD/miniSD と比べて、製造の難易度が高く 実装のバリエーションが少ないだろう” ということ。少数の一流メーカしか製造できないなら、特性も似たりよったりになってくるのではないか?→ すなわち、結構特性を一般化できるはず→調査したデータが意味を持ってくる。

補足: microSD のサイズは、11mm x 15 mm x 1.0 mm 。東芝 が 2007年 03月28日に発表した 56nmプロセス 16G bit NAND型フラッシュメモリTC58NVG4D1DTG00は、12mm x 20 mm × 1.2 mm -- LSI より小さく薄いのだ。今は 8GB のものまであるが、いったいどこに入っていて、ちゃんと強度を保てているのか?不思議なぐらい。

ISSCC 2008レポートを見ると 16G bits(2G bytes)でチップ面積が 120平方 mm とか書いてある。microSD のサイズ (端子込みで 165 平方 mm) とさして変わらない。2GB ですら どういう風にチップが入っているのかあまり想像できない? まして 8GB は? -- もちろん 積層されている以外にないのだが ... 1mm の薄さにそれが入っていて、一般の人が扱えるだけの強度があるというのがとても不思議。

実装のバリエーションが少ないというのは、ほんとうらしい。
microSDの性能についてを参照

このようなことを考えたから microSD をターゲットに調査をしている。値段の関係で microSD しか調べられないが、一般的に microSDHC も調べた特性より高耐性になるだろうという予想はできる。

これから一般化してくるであろう SSD も 調べた特性より高耐性なものに収束していくだろうと思う。ただ過渡期において変なもの・雑な設計のものが出てくる可能性はある。

USB メモリはどうなるか、さっぱりわからない。それは実装があまりに多様だからだ。書き込み耐性の面でダメダメな実装も多いかもしれない。Flash のチップ内部で 不良ブロック制御を行っているものがあるが、そういうものが一般化されないと、書き込み耐性について一般化してコメントできるような気がしない。

なぜ興味を持ったのか

普通に Windosやデジカメで使った場合、安心できるか?書き込み回数が多い場所が 10万回〜数十万回でダメになるなら、あまり安心できない。もうすこし多くないと困る。

たとえば、1日に100枚の写真を撮るとすると、100日で最悪 10万回の書き換えが起きるところ(たぶんディレクトリエントリ)が出てくるかも知れない。そう考えると 10万回というのは多いとは言えない。

また、書き込み耐性を超えたらどうなってしまうのか? これも問題だ。データが壊れるとすれば、撮った写真がダメになってしまうのか?

こういうことが一般的に知りたい理由だろう。私もそういう観点で知りたいが、もっと別の理由がある。

ひとつは、電子工作的な観点。大容量のメモリ(RAM)を AVR とかにつなぐのは 配線の数が多くなるので、物理的に無理だったり、面倒だったりする。シリアルベースの Flash メモリをつなぐのは簡単だが、繰り返し書き換えられるのかどうか?

たとえば、ログを全体にわたってサイクリックに書き込むとする。10万回書き換えられて、1GB あるならば、通算で 100TB ものデータを書くことはできる。1MB/sec で書き込み続けても 3年以上持つ。

それは良いのだが、どこまで書いたかという情報をどこか固定の場所に書くとすると、そこだけ異常に書き換え回数が増えることになる。1000万回のオーダで書き換えられることを知っていれば、結構安心してこういう設計ができることになるわけだ。

実はもっと別の理由もある。それは、SSD に対する理想のファイルシステムはどういうものかを考えるということ。

簡単に言えば上のような制御をやってくれるファイルシステムということになる。ファイルシステムでは、zfs のように copy-on-write という概念がある。書き換えたデータを同じところには保存せず常に新しい領域を確保してそこに書く。ハードディスクだとランダムアクセスが遅いから、連続した領域に書くというのは性能を上げるために重要な技術なのだが、SSD の場合それは関係ない。しかし、領域全体を使い書き込み回数を平均化してくれるわけで、 copy-on-write という技術は SSD に対して別の理由で有利なわけだ。

それは良いのだが、最新のデータを示すポインタが必要で普通 SUPERBLOCK といわれるところに格納する。そこだけ極端に書き込み回数が増える。

書き込み耐性がいったいどれぐらいあるのかということが、ポイントになってくるのだ。あまりに低いと ハードディスク用の設計では不十分で SSD 専用の仕組みが必要になる。結論としてはこれぐらいあればまぁ、普通に使えそう。

相当に専門的な興味だと思われるかも知れない。でもそうではない。もう SSD というのはかなり身近になってきている。Flash に変わる不揮発性メモリも話題になっているが、当面は Flash だろう。Flash ベースの SSD をどうやって使えばよいのかということを考えるのは、普通に使う立場でも有用なはずだ。


microSDの性能についてで示したように、microSD (一般の MLC Flashも)は、4KB とか小さいサイズの Write が相当遅い。OS をインストールするような場合、書き込み耐性よりこっちの方がネックになりそうだ。そういう意味でも、連続した領域に書く copy-on-write ファイルシステムが望まれる。
posted by すz at 17:35| Comment(98) | TrackBack(1) | microSD関係

2008年02月26日

microSDカードの書き込み耐性について

microSD や (miniSD , SD) カードの書き込み耐性は、一般に 10万回〜数十万回ということになっているらしい。

本当にそれぐらいしか書き込みできないのか?限界を超えるとどうなるのか?ずっと気になっていた。最近大容量の microSD が安くなって来ているので、使い道がなくなった 64MB の miniSD カードで試してみることにした。

  • データを保存する nand FLASH 自体が 10万回ぐらいの書き込み耐性しかないのがこの回数の根拠だと思う。
  • ただ多くのカードは、損耗平均化アルゴリズム(wear leveling algorithms) やら、不良ブロックマネージメント機能やらを搭載していて、書き換えが集中するブロックの耐性を上げているようだ。だからファイルの作成・削除ができる回数はもっと多いはずだ。

テストの方法

Windows では、どのように書き込むのか調べようがないので、Linux を使うことにする。Linux では、O_DIRECT フラグをつけて open すると、キャッシュを使わないで read/write するようになる。これを使って、確実に書き換えるようにした。

その上で、指定したファイルの指定したオフセット(デフォルト 0)を 毎回違う内容で書き換え、書いたデータが同じかどうかチェックすることにした。


  • 本当は、ファイルを作ったり消したりするのが良いのだが、どこを何回書き換えるのか調べるのが面倒なので、このようにした。これなら、同じブロックが書き換わるはず。
  • テストプログラム→flashtest.c


テストの結果


  • テストは、8KB を書き換えることにした。だいたい 1秒間に 30回ぐらいの write and read ができた --- 10万回書き換える場合 1時間近い時間がかかることになる。


結果は、なんと! 515万回の書き換えができた。最終的には、 write でエラーになった。


  • エラーになった後、ls してみると、77777777.777 という名前のディレクトリが多数できていた。テストに使ったファイルは残っている。--- ルートディレクトリ・エントリが 0xffで埋められた結果だと思う。
  • エラーになった後は、テストを再開しても 1 回目でエラーになるようになってしまった。それだけではなく、新しいファイルを作れなくなった。--- ルートディレクトリ・エントリへの書き換えができなくなってしまったらしい。
  • fdisk でパーティションをずらしたりしてみた。特定のブロックだけがエラーになるのなら、ずらすことでまた書けるようになるかも知れない。実際にやってみると、fdisk 自体は成功するが、どこにずらしても フォーマット(mkfs.msdos) が失敗するようになってしまった。--- どうも カード全体が死んでしまったらしい。


考察

この miniSD カードは、(なんらかの)不良ブロックマネージメント機能をもっていたに違いない。そうでなければ、カード全体が死んでしまうことはないはずだし、なにより 500 万回もの書き換えに耐えることはないはずだ。

さて、500 万回の書き換え耐性というのは、十分なのか?というと微妙なところ。人がオペレーションしてファイルを置いたり消したりするには十分すぎる耐性だが、Linux のルートファイルシステムを作ったりするには不安がある。

  • Linux のファイルシステムは、パーティションの先頭の SUPERBLOCK を最も多く書き換える。どこが変更されても SUPERBLOCK が書き換わるのだ。30秒に1回程度書き換えがおきるとすれば、500万回書き換えできても 5年弱でダメになる計算。


おわりに

たった一例だが、どういうものなのか少しは判った気がする。ついでなので、最新の microSD カードも試してみようと思う。ずいぶん安くなったし、1つ壊してもこれからの安心が買えると思えば安いものだと思うことにする。

ターゲットは、今最も安い上海問屋オリジナルの 2G の microSD カード。

追記:現在テスト中

今、上海問屋オリジナル 2G microSD のテストをしている。
だいたい 10万回書き換えるのに 30分のペース。今 270万回の書き換えが出来ている。

どこまで行けるのかは、想像がつかない。不良ブロックマネージメント機能が多くの代替ブロックを管理していれば、500万回よりはるかに多くの書き換えが出来ても不思議はない。

一応、満足が行く耐性を 3000万回と考えていて、テストの上限も 3000万回としている。上限に達するまで、トータル 150時間もかかる計算だからテストが終了するまで数日かかる場合もあり得る。


- なぜ 3000 万回?
- 仮に 30秒に1回必ず書き込まれると仮定します。そうしたら 1500万分(28.5年)持つということになります。FLASH のデータ保持期間は 10年〜数十年らしいので、これぐらいもてば安心かなぁということです。
- なぜ 30秒に1回?
- Linux で通常のファイルシステムの場合、どこかが更新されたら SUPERBLOCKが更新されます。デフォルトでは SUPERBLOCK の更新間隔が 30秒に1回なのです。SUPERBLOCK 以外でも DISKキャッシュが書き出される頻度があって、これも 30秒に1回ぐらい。ガンカン書き込むようなことをしなければ、(ながい目でみて)最多で 30秒に1回と考えてよいと思います。
- もちろん使い方によっては、更新頻度がもっと高いところが出てくるかも知れません。O_DIRECT とか O_SYNC を付けて open すればこのテストのように短期間で ダメにできます。


上海問屋のユーザレビューについて

フォーマットに失敗するだとか、使えない、あるいはデータが化けるというレポートがいくつか見られた。

本当に初期不良だった可能性もあるのだが、単なる接触不良である可能性の方が高いと思う。というか実際に接触不良を経験した。

新品のPhoto Fast の メモリースティック PRO Duo アダプタを介して使ったのだが、フォーマットに失敗したりした。そして、抜き指しを何回か繰り返しているうちにちゃんと使えるようになった。

SD や miniSD ではそんなことは経験していない。microSD ほど小さくなれば、端子の面積も小さくなるし危険性が高まるのだろう。

特に変換アダプタを使う場合は接触不良に注意!

ちなみに、安物だから品質が悪いとは思っていない。こんな小さく薄いものを作れるメーカは限られているに違いない。どこか一流メーカの OEM のはずだと思っている。


追記:現在テスト中 - その2

現在 トータルで 690万回まで OK まだ継続中なのだが、ちょっと疑問が出てきた。

SD は、FAT16 など特別なフォーマット向けに最適化されているという事実。

コメントにあったように、ELM のページには、内部的には 512B ではなく 2KB でアクセスしていたりすることが書かれている。

ひょっとして、2,4,8..N KBのバッファを持っていて、それに満たないデータを何回買いても 実際にはバッファに書き込まれるだけではないか?

そういうおそれがあったので、一回に書き込むデータ量を 8KB にしてみたのだが ... それで十分だったのだろうか?

ターゲットの microSD にもともとされていたフォーマットは FAT16 だったのか FAT32 だったのか実はわからなくなっている。

少なくとも、それとは違う 2G のカードで FAT16 のものがあったことは覚えている。これも FAT16 だったのかも知れない。


さて、FAT16 の場合、アロケーションサイズ(クラスタサイズ)は、32KB にもなる。実際のFLASH への書き込みは、32KB 全部書き込まれて初めて発生するのかも知れない。

ただし、ぜんぜん違う場所への書き込みが発生すれば、カレントのバッファを書き出し始めるはず。(そうでないと仕様を満たせない)

そして、おそらく、高速化のためにバッファを複数持っているはず。複数といっても普通は 2 。3 以上になると、一般のキャッシュ制御と変わらなくなる。内部 FW が複雑になりすぎるうえに、メリットがないはずで 3 以上というのは考えにくい。

このテストでルートディレクトリ・エントリが壊れるほど書き換えたことで、実際に書き換えたエリアと、ルートディレクトリ・エントリの 2 ヵ所は書き換えることが判っている。

だから本当に書き換えているのだと思うのだが、ひょっとしたらテストプログラムが書き換えたはずの回数と実際に書き換えた回数が違うかも知れない可能性が若干ある。

さらに実は、もうひとつ懸念がある。このテストは、VMware Player を使った仮想 OS (Vine-4.2) で行っているのだ。ゲストOS が DISK に書き込むのは間違いないと思っている。ソースコードを見て確かめることさえできるから、本当に怪しくなったら確かめても良い。

それは良いのだが、VMware Player あるいは、ホスト OS 側がキャッシングしてしまう可能性がある。

Flash のアクセスランプが点滅しているし、秒間 60回ぐらいしか書き換えできていないから、大丈夫のはずだが、確信にまでは至らない。

そういうわけで、このテスト継続していくが、実際の書き換え回数と違うかも知れないことを覚えておいてほしい。


おまけ - Windows XP の設定について

以前は、Flash メモリなどを取り外したときに、「安全な取り外し」の作業が必要だったことを覚えて( or 知って)いるだろうか。そして、今はそのメニューが出ないことを。

この機能の切り替えは、コントロールパネル→管理ツール→コンピュータの管理で出てくるパネルの上で、ディスクの管理→ディスク1などのリムーバブルディスクの装置自体(ボリュームではなく左)のプロパティのポリシーで切り替えられるようになっている。

デフォルトは「クイック削除のために最適化する」でキャッシュを使わない。「パフォーマンスのために最適化する」を選ぶとキャッシュを使うようになり、書き込みの回数を減らすことができる。

Flash メモリを使うときは、これを選んだほうが良いのだが、「安全な取り外し」の作業をする必要が出てきて、ちょっと面倒。

キャッシュを使わないではなくて、キャッシュの寿命を 1秒とか コントロールできたほうが嬉しかった。



追記:ほんとうに Flash を書き換えているのか?

まず、Linux 内部で Flash を書き換えたかどうか検証してみた。

まず、使っている OS は vine-4.2 である。サーバ用OSとは違って システム負荷を調べるようなツールは充実していない。とりあえず、RHEL4 の sysstat のソースRPM をとって来て rpmbuild を使ってビルドしてインストールした。

次に /etc/init.d/sysstat start を動かして数時間放置。

そして、sar -d を使って DISK毎の I/O 状況を調べてみると次のようになった。(抜粋)

DEV tps rd_sec/s wr_sec/s
21時40分00秒 dev8-0 107.08 856.45 856.46
21時50分00秒 dev8-0 108.04 864.09 864.15
22時00分00秒 dev8-0 105.17 841.15 841.18
22時10分00秒 dev8-0 108.83 870.39 870.41
22時20分00秒 dev8-0 109.10 872.61 872.62
22時30分00秒 dev8-0 109.13 872.85 872.88
22時40分00秒 dev8-0 105.96 847.47 847.52


dev8-0 というのは、major 8 minor 0 というデバイスの意味で、/dev/sda のこと。この環境だと USB mass storage である テスト中の microSD を指す。

wr_sec/s は、1秒間あたりの Write セクタ数(512B単位)。rd_sec/s は読み込んだセクタ数 。tps は1秒間あたりの I/O 回数(read writeの合計)。
この情報で、平均 I/O サイズは 8KB ぐらいとわかる。全部がテストプログラムでの read/write だとすれば、10 万回の write + read をするのに 15.4 分で済んでいるはずだ。

ところが、プログラムのログは、次のように 10万回あたり 30.5 分かかっていることを示している。

02/27 21:58:56 :05800000 times -- OK
02/27 22:29:31 :05900000 times -- OK


どういうことかというと、テストでの write+read の組に対して余分な 8KB の read と write が発生しているということ。そして、この余分な read と write は ルートディレクトリ・エントリに対しての I/O ということになる。

なぜルートディレクトリ・エントリに対して I/O が必要かというと、更新時間を記録するためである。

- ただしこれは、O_DIRECT を指定したときだけの動作、普通はキャッシングするから read はしないし、更新時間も 30秒に 1回とかの頻度になる。
- O_DIRECT を指定したからといって、ルートディレクトリ・エントリまでキャッシングしないというのはなぜなのか? -- ちょっとわからない。


こういうように Linux 側でどういう I/O をしたかは分析できる。

Windows でも 管理ツール→パフォーマンス→システムモニタで調べることができる。+のアイコンでカウンタを追加する。追加する項目は、PhysicalDISK の DISK Write Bytes/sec 。対象とするインスタンスは(リムーバブルディスクは選択できないので)Total を選択する。別に C: もあるので、これも追加する。

で、みてみると、C: と Total が同じであることがわかる。どういうことかというと、Windows では 物理DISK として管理していないということ。もっとハードウェアに近いレイヤ(デバイスそのものか デバイスを仮想化したもの)で VMware Player に接続されている。こういう状況なら Windows でのキャッシングはないといえそうだ。

- Windows の中がどうなっているかは判るわけもないが、一般に OS での DISK のキャッシングは、物理DISK にたいして行われる。
- 論理DISK (パーティショニング後の仮想化されたディスク(のはず))を対象にするかも知れない。
- でもデバイスに対してのキャッシングはあり得ない。物理DISKというレイヤの意味がなくなる。


最後に残るのは、VMware Player でキャッシングしているかどうか。デバイスそのものを扱っているのならば、やろうと思ってもまずは、無理そうだ。

- VMware Player は、USB host コントローラを ゲストOS に見せている。
- Windows から USB host コントローラへのアクセス権利をもらって(奪って) そのまま ゲスト OS に見せているのだと思う。
- ただ、あくまで推測。USB mass storage のプロトコルとかもっと上位レイアのやりとりを使って 仮想 USB host コントローラに見えるようにしているかも知れない。
- ただそういう場合でも自分でキャッシングしたら問題が出る場合がある。-- 装置を切り離したときに、書いていないデータがキャッシュに残ってしまうかも知れない。

ここまで調べて、テストの結果は信用して良さそうという結論になる。

追記:エラー発生!

1000万回書き込めた後、データの不一致を検出。

不一致になったときのデータパターン

00: 54 e8 7c 00 da da da da da da da da da da da da
01: da da da da da da da da da da da da da da da da
02: da da da da da da da da da da da da da da da da
03: da da da da da da da da da da da da da da da da
          あと全部 da

先頭 4 バイトは書き込み回数。そして、残りの da というのは、書き込み回数 の 下位1バイト。
1 バイト目と 5バイト目以降の値は同じにならなければならない。
エラーが起きたときのログから、1バイト目(先頭)が 0xda であるべきなのが、0x54 になったということだ。


このデータ調べればわかるが、8138714 回を指している。実は 2 回目。1回目は、USB が disconnect になって、テストが中断されてしまった。そのときの、190万回を足している。


ただ、壊れ方が不自然。先頭の1バイトだけが壊れるというのは、いかにもソフトのバグのような感じだ。また、普通のカードは、ECC でエラー検出しているらしい。このカードも不良セクタマネージメント機能を持っているようだから(1000万回も書けたなら絶対数回は代替しているはず)データが化けてしまったら read error になるはずなのだ。

Linux あるいは VMware Player のなんらかのバグで、書き込む前にデータが化けてしまったと判断。データを正しいものに変更し、再実行することにした。

追記:2回目のエラー発生!

1740万回書き込めた後、データの不一致を検出。

不一致になったときのデータパターン

PAGE: 28 (7168)

00: ab 7a ba ba ba ba ba ba ba ba ba ba ba ba ba ba
01: ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba
02: ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba
03: ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba ba


2回似ているエラーになった以上、1回目の判断は怪しいということにしてあらためて考察してみよう。

512 B 単位の先頭の 1〜2 バイトが壊れたというのが共通するパターン。そして、保存されたデータ自体が壊れていて、read エラーにはならない。

なんだか、書き込みのデータ転送で microSD がデータを誤って受け取ったような感じがする。転送しようとした直後は、タイミングが厳しいとかなんらかのカード固有の理由があるのかも知れない。たしか CRC 付きの転送だったはずなので、ちゃんと調べれば、CRC 値が同じになるかどうかで判断できそうだ。

でも、転送で CRC をすり抜けるパターンでたまたまエラーが起きた ... というのもどうかという気がする。すり抜けなかったエラーは実は多数起きていてそれは、dmesg で確認できるメッセージとして表示されないだけかも知れない。そういうことはカーネルのソースコードを調べればわかるはず。

まぁ、ぜんぜん外していて、まったく違う理由かも知れない。理由を追うのは面倒だから事実だけに注目してみる。

この microSD 限定の話になるが、どうも 書き込みはいくらでも出来るように見える。ただ、書き込みでエラーが起きなくても正しいデータが記録されているとは限らない。

この点はハードディスクと違う。ハードディスクは、もっと信頼できる。そして、OS は (ハードディスクと同じ処理が基本なので)普通、正しく書けたかどうかデータを確認することまではしない。

確実にデータを保存したいケース(確率は低いようなので、本当に大事なデータの場合)は、いったん PC から切り離して、再接続し、MD5 とかチェックサムをとって確認する作業をした方が良いかも知れない。

上記のような壊れ方をした場合の考察
上記のようなパターンで壊れた場合、データが入っているところ(データブロック)が壊れたから上記のようになったわけだが、他の場所が壊れた場合どういう風にみえるのかについてもうすこし説明しておこう。(あくまで 512B のうち先頭の 1〜2 バイトが壊れたというケース限定、他の壊れ方まで説明するのは難しい)

FAT が壊れた場合)
たまたま FAT が上のように壊れると、更新したファイルとぜんぜん違うファイルのデータが壊れることになる。C でいうとポインタで一方向リンクを作っていたときにポインタの1つに変な値が入ったようなもの。こわれたリンクから先がめちゃめちゃになる。
OS がなにをしているかわからないのだが、FAT は 2 組あるので、chkdsk とかで復旧できるかも。(自信なし)

BPB (SUPERBLOCK相当)が壊れた場合)
FAT ファイルシステム覚え書きを参考にすると、先頭には、3 バイトの jmpOpeCode という部分があり、それが壊れることになる。ここに正しいデータが入っていないとおそらく、ファイルシステムが認識されない。普通の方法では復旧できないだろう。
ただ、ここだけが壊れたのが確実なら、正しい データにすればよいので復旧が完全に不可能というわけではない。

ディレクトリエントリが壊れた場合)
こういうケースでは、更新したファイルがあるディレクトリで、ファイル名が化ける結果になりそうだ。ダメージとしては小さい。



追記:3回目以降のエラー

2 回目でもうやめようと思ったのだが、それからしつこくやるとどうなるか興味があったのでやってみた。

3 回目は、2回目のエラーから 78万回で write エラーが起きた。4 回目はそれから 20万回で write エラー。エラーが起きたところは、前のデータのままになっていた。

いつまでも書けるのかと思ったが違うようだ。2 回目のエラーのときには既に限界になっていたようだ。

限界を超えると write エラーになり、しかも前のデータが残っているのというのは、たちの良い壊れ方だ。ただし、1 回目/2回目のようなことがあると write エラーで限界だとわかったときには、すでにいくつかのファイルがおかしくなっているということでもある。


ちなみに、4回目のエラーの後、別のファイルに対してテストを実行してみたところ、25 万回でエラーになった。要するに 代替ブロックを消費しつくした後は、代替しないで write エラーになる。記録する FLash 自体の書き込み耐性はやはり、10 万回〜数十万回の
ようだ。1 回 write エラーになった後、もう書けないわけではなく、ある確率で write エラーになる。そしてその確率は(おそらく)だんだん高くなっていくように思える。


おわりにその2

題名が microSD の 書き込み耐性で、64M miniSD はプロローグみたいなもの。それで終わるのは気がひけたので、ここまで追記してしまった。

それはともかく、他の microSD はどうなのか? なんて興味も出てきてしまった。金銭的にダメージがあるので、あんまりやるつもりはない。でも壊れ方のパターンを知りたいので、もう1つだけやってみようかと思う。

ターゲットは、キングストンの microSD 2G 。東芝の chip を使っているらしい。あと microSD 自体に JAPAN の文字がはいっている。テストをするマシンも玄箱/HG(自分改造版) の Linux に変更予定。

なお、このレポートは新しく記事にするので、追記はここで終わりです。

microSDカードの書き込み耐性(2)に続く。
posted by すz at 00:40| Comment(85) | TrackBack(1) | microSD関係