続報３: microSD カードの寿命を調べる

磁気研究所ブランドに続き、Silicon Powerブランド microSD の寿命が尽きたようである。磁気研究所ブランドのサンプルの状況は前々回および前回の記事を参照してほしい。

/*-----------  -----------*/

寿命が尽きるまでの状況

最初に寿命が尽きた磁気研究所ブランドの microSD と似た経過をたどった。

• 理由もなく時々 Linux が固まるようになった
• テストプログラムが書き込んだデータを読みだしたとき不一致を検出するようになった
• Linux が起動しなくなった

最後の「Linux が起動しなくなった」と言うのは、具体的には以下のような状況である。

U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:   
 not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0 
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
808 bytes read in 4 ms (197.3 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
mmc1(part 0) is current device
mmc_send_cmd : timeout: No status update
mmc0 is current device
3245640 bytes read in 676 ms (4.6 MiB/s)
Booting from external microSD...
23801 bytes read in 50 ms (464.8 KiB/s)
## Flattened Device Tree blob at 80f80000
   Booting using the fdt blob at 0x80f80000
   Using Device Tree in place at 80f80000, end 80f88cf8

Starting kernel ...

Uncompressing Linux...

XZ-compressed data is corrupt

 -- System halted

Linux kernel を起動しようとした時、kernel イメージの解凍に失敗しているようだ。
磁気研究所ブランドのサンプルでは Python が動かなくなったが、これは壊れた場所が違うだけで、Linux を構成するファイルの一部が壊れたことに変わりない。

不一致を検出した状況も磁気研究所ブランドのサンプルとさほど違わない。

不一致が出始めたあたりから拡大すると以下の様である。

読み書きの処理時間の推移は若干異なる。

不一致が発生するようになるのと同時に読み書きとも処理時間が急に増加し始めている。
この現象をとらえれば microSD が寿命に到達したのを検出できそうだ。しかし今回は一定の条件でテストを繰り返しているから分かったが、通常の使用状況で検出するのはかなり難しそうである。

今回寿命が尽きた Silicon Power ブランドのサンプルは 17.7x10¹² バイト (16.1TB) 書き込んだあたりから兆候があり、19.86x10¹² バイト (18.1TB) 書き込んだ時点で Linux が起動不能に陥った。この microSD カード全体の容量が3,974,743,744 バイトなので、 Linux が起動不能に陥るまでにカード容量の 5,000 倍を書き込んだことになる。

寿命が尽きた後の状況

磁気研究所ブランドのサンプル同様、SDフォーマッター4.0で上書きフォーマットを行うと一見マトモに使える。しかし ATTO Disk Benchmark で I/O Comparison を行うと比較エラーが出る状況である。

Ware Leveling について

磁気研究所ブランドのサンプルについて、Ware Levelingの方式ごとに推定したフラッシュメモリーの消去・書き込みサイクル寿命は以下の通りだった。

• Ware Leveling なし: 8,700
• Dynamic Ware Leveling: 3,100
• Static Ware Leveling: 2,300

Silicon Power のサンプルは全く同じ条件でテストを行い、寿命が尽きるまでに磁気研究所ブランドのサンプルのほぼ２倍の書き込み量に到達しているので、上記数字を単純に２倍すればよいことになる。

消去・書き込みサイクル寿命 17,400 はどう考えても大き過ぎるので、Ware Leveling を行っていないと言う可能性は除外してよいだろう。

Dynamic Ware Leveling を行っていると仮定した場合の 6,200 はかなりそれらしい数字である。英語版 Wikipedia の Ware leveling の項に Dynamic Ware Leveling の典型的な使用例として USB Flash Drives が挙げられているが、microSD カードも同様ではないかと考えられる。

Static Ware Leveling を行っていて消去・書き込み寿命 4,600 と言う可能性は否定できないが、Dynamic Ware Leveling を行っていると考えるのに比べると違和感がある。

今回のまとめ

Silicon Power ブランドのサンプルは全容量の 5,000 倍を書き込んで寿命が尽きた。去年の大晦日にテストを開始しているので、丸々５カ月の間休みなく書き込み続けた結果である。

デジタルカメラのような使用パターン、容量いっぱい近くまで使い初期化するのを繰り返すのであれば、このサイクルを 5,000 回以上繰り返すことができる、と言う事だ。毎日初期化しても 13年以上なので、このような使い方には十分な寿命である。

このサンプルは Dynamic Ware Leveling を行っていると考えられる。と言う事は、空き容量が極端に少ない状態でファイルの上書きを繰り返すと、割と短時間で寿命が尽きる可能性がある。これには注意する必要があるだろう。

BBB などで使う場合、今回のテストの条件で使うと、休みなく書き込んでも５カ月程度使える。しかしこのような書き込みを行うと I/O 待ちがボトルネックになってレスポンスが極端に悪くなる。書き込み負荷が 1/2 またはそれ以下でないと実用にならないだろう。つまり実用的な使い方をしているなら、少なくとも１年くらいは今回の Silicon Power のサンプルは寿命に達しないはずである。

BBB で長期安定運用を狙う場合、できるだけ容量の大きな microSD を空き容量の多い状態で使うのが手間がかからない割に効果的ではないかと思う。ちなみに BBB は 32GB までサポートしているようだ。使用量も含め全てが比例関係で８倍になるとすれば、今回と全く同じ条件で寿命が尽きるまで 40カ月かかる計算になる。実用的な条件なら 80カ月、６年以上である。

32GB の microSD カードは１千円台半ばで入手できるから、費用が問題になる場合は多くないはずだ。

前々回の記事に「２か月近く経った今ようやく先が見えてきた」と書いたが、これは見通しが甘かったようだ。