Nintendo Switch、ドライブレコーダー、スマートフォンなど身の回りの様々なものに使用するSDカード。
「SDカードには寿命がある」「安価なものは1,000回しか書き込めない」「ドライブレコーダーには高耐久タイプを使用する必要がある」など、耐久性に関する気になる情報を目にします。
弊社でもRaspberry Piを使用した製品を扱っているので、非常に気になるところです。
物理的には1,000回しか書き込めないけど、ウェアレベリングという同じ場所に書き込みが集中しない制御がなされているので実際の寿命はもっと長い、という情報も見ますが、いまいち何が正しいのかわかりません。
そこで今回は、SDカードを壊れるまで読み書きしてみて、耐久性を確認してみよう、という企画です。
実験対象
①Transcend microSDHCカード 32GB 3D TLC UHS-I Class10 TS32GUSD300S
②Transcend 高耐久 microSDHCカード MLCフラッシュ搭載 (ドライブレコーダー向けメモリ)32GB Class10 TS32GUSDHC10V
③innowa Loop King microSDHC 32GB メモリーカード 超高耐久性 pSLC 専用ソフト ループ録画 ドラブレコーダーに最適 4K動画撮影対応
①からTLC（トリプルレベルセル）、MLC（マルチレベルセル）、SLC（シングルレベルセル）となっています。ひとつのセルに保存できるデータ量が3ビット、2ビット、1ビットとなっており、耐久性はTLC→MLC→SLCの順に高くなると言われています。価格はひとつのセルにたくさんのデータが保存できた方が安いため、TCLが一番安いです。
検証スクリプト
次のような感じにしてみました。
Windows上でBashから実行しました。SDカードはDドライブです。
$ cat write.sh #!/bin/sh echo "1234567890" > /d/text.txt
$ cat read.sh #!/bin/sh line=`cat /d/text.txt` test $line -eq '1234567890'; echo $?
$ cat test.sh
#!/bin/sh
i=1;
./write.sh
while [ "`./read.sh`" = "0" ]
do
echo $i
i=$((i+1))
./write.sh
done
ウェアレベリングが有効だと永遠に終わらないんじゃないか、実際に壊れた時にどういう挙動になるか、壊れても気づけないんじゃないか、OSのキャッシュが有効だとテストの意味がないんじゃないか、などいろいろ懸念があります。ちゃんと壊れてくれるでしょうか。まあ気にせずやってみることにします。
まずはいちばん早く壊れるであろうTLCから実験します。
結果
3日間プログラム動かし続けたが壊れない！
（正確には表面上、壊れたようには見えない）
上のスクリプトで666,075回ループしたが壊れない！
それではと思い、ファイル上書きじゃなくて削除して新規作成するようにスクリプトを変更して196,564回ループしたが壊れない！
空き容量があるとウェアレベリングが効いて壊れにくいのかと思い、ディスクの大半にダミーファイルを書き込み、ddコマンドで残り容量をほぼ使い切るファイルを書き込むようにスクリプトを変更して1週間プログラムを動かし続けて26,014回ループ、約7TBのファイルの作成と削除を行いましたが壊れない！
いったん中断してベンチマークを走らせてみたところ、壊れてる？
Writeが異様に遅い気がします。少なくとも書き込み性能は大幅に劣化している気がします。
開始時の性能と比較しないといけないのですが、耐久テスト前にRead/Writeしたくないという余計な配慮のせいでベンチマークを行っていません。
これ以上の実験の継続はテストを実施しているPCへのダメージが心配になってきたので止めておきます。
まとめ
Read/Write時にスクリプトがエラーになるような壊れ方をするかと想像していましたが、それは起こりませんでした。しかし性能は大幅に劣化している気がします。既に壊れているのかもしれませんが、壊れているのかどうかの判断も出来ません。
おそらくSDの寿命は抜き差しを繰り返したり長時間給電しなかったりといった使用状況によっても変わると思われます。データが化けたりはあってはならないのですが、それが起きていた可能性もあります。しかしそれをチェックするようなちゃんとしたプログラムは組んでいないので真相は闇の中です。
ただ、データが正しいことをチェックするプログラムにしていたら、壊れるまで途方もない時間がかかる気がします。
教訓
耐久テストは奥が深い。ちゃんと考えてから行おう。
ピンバック: マニアによるマニアのためのSDカードの選び方
トリムしたら治りますかね？
時間がある時に試してみますね
ピンバック: SDカードの構造と主要メーカー
PCMレコーダーに使っているマイクロSDが読み込み不能、エラー、異常になります。
カードは量販店で1,000円前後で購入した16Gのもの。
商品が頻繁に入れ替わるメーカーがダメかと思い、三菱系やIOデータ、エレコムなどにしましたが起こります。
レコーダーはオリンパスのV-802、803及びDM-750
PCM44.1で録音し、容量いっぱいは負担がかかるらしいので1時間分くらい残して記録。
最近気になるのは本体充電時。
DM-750は充電かけたあとカード不具合になる事が。
量販店のサイコロみたいなコンセント直差しの充電器に問題があるのでしょうか。
パソコンUSB充電では不具合なしでした。
バックアップもとりたいのでカードデュプリケーターを検討しています。
レコーダーの故障なら特定の機種だけで起こると思うので、何でしょうね。
充電中に問題が起こるとすると、パッと思いつく原因としては発熱でしょうか。
充電器で充電するとPCと比べて異常発熱があったりしませんでしょうか。
手間ですが、充電中にSDカードを抜けば対策になるかも知れません。少なくとも問題の切り分けは出来そうです。
空き容量をどの位残してテストするかによって結果は大きく異なると思います。ウェアレベリング処理では、メモリ領域が「均等に摩耗」するように調整するので、それは空き領域に依存するからです。
foo barさん
コメントありがとうございます。
ウェアレベリングの件はおっしゃる通りだと思います。
ぜんぜん壊れなかったので、途中から空き容量をほとんどなくして壊すことを目的にしました。
このスクリプトだと、全然テストにはなってないのではないでしょうか?
ほとんど、OSのキャッシュのメモリ内で読み書きしてるようなものなので。
ファイルシステムのファイルではなく、ddコマンドとかで、ディバイスファイルに直接読み書きしないと…。
Windows上のbashだと、ディバイスファイル直接ってアクセスできたのかしら…。
LinuxsやFreeBSDでddコマンド使って、直接ディバイスファイルに読み書きするのが、簡単で確実だと思います。
ffさん
OSのキャッシュメモリについて懸念しましたが、SDカード時に実際に書き込まれていることは確認しました。
正確なテストにはもっとたくさんの考慮が必要です。
書き込まれるのは確かだけど、それは、OSがファイシステムレイヤに書き込んで、ディスクキャッシュに溜まって、後で書き込みが起こります。書き込みは非同期に行われ、特に指定しない限り、なるべくまとめて書き込みが起こるように遅延実行されます(その方が効率がいいから)。
読み込みは、ディスクキャッシュに該当ブロックがある場合、実際のSDカードへの読み込みは発生しません(メモリから読んでる)。
しかも、書き込んでるデーターが短いので、1ブロックに満たない領域を読み書きしてることになるので、正直テストの意味はなさないと思います。
Linuxのrawディバイス、ブロックディバイスというのを調べられてはどうでしょう?
Windowsでも、rawディバイスのアクセスは(権限とかの問題があるかもしれないけど)できない事はないんではないかと思います。
ファイルというのは、そのrawディバイスの上にファイシステムソフトレイヤが載って、ファイルとしてアクセスしてるので、違うレイヤなので。
物理的なディバイスを操作しているのではなく、ファイルシステムレイヤを通してファイルとして見えている仮想実体を操作しているのです。
こんなミクロなデータ、32GBでしょ、32バイトとしたって1G回書き込んでやっとすべてのセルに1回書き込んだことになるだけ。
主のやったことは試験になっていない。