2008/02/24(日)フラッシュメモリは何日で壊れる? ウェアレベリングの仕組み

一昔前はLinuxマシンにCFディスクをCF→ATAPI変換して使うということもありました。SSDをはじめ半導体不揮発メモリが盛り上がりつつある時代、寿命について考えてみたいと思います。

なお、SSDのいわゆるプチフリーズと呼ばれる現象の正体は、このウェアレベリングに他なりません。*1

資料:SanDiskCF仕様書SanDiskウェアレベリング(ホワイトペーパー)

SanDiskのCFについて考察しますが、他社製の半導体メモリでも同様の機構があります

*1 : このような書き込み中に数秒とまるという現象は、SSD登場以前のCFでも既に起こっていました。

半導体メモリの寿命

ほぼすべての半導体メモリには構造上の寿命があります。これは書き込み回数の制限で、一般的に10万回(多くて30万回)と言われています。しかしこれはSLCタイプと呼ばれるメモリの話で、現在主流となっている安価なMLCタイプ*2では1万回程度と言われています。(この記事では30万回を寿命として計算していますので、普通のSD等では1/30だと読み進めてください。)

30万回ならば到底問題ないじゃないかと思うかも知れません。

しかし、例えば30万回だとして、1秒に1回データを書き込んでいたとすると

3600(秒)×24(時間)=86400
86400×4日=345600

となり、たった4日で壊れる計算になります。同じファイル(の同じ場所)をそんなに書き換えないと思うかも知れませんが、ファイルシステムというものが存在するので、ログディレクトリ内で1秒1回書き込んでいると、常に同じ場所に存在するログディレクトリ(ディレクトリファイル)は1秒に1回書き換えられることになります。*3

デジカメの写真なら30万枚撮らないと壊れませんが、パソコンのディスクとして使用すると結構簡単に壊れることが分かると思います。

*2 : この回数は1セルに2bit以上記録する。

*3 : Windowsは、ファイルに触るたびにファイルへの最終アクセス時刻をファイルシステムに記録するのでもっと酷いことになります。レジストリを操作すればオフにできますが。

SanDisk製コンパクトフラッシュの故障防止機構

SanDisk製CFにはウェアレベリングという故障防止機構が搭載されいてます。

ディスク容量などによって大きさは変化しますが、CFは16KBごとの物理ブロックに分割されて内部管理されています。またディスク全体は4MBごと*4にゾーンとして切り分けています*5。各ゾーンは約3%(128KBぐらい)の余剰領域(通常はアクセスできない)を持っています。

waer_leveling.png

CF内のアドレス(CHS/LBA)はそれぞれ4MBごとに物理ゾーンと対応しています*6。各ゾーンは「Erase Pool」と呼ばれる空き領域の線形リストを持っています。データの書き込まれていないブロックはすべてErase Poolに置かれます

ゾーン内への書き込み命令があったとき、対応する物理アドレスを直接書き換えるのではなく、「Erase Pool」から1ブロックを取り出しそこに内容を書き込み、それを(内部的に)書き込んだ論理アドレスに対応させます。今まで論理アドレスに対応していた物理ブロックは消去した上で「Erase Pool」に移動されます。こうすることでゾーン内での書き込みを分散させます。

しかしこのままでは、各ゾーン(に対応する論理アドレス)に書き込みが集中したときあっという間に壊れてしまいます。そのためゾーンに対する書き込みがある一定数に達すると「対応ゾーンの変更処理」が行われます。ゾーンAとゾーンBのデータが入れ替えです。入れ替えといっても、ディスク内部でデータを互いにコピーしているだけですので少々時間がかかります。実際、CFに対して連続書き込み*7を行うと、一定回数書き込みむごとに動作が2~3秒停止します*8。このときゾーン間のコピーが発生しているようです。

このようなゾーン内の分散処理とゾーン自体の入れ替え処理により、書き込み負荷はディスク全体に分散され、ディスクに空き領域があればあるだけディスクの寿命が伸びます。半導体メモリ各社で実装には色々な違いや特徴(特許)ががりますが、このようなディスクの機構をwear leveling(ウェアレベリング)といいます。

*4 : ディスクによって異なります

*5 : 書き込みや読み込みは、通常ページやセクタ単位(512byte等)で行われますが、消去(空き領域管理)はゾーン単位です

*6 : メモリのページング機構みたいなもの

*7 : 同一ファイルの上書きアップデートとF_SYNC

*8 : SSDで言うところのいわゆるプチフリーズ現象です。

ウェアレベリングの実際

かなり秀逸な機構……に見えますが、実際はそうそう上手く行きません。この機構が正しく働くためには、書き込みを行うディスクに空きゾーン領域がたくさんなければなりません。

