フラッシュロムはバグの巣窟
何故バグが寄ってくるの？
ところで、フラッシュロムにはなぜバグが寄ってくるのでしょうか？ 実はフラッシュロムには普段のソフトウエアの設計や実装ではあまり気にする事のない以下のような３つの特徴があるためです。
- 書き込み速度が変わる：ウエアレベリング等のために書き込みが待たされる事がある
- 書き込み回数の上限がある：数千回（最悪の状態）から数十万回の制限がある
- データが蒸発する：最悪の場合数日でデータが消えてしまう
それでは各々の特徴について、もう少し詳しく見ていきましょう。
書き込みが速度が変わる
フラッシュロムはPC等の主記憶に使われているDRAM（Dynamic Random Access Memory) に比べて１桁から３桁読み出しや書き込みに時間が掛かります。そして、書き込みの速度はバラつきが大きくて、時たま書き込みがとても遅くなって、場合によっては秒単位で書き込みが待たされるという事が起こる事もあります。この書き込み速度のバラつきは、フラッシュロムの種類や使い方で変わるので一概には言えないのですが、こんな事も起こる可能性があるとの前提で設計・実装やテストが行われていないと問題点がでてきます。
書き込み速度のバラつきが起きるのにはフラシュロム固有の特徴に対応するためにソフトウエアの色々なレベルで対策が行われている事に起因します。詳しく紹介し始めると技術説明が長くなってしまうのでやや乱暴ですが簡単に纏めてしまうと、①ブロック書き込みのための Read Veriy Wirte 処理に時間が掛かる ②ウエアレベリングのためのデータコピーに時間が掛かる ③ガベッジコレクションのために時間が掛かる です。 このうち①はフラッシュロムの書き込みの時に毎回必要な処理で比較的同じ時間で済むのですが、②と③は必要な時と必要で無い時があって、必要な時にだけ実行されるのでその時にだけ余計に時間が掛かります。アプリケーションソフトから見ると、ある時急に書き込みが遅くなるという症状に見えます。
この、余計に時間が掛かるというのが少々ならばそんれほど気にする事も無いのですが、大幅に時間が掛かる、例えば数百ｍ秒から数秒となると、それだけの時間フラッシュロムの書き込みが待たされると、色んなタイムアウトに引っかかったりして、処理がエラー終了してしまう事も起きます。このような事にならないように、設計や実装で注意しておく必要が出てきます。
書き込み回数の制限がある
フラッシュロムはその構造上書き込みというか書き換えのできる回数に上限があります。PC等の主記憶に使われているDRAMには書き換え回数の上限などは無いので、これはフラッシュロムだけの特徴です。その書き換え回数の上限ですが、これまたフラッシュROMの種類や使用条件によって、数十万回から数千回まで大きくバラつきがあります。
ひと昔前までは、フラッシュロムの種類もそんなに多くなく大抵のフラッシュロムは数十万回程度の書き換え上限でした。 なので、フラッシュロムを使った装置でも書き換え回数上限を 数十万回として設計をしていればまあ大丈夫でした。
しかし、大容量化のために色々な技術が生み出されて、どの技術を取り込むんで作られたのかによってフラッシュロムの種類も増えてきた現在では、書き換え上限回数にも色々な値を持つものが出てきました。この記事を書いている時点で公開されているフラッシュロムのうち、一番書き換え上限の小さいのはTLCのNnad 型のフラッシュロムで数千回です。 最新技術としてはさらにQLCのNand型というのも出てきているのですが、きちらはまだ書き換え上限回数についての情報があまり出てきていません。しかし、その構造上TLCのNand 型よりもさらに書き換え上限値は小さくなると思われます。
書き換え上限回数が数千回となると、よく注意して使わないと、フラッシュロムの書き換え上限回数による寿命が装置そのものの寿命よりも短くなってしまいます。装置そのものは10年くらいは使えるのに、フラッシュロムは3年程度で書き換えができなくなった、という事も起こり得ます。
そうならないように、装置に使われるフラッシュロムの種類から書き換え上限回数を確認して、それに従って必要な処理をソフトウエアに設計・実装する必要が出てきます。これを忘れると、寿命の短い製品になってしまうので、ちょっとマズイですね。