エンジニア徒然草

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

調査対象と方法

言うまでもなく調査対象は寿命だ。この場合の「寿命」は microSD が壊れるまでに書き込めたデータ量と定義する以外にあまり良い方法は無さそうである。また「壊れた」と言うのは書き込んだ直後にデータを読みだした際、書き込んだ通りのデータが読み出せなかったり I/O エラーが発生する状態と定義する。

書き込み直後には正常に読み出せても少し時間が経つとエラーが発生するような状態、つまりデータ保持期間が極端に短くなるような場合も起こると思うが、これを調べようとするとかなり長期間の調査になりそうなので見送った。

今回もう一つ調べたかったのが書き込みデータ量の実用的な把握方法である。

SSD なら S.M.A.R.T. 機能の属性値に消去回数のような残り寿命を推定できる情報が準備されている場合が多いが、 microSD カードではこの種の情報が得られない。

その代わりに書き込んだデータ量を把握して、同じ様に調べておいた寿命と比べれば残り寿命が推定できるだろうと考えたわけである。寿命を調査する時はテスト用のプログラムが圧倒的に多量のデータを書き込むようにして、それ以外の書き込みは無視できるようにするのが一般的だと思う。しかし実用的なアプリ運用中にその手段は使えないが、 Linux の機能をうまく組み合わせれば同等の事が実現できる。

最近の Linux では一般的になった Ext4 ファイルシステムはスーパーブロック情報に「Lifetime writes」が含まれていて、 dumpe2fs -h コマンドまたは tue2fs -l コマンドで表示させることができる。

volumio@volumio223:~$ sudo dumpe2fs -h /dev/root | grep Lifetime
dumpe2fs 1.42.5 (29-Jul-2012)
Lifetime writes:          378 GB
volumio@volumio223:~$ sudo tune2fs -l /dev/root | grep Lifetime
Lifetime writes:          378 GB

これはファイルシステムが作成されて以来書き込まれた累計データ量だ。ただしこの数値はファイルシステムがマウントされた時点のもので、マウント中は更新されないが、 iostat コマンドを使うと補うことができる。

volumio@volumio223:~$ iostat -m
Linux 3.8.13-bone20 (volumio223)        01/03/15        _armv7l_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.29    0.00    6.52   89.90    0.00    0.29

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
mmcblk0          50.72         0.52         2.61      42232     213834
mmcblk1           0.00         0.00         0.00          0          0
mmcblk1boot1      0.00         0.00         0.00          0          0
mmcblk1boot0      0.00         0.00         0.00          0          0
sda               0.01         0.00         0.00          5          0

MB_wrtn は、デバイス毎の Linux 起動以来の累計書き込みデータ量である。この数値はコマンド実行時点の値なので、「Lifetime writes」と合計すればファイルシステム作成以来の書き込み量の最新値を得ることができる。ただし「Lifetime writes」はファイルシステム毎なので、一般論として同じデバイスに属する全ての区画を合計する必要があるが、 BBB では通常書き込みを行う区画が一つしかないのでこの種の心配は要らない。

これでメデタシメデタシとなる予定だったのだが、今回調査していて少し困ったことが見つかってしまった。「Lifetime writes」は Linux が正常終了しなかった場合に更新されない様なのだ。つまりこう言う事である。

• Linux 起動: Lifetime writes = 123GB
• テストプログラムで 10GB 書き込み
• リセットスイッチで Linux 再起動: Lifetime writes = 123GB

「Lifetime writes」はアンマウントのタイミングでファイルシステムに書き戻されているのかもしれない。いずれにせよ「Lifetime writes」と iostat の結果を単純に合計しただけではダメだ。今回の調査ではファイルシステム作成以来 Linux 起動する都度の「Lifetime writes」と定期的な iostat 結果の記録を残しているので、正常に Linux が終了しなかったことによる「Lifetime writes」の差異は補正可能だ。ただし最後の iostat 結果の記録以降に行われた書き込み量が把握できず、マイナス誤差になる。この誤差は iostat 結果の記録頻度を高くすれば小さくなるので、必要な精度から頻度を決めるようにする必要がある。

今回問題は１回の異常終了毎に最大 5GB の誤差を許容する設定だ。問題になるのがテラバイト単位のデータ量なのでこれで良いのである。

同じような記録を残せば実用的アプリ運用中にも適用可能だ。この場合全ての記録を残す必要は無く、直近の２世代程度の情報を再起動をまたいで伝わるようファイルで残してやれば良いはずだ。これはまだ構想段階で、今回の調査が終わったら詳細を詰めたうえで記事にしたいと思っている。

更にもう一つ、せっかく時間をかけて調べるのだから残り寿命に応じて変化するような指標になりそうなものを試すことにした。

エラー訂正は今日の大容量フラッシュメモリーを支える重要な技術だ。これは磁気ディスクでも同じかもしれない。フラッシュメモリーが寿命を迎えるのはエラーが訂正しきれなくなる時である。つまり残り寿命が短くなるにつれ訂正されるエラー頻度が高くなり、それに応じて読出し時間が長くなるのではないかと考えた。 Read-modify-write を行っている場合があるので、これは書き込み時間にも影響するはずだ。つまり決まった量のデータを読み書きするのに要する時間変化を調べることにした。