例えば、CFディスクを結構使い動作も遅くなってきたので、一度フォーマットして全領域を一度開放したいと思ったとします。ここで、WindowsなどからCFディスクをフォーマットすると(クイックフォーマット除く)どうなるでしょうか? 空き領域(空きブロック/空きゾーン)を増やすつもりが、逆にCFディスクの全領域が使用中にマークされてしまいます。空き領域(空きブロック等)を増やそうとファイルを削除してもまったく増えません。

なぜなら、ディスクはファイルシステムの空き領域を知ることはできないからです*9。ディスク側は1度でも何か書き込まれれば、そのブロックは使用済領域とみなします。

もし、ディスクの空き領域(空きブロック等)を増やすのであれば、ディスクに対してそのブロックが既に使用されてないことを教える特殊なコマンドを発行してあげる必要があります。実際、CFにはそのようなコマンドとして「CF ERASE SECTORS」が規定されています。しかしながらIDEディスク代わりやUSBメモリとして使っている場合、このコマンドは発行されません*10

要するに全く未使用の状況ならともかく、使っているうちに実際のディスク使用率(ファイルシステム上の空き領域)に関わらず「Erase Pool」はどんどん減少していきます。うっかり通常フォーマットやエラーチェックでディスク全体の書き込み検査でもしようものなら、「Erase Pool」は最初から余剰分として用意された3%しか無くなります。

*9 : ディスク自体にファイルシステムの機能があるのではなく、OSがファイルシステムを持っているのだから当たり前です

*10 : OSとデバイスドライバに依存しますが、OSがディスクを普通のHDD等とみなしている限り無理でしょう。ZPOOL(ZFS)なんかだと、ディスクまで開放命令(ERASE SECTORS)が発行されるみたいです。あとここ最近のSATA接続のSSDとかも開放されるらしい。

3%の余剰セクタで何日使える?

例えばディスク容量が2GBとすると、2048MBの3%で62MBの余剰領域となります。16KBの消去ブロックで考えると62MB/16KB=約4000となります。理想通り効率的にディスク全体に書き込みが分散されるとしたら、1秒1回書き込むとして

4000(ブロック数)×300000(寿命)/86400=13653日

となります。書き込み回数が1秒2回(各16KB以内)ならば、この値は半分になるし容量が半分になっても半分になります。

用途によっては秒間10回(または160KB/sec)の書き換えというのは、それほど非現実的ではありません。このときたった136日でCFは壊れます。もちろんこれはウェアレベリングが理想的に動作したときで、実際はもっと前にエラーが起こるでしょう。

CFのエラーマネジメント機構

ちなみにCFには(HDDにも)エラーマネジメント機構として、エラーのあった場所を代替セクタで置き換えるシステムがあります。HDDのエラーは一度起これば広範囲かつ致命的に起こるのですぐに発見できますが、CFのエラーは局所的にしか発生しないため、エラーマネジメントによって置き換えられ隠蔽されます。*11

よってCFのエラーの発生を調べるのはかなり大変です。

*11 : 仕様書には記載されていませんが、この置き換えにはさきほどの3%の余剰ブロックが使われていると思われます。

まとめ

半導体メモリを使用する際は、構造的な有限寿命であることを考慮の上、書き込み回数をよく見積もってから使うべきです。ユーザー環境なら構わないでしょうが、サーバや組み込み系システムで(HDDよりもいいだろうと思って)安易に半導体ディスクを使うと大変なことになります。

今回行った計算はあくまで例です。寿命はセルあたりの書き込み回数寿命、ウェアレベリングの方式、zoneサイズ、全容量が大きく関係しますが、それは製品によって異なります。

2008/01/28(月)FirefoxのSageは危ない

脆弱性情報の公表に関する疑問によると

最後に、Sageユーザーの方が現時点で取り得る対策方法について記しておきたいと思います。

  • Sageの使用を直ちに中止する (強く推奨)

だそうです。とりあえずSage++に入れ替えた(このままSage使うよりはマシ良いので)。

そういやSageが危ないって話は前からありましたよね……。というより、実際自分でもadiary開発中に何度も確認してるし。Sageは数え切れない欠陥がありまして*1、実行時の場所が

file:///C:/Documents%20and%20Settings/~/chrome/sage.html

ですから、XSS使うと簡単に同一ドメインでローカルファイルがry

それにしてもJPCERT/CCって害毒だなー(笑)

*1 : 内部特殊変数をRSSに書くと置き換えてくれたり、エスケープコードを2重に評価したり。この2重評価はひどくて、blogシステム上で第3者によるXSS対策をしてもRSSを読むことで、blogシステムの防衛機能を乗り越えてクライアントPCでXSSできるという。実証はしてないけど、たぶんできる。