ウェアレベリング
フラッシュはデバイスの仕様として書き換えに対して一定の不良ブロック数の範囲内で10万回という回数の上限があります。
言い換えると、10万回の書き換えに対して、ブロック不良率は約2%以下であることをデバイスメーカが保証していることになります。
通常の設計では、フラッシュを搭載した機器自身の製品寿命とフラッシュに対する書き換え頻度を考慮してシステムのストレージアーキテクチャを組み立てます。
そこで用いられるウェアレベリング (図4) とは、フラッシュの書き換え操作が特定のブロックに集中して、そのブロックが極端に消耗して寿命が尽きることを避けるために実施される処理です。
もっともオーソドックスな方法は、ブロックごとの書き換え回数を管理して、書き換え対象のブロックを選択する時点で、カウンタの値の少ないブロックを選び出すやり方です。
ウェアレベリング機能を組み込むことで、フラッシュ全体の寿命を少しでも伸ばすことができると考えられています。
ウェアレベリングのアルゴリズムを考えるときに、どこまで積極的に書き換え回数の平均化を実現するかの戦略がいくつかあります。
- 積極的に書き換え回数の少ないブロックを選び出す
- 特定ブロックに書き換えが集中しない防衛的方法
- ブロック書き換えの局所集中許容
1番目の方式は、フラッシュの全ブロックの中からもっとも書き換え回数の少ないブロックを選び出して、次の書き換え対象ブロックの候補にする方法です。
実際のシステムでもっとも書き換え回数の少ないブロックとは、工場出荷時に書かれたデータが変更なく保持されているブロックです。
このようなブロックはCold Blockと呼ばれます。
Cold Blockに書かれたデータは書き換えられる可能性が少ないわけなので、ある程度書き換え回数が多くなってしまったブロックに移しておけば、元の書き換え回数の少ないブロックが次の書き換えに使えるようになります。
ただし、Cold Blockの置き換え操作では余分な空きブロックは発生しないので、この操作と同時に、使用済みブロックの回収を実施しておかないと管理情報の更新分だけ残容量を減らしてしまうだけとなってしまいます。
書き換え回数の平均化という結果を得るために、丸ごと1ブロック分のデータ書き換えが余分に発生するので、システムのオーバヘッドが高くなってしまいます。
2番目の方式は、Cold Blockには手を触れず、あくまでも使用済み領域や空きのあるブロックのみを書き換え候補の対象とします。
余分なデータ転送が存在しないため、シンプルで妥当なパフォーマンスが得られます。
しかし平均化の効果は限定的で、システムのユースケースによっては、局所的に書き換えが集中してしまう可能性が残ります。
3番目の方法は、ウェアレベリングを行わないことです。
ウェアレベリングを行わなず、書き換えが局所集中するワーストケースを考えてみましょう。
いちばん極端なパターンは、単一のブロックにのみ書き換えが行われる場合です。
ウェアレベリングは行わなくても、使用済み領域の回収 (リクラメーション/ガーベジコレクション) は必須なので、実際のワーストケースでは二つのブロックを交互に書き換えることになります。
1ブロックは32ページ、1ページあたり512バイトで構成されるため、二つのブロックで32Kバイトが基本容量です。
このブロックを10万回書き換えたとすると、32Kバイト×100,000＝3,200,000,000バイト＝約3.2Gバイト分の書き換えを行うことになります。
わずか二つのブロックでもこれだけの容量を受け止めることができるのです。
書き換え頻度についても試算してみましょう。
2ブロックで10万回なので、合計20万回の書き換えとなります。
製品寿命を5年 (365×5=1825日) とすると、100,000/1825≒54、1日あたり54回 (54×16Kバイト=864Kバイト) の書き換えが可能です。
この水準はシステムのユースケース次第では十分許容できる場合もあるでしょう。