結局以下のようなシェルスクリプトで記録を取ることにした。

#!/bin/bash

log='/mnt2/sd_endurance/log.txt'
part=`mount | grep 'on / ' |  awk '{ print $1 }' `
echo "${part}"
echo -n "${part} -- " >> $log
sudo dumpe2fs -h $part | grep Lifetime | tee -a $log

mkdir -p testfiles

while $True ; do
    date | tee -a $log
    for i in 1 2 3 4 ; do
        echo -n "wrt[${i}] "
        ./filewrt.py
    done
    echo -n "wrt[5] "
    ./wrt_chk.py | tee -a $log
    date | tee -a $log
    iostat -m | grep mmcblk0  | tee -a $log
done

filewrt.py は 1GB データを書き込むプログラム、 wrt_chk.py は 1GB データを書き込んだ後読み出して正しく書き込めているか確認するプログラムである。

書き込むのはサイズ 256kB のファイルを 1024 個、 256MB のサイズを 3 個で、内容は長さ 256kB のランダムな文字列だ。万が一圧縮機能があっても効かないようにするためである。なおランダムな文字列はプログラムの実行の都度生成するが、先頭をファイル名に置き換えている以外全てのファイルで共通である。 256MB のファイルでは同じ文字列を 1024 回繰り返している。なお書き込みブロックサイズは全て 256kB である。

wrt_chk.py は読みだしたデータを書き込んだデータと照合して不一致が発生した場合、および読出し中に発生したエラーの内容がログに残るよう出力する。これらの事象が発生しても処理は打ち切らない。書き込み中にエラーが発生した場合は Python の標準機能でプログラムの実行が中断されるはずだが、可能な限りスクリプトの実行は継続する。これは microSD が壊れた時何が起こるか、できるだけ最後まで見届けられるように考えたものだ。

スクリプトを実行する前にファイルサーバー上の共有ディレクトリーを /mnt2 にマウントしておく。実際はサンプルを識別するためにログファイル名をユニークにしているので同時複数のテストを行うことが可能である。

なお今回 Linux イメージは Volumio を使った。テストプログラムを黙々と動かしている間も microSD 以外のリソースはほとんど使われていないので Web ラジオが聞けるようにしてしまおう、と言うことだ。記事を書いた時点の最新バージョンは 1.5 だが Volumio の機能に一部不具合があったので 1.4 を使っている。ディストリビューションは Debian 7.7、カーネル 3.8.13-bone20 だ。

apt-get update および upgrade を行うのに加え、以下の準備を行っている。

• IP アドレス固定化（/etc/network/interfaces 編集）
• ホスト名変更（/etc/hosts および /etc/hostname 編集）
• タイムゾーンを Asia/Tokyo に設定（dpkg-reconfigure tzdata）
• パッケージ sysstat および screen をインストール

sysstat パッケージは iostat コマンドを使うために必要。 ssh セッションで BBB にログインして、 screen パッケージが提供している screen コマンドを実行してからシェルスクリプトを動かしておく。これで ssh セッションを切断して再接続後に screen -r コマンドを実行することでスクリプトを実行中のセッションに再接続可能になる。

 

調査対象サンプル

できるだけ調査が短期間で終わるよう、 micoroSD HC カードの最小容量である 4GB で最も高速な Class 10 を４品種、それぞれ１つずつ調べることにした。

今回の調査はブランド間の違いを調べるのが目的ではないので各品種１サンプルとした。これでは得られた結果から当該品種母集団の平均像を議論するのは統計的な意味が無いが、それで良いのだ。むしろブランドを決めずに「4GB Class 10 の micorSD カード」を一つ取り上げた時の結果がどの程度の範囲にバラつくのか、それを調べるのが目的である。

ただし便宜上「xxx（ブランド名）のサンプル」と表現する場合があると思うが、これは今回使ったサンプルを識別するのが目的であって、そのブランドの製品の平均像と言う意味ではない。

 

事前の予測

寿命に関する記述のある microSD カードのデータシートは見たことが無い。 SSD なら詳細なデータシートを公開しているベンダーもあるが、コンシューマー向け製品の寿命に関しては「JESD218規格適合」で済まされている場合が多い。

「JESD218規格」そのものは無償公開されていないが、間接的に無償公開されている例としてインテル 530 シリーズのデータシートを参照すると、以下のように記載されている。

The Intel® SSD 530 Series meets or exceeds SSD endurance and data retention requirements as specified in the JESD218 specification.
Table 10: Reliability Specifications
Parameter Value （省略） Minimum Useful Life/Endurance Rating   The SSD will have a minimum useful life based on a typical client workload assuming up to 20 GB of host writes per day. 5 years （省略）
Source: http://www.intel.co.jp/content/dam/www/public/us/en/documents/product-specifications/ssd-530-sata-specification.pdf

「５年間毎日 20GB 書き込んでも大丈夫」と言うこと。 365 日／年とすると累計 36.5TB 書き込める計算だ。インテル 530 シリーズで最も容量の小さい製品は 80GB なので、ディスク容量の約 450 倍書き込んでも大丈夫、と言うことである。これから推定すると、ディスク容量の 500～1000 倍書き込むと「壊れる」のではないかと考えられる。

少し無謀だと思うが、これをそのまま 4GB microSD に当てはめると 1.8TB 書き込んでも大丈夫、 2～4TB 書き込むと「壊れる」と言うことだ。 Class 10 の規格の半分、 5MB/s の書き込みスループットが得られるなら、早ければ５日で終わる。この程度なら手軽に試せる、と思って始めたのが間違いだったかもしれない。

 

中間結果

最も早く調査開始した磁気研究所（MAG-LAB）と Transcend のサンプルが１週間を超えた時点の結果である。

一番多いものでも累計書き込み量は約 1.7TB に留まっていて未だエラーなどは発生していない。これは BBB の書き込みスループットが 3～4MB/s しか出ないことに原因がある 。USB 接続のカードリーダー／ライターを使って Windows でイメージを書き込んだときは間違いなく 10MB/s 以上出ていたので、 BBB のアクセス方法の問題である可能性が高い。

これだと 2TB に到達するにはさらに１日以上かかる計算になる。また同時に調査できるのは最大３サンプルなので、どれか一つが壊れてからさらに１週間以上調査する必要がある。やれやれ。

なお MAG-LAB と Transcend のグラフが 200GB から始まっているが、これは最初読み込み確認を行っていなかったためである。また Silicon Power のサンプルは受け入れ検査のつもりで最初の 100GB だけテストして待機させている。

現時点で収穫と言えるのは、書き込み量が増えるのに従ってテストプログラムの処理時間が増加している事だ。原因は私が想定した通りではないかもしれないが、今後どのような変化を見せるか楽しみである。

 

Write-amplification

先ほどインテル 530 シリーズの寿命がディスク容量の 500～1000 倍書き込みと計算した。 MLC フラッシュデバイスの消去／書き込みサイクル寿命が数千～１万回と言われている事を考えると、 Write-amplification が平均 5～10 程度になるような書き込みパターンを想定していると考えるべきなのだろう。

今回の調査で使っているテストプログラムの書き込みブロックサイズは 256kB で、 Write-amplification がもっと小さくなっている可能性がある。もしそうなら、今回の調査は書き込み量 4TB 位では終わらないことになる。

microSD のコントローラーはそんなに凝った制御はできないだろうから、書き込みに必要な時間が Write-amplification と比例するのではないかと考え、書き込みブロックサイズとパフォーマンスの関係を調べてみた。

今回調査に使っている microSD で調べると書き込みデータ量が正しく把握できなくなってしまうので、それらとは別の Lexar Media の 8GB Class 10 の製品で調べた結果である。書き込みに必要な時間が Write-amplification と比例している領域では IOPS が一定値になるはずなので、計算してプロットしてみた。

ブロックサイズ 32kB 以下で IOPS がほぼ一定になっているようだ。若干右肩下がりなのはデータ転送に要する時間がブロックサイズに比例することで説明できるのではないかと思う。従って、今回のテストプログラムが行っているブロックサイズ 256kB の書き込みの場合 Write-amplification は１である可能性がある。もしその通りだとして、 4GB の microSD を壊すには 20TB 書き込みが必要だとすると、調査期間は２か月以上必要である。やれやれ。

もちろん 4GB の microSD に 20TB 書き込まないと壊れない、と分かるのは喜ばしいことである。始めた以上見届けるつもりだが・・・やれやれ。

しかしその一方で、そんなに長い期間かからないのではないかと思える材料もある。

今のペース（２～４分／TB）で処理時間が増加を続けると、書き込み量が 20TB に到達するころには処理時間が最初の２倍を超えてしまう。これはありそうにない事だ。全く根拠は無いが仮に処理時間が最初の５割増しになった時に壊れるなら、書き込み量は 3.5～6TB である。こっちの方がもっともらしく思える数字だ。調査期間は２～３週間で済む。

 

今回のまとめ

ブロックサイズ 256kB は現在構想中のアプリの典型的なデータセットサイズだ。アプリでバッファーしておいて、一気に書き込むようにすればこうなる、と言う構想。こうすると 20TB 書き込めるなら、データセットを８千万回書き込める、と言うことである。データセットの中身にはセンサーから取得するサンプル値が含まれ、 256kB のデータセットを一つ作るのに少なくとも１分かかる見込みなので、連続してデータセットを作り続けても５万日分以上のデータを書き込める寿命がある・・・計算違いじゃあないかと心配になる数字だ。１００年を超えるので現実的に意味のある数字ではない。つまり半永久的、と言える水準である。

どんな結果が出るか続けてみないと分からない。続報も記事にする予定である。しかし 2TB でも５千日分以上のデータを書き込めるわけで、これでも十分おなか一杯だ。そしてその水準にもうすぐ到達するのだから、 microSD の寿命を気に病む必要があるかどうかについては既に決着済なのかもしれない。