今日、USBやSATA/IDEドライブ、SDカード、CFカードからのシステムブートをサポートするNOR flash（protected）BIOS対応のシステムはシステム設計の一般的な選択肢であり、それらは通常、産業用NANDフラッシュベースとなっています。　NORフラッシュ（protected）は、NANDフラッシュシステムのエラー管理を支援するための設計手法です。

NANDフラッシュには、さまざまな技術があります。

• SLC (シングルレベルセル)
• MLC（2レベルセル：擬似SLCとして使用可能）。
• TLC（トリプルレベルセル）
• 3D - (X-Y-Z軸グリッドアレイ)

これらの技術はすべて素晴らしく、耐用年数も長く、詳細は「フラッシュ製品の耐久性・寿命について」に記載されています。これらの技術は、適切に動作させるために、ハードウェアとファームウェアの両方で、洗練されたインターフェイスを必要とします。MLC/TLCの未処理ビット・エラー・レートは非常に高く、エラー検出と訂正のために高負荷のECCアルゴリズムが必要です。 > 96ビットの検出/訂正は、MLC/TLCの平均的なものです。 NANDフラッシュは、その性質上（電荷ベースのセル）、本質的にエラーが発生しやすいものです。ここでは、顕著なエラーの可能性をリストアップします： セルの電荷の損失または増加 ディスターブスを読む プログラムディストリビューション プログラム/消去回数が多すぎる 洗練された設計のNANDコントローラーの使用は、ストレージ製品の良し悪しを左右します。コントローラは、エラー発生を最小限に抑えるために、ハードウェア/ファームウェアに適切に設計されたFlash Translation Layer (FTL)を備えている必要があります。 FTLは、論理的マッピングから物理的マッピングへの変換を担当する。論理セクタ（LBA）からフラッシュ内の物理セクタ（Block-＞Pages-＞Sectors）へ。マッピングは比較的簡単な部分です。ほとんどのコントローラーは、ブロックベースのマッピングまたはページベースのマッピングのいずれかを使用します。どちらにも利点と欠点があります。FTLマッピングについては、インターネットを検索すれば網羅的な情報が得られるので、興味のある方は調べてみてください。FTLの最も難しいタスクは、エラー処理です。MLC/TLCや非常に小さなダイのプロセス形状では、この点がより重要になることはご想像の通りです。 ブロックの磨耗は、P/Eサイクルを何度も繰り返すと起こります。ORTテストは、摩耗を判断するのに役立ちます。最初に考慮すべきは、フラッシュ内のブロックの早期磨耗を防ぐことです。このブロックの寿命は、小型プロセスのMLC/TLCデバイスでは3000P/Eサイクルと短いものです。ウェアレベリングは、すべてのブロックがほぼ同じ数のP/Eサイクルを受けることを確認します。最適なウェアレベリングはスタティックタイプで、書き込みがほとんどない場合でもデータブロックが循環します(スタティックデータは移動します)。 優れたFTLは、各アクティブブロックの消去回数を記録し、あらかじめ設定された消去回数に達するとウェアレベリングが開始されます。したがって、ウェアレベリングはエラーハンドリングの最初の基本ステップである。 この機能は通常、ハードウェアで実行されます。フラッシュからデータを読み出すとエラーが発生しますが、それを回避することはできません。最高のFTL設計では、ECCとCRCを組み合わせて使用し、データの誤検出と訂正を防止しています。使用されているアルゴリズムは様々ですが、最も効果的なのはBCHアルゴリズムです。これは、補正を希望する各ビットに対して13ビットのオーバーヘッドを必要とします。 オーバーヘッド検出の補正データはフラッシュの予備領域に保持されるため、使用する補正量はオーバーヘッド領域の空きフラッシュに依存します。フラッシュベンダーはこの点に着目しており、優れたFTLは、データが補正される場合でも、読み出しごとに何ビットの補正が必要かを記録します。これには、後述するように正当な理由があるのです。 この現象は、多くのコントローラベンダーが一般的に見落としていますが、そうではありません。リード・ディスターブ・エラーは、現場で起こる多くの不思議な問題の原因となっています。 リード・ディスターブ・エラーは、ブロック消去を挟まずに、1ページに約1Mの読み出しが行われた場合に発生します。スタティック・ウェアレベリングはある程度効果がありますが、それだけでは十分ではありません。ウェアレベリングは、ブロックのプログラム消去回数が多すぎないようにするための保護メカニズムです。必要なのは、ブロック/ページからの読み出し回数をカウントすることです。ある閾値に達すると、データを消去したばかりのブロックに移動させる必要があり、その後、消去されたブロックを再び使用できるようにします。 リードディスターブの問題は、読み込まれたページだけでなく、隣接するページにも影響を及ぼすことです。これは、影響を受けたページの読み取り時に発生するエラーが修正できない可能性があるため危険です。 プログラム妨害エラーは、通常、部分ページプログラムを作りすぎて、隣接するページが妨害された場合に発生します。これを回避する一つの方法は、部分ページプログラムの数を制限することである。リードディスターブのように定義された制限はなく、他のメカニズムで最小化することができます。影響を受けるページが読み込まれ、エラーが検出されたときに起こります。これを修正できる場合もありますが、しかし、ブロックにはトラブルが残っています。 では、どうすればいいのだろうか。一つの方法として、各ページの読み取り時に補正が必要なビットの数を記録しておくことが有効です。修正可能なビットの割合に近づいたら、そのブロックを消去し、他の良好なブロックにデータを移動させ、その後、そのブロックを使用できるようにする必要があります。 NANDフラッシュのエラーを管理する場合、プログラムエラーは消去エラーに比べれば少ない。プログラムエラーが発生した場合、必ずしもそのブロックを使用不能にする必要はありません。ブロックを使用停止にすることは、非効率的で不必要です。別のブロックを選び、古いブロックから新しいブロックにデータをコピーし、エラーが発生したブロックを消去するだけです。そうすれば、すぐに使えるようになります。 消去に失敗した場合、結果はより深刻です。消去に失敗した場合、そのブロックを引退させ、交換（リマップ）することが必要になります。 フラッシュデバイスは、工場出荷時に不良ブロックがマークされています。通常、すべての良品ブロックには0xFFが入っています。製造元は、ブロックの最初の数ページに、0xFFとは異なるデータで不良ブロックをマークします。コントローラの最初の仕事は、これらのブロックをスキャンして欠陥テーブルを作成することです。これらのブロックは、論理-物理マッピングに含まれません。メーカーは通常、初期不良と過渡的に発生する不良ブロックが総ブロックの何パーセントを超えないように指定します。一般的には2％とされています。不良ブロックが増えると、そのブロックを交換するために、予備ブロックのプールを確立しておくことが重要である。 NANDフラッシュには、内部でデータをブロックごとにコピーできる機能があります。これにより、およそ20％の高速化を実現することができます。データはフラッシュデバイスの外に出ることはありません。しかし、大きな欠点は、エラー訂正ができないことです。これを何度も繰り返すと、ビットエラーが蓄積されていきます。では、これを防ぐにはどうしたらいいのでしょうか？カウンターを使って、コピーバックの実行量を制限する。閾値を超えたら、コントローラからデータを読み出してエラーを修正します。そして、カウンターをリセットする。これは、速度と信頼性の間の良い妥協点であることが判明しました。 NANDフラッシュを使用する際に、いくつかの方法でエラーが発生すること、そしてNANDフラッシュのエラーを管理することが重要であることがお分かりいただけたと思います。上記の方法は、いずれもエラーに遭遇する確率を最小限にするために使用されるべきものです。 しかし、いずれにせよエラーは発生するものです。ここでは、フラッシュからの読み取りエラーについて説明します。上記では、読み出しのたびに何ビットが訂正されたかを記録する方法をすでに紹介しました。このカウンターを見ることで、ブロックが劣化しているかどうかを知ることができます。補正能力の75％に達したら、ブロック消去をすればいい。 それでも、コントローラーがページを読んで訂正不能のエラーが出たとしよう。これがハードエラーなのかソフトエラーなのか、もしかしたら過去に発生した読み出しやプログラム障害によるものなのか、コントローラにはわかりません。そこで、コントローラは数回連続して読み取りを行い、訂正が可能かどうかを確認する必要があります。もしそうなら、そのブロックはリフレッシュのためにスケジュールされるべきで、消去され、データは別のブロックに移動されます。消去に失敗した場合は、再マップする必要があります。 修正できない場合、UNCエラーがデータなしでホストに返されます。このような悪いシナリオは、上記のようなテクニックを使えば最小限に抑えることができます。システム・レベルでは、重要なデータに影響を与えるサービスは、ドライブ上の複数の場所に保管する必要があります。 フラッシュプログラムエラーを伴う書き込みエラーの場合、コントローラは既存のデータを新しいブロックに移動し、新しいページをプログラムし、ブロックをリフレッシュするようにスケジュールする必要があります。ブロックが消去に失敗した場合は、再マップする必要があります。 どのようなストレージデバイスでも、書き込みサイクル中に電源が落ちると（Power Fail）、データが破損する可能性が高く、NANDフラッシュのエラー管理を考慮する必要があります。コントローラ/ディスクの観点からは、できることに限りがあります。何が起こるかは、セクタ・バッファにどれだけのデータがあるか、その背後に全体としてどれだけのデータがあるかによります。 ディスクの電源レールに十分な静電容量があれば、コントローラは最初にパワーフェイルを検出し、セクタバッファをフラッシュに流し、ホストインターフェイスにビジー信号を提示することができます。同時に、フラッシュを書き込み保護し、CPUを停止させる。 このシナリオを実装することは、必ずしも可能ではありません。ディスクの観点から、できることは破損を最小限に抑えることであり、パワーダウンの検出時に、上記の手順が取られれば、少なくともフラッシュは書き込み保護されます。 電源投入時のリカバリーは、通常、事態の収拾が図られるところです。合理的なコントローラーの設計では、フラッシュ・バッファに新しいデータを書き込み、既存のデータには触れないことに留意してください。そのため、電源投入時のリカバリーでは、これらのバッファを読み取り、エラーが発生した場合は、このデータを古いデータと置き換えます。これは理想的ではありませんが、少なくともドライブに保存されたデータが破損したり、無意味になったりしないことは保証されます。 電源障害からの復旧は、ホストがその責任を負う。電源喪失を検出すると、ホストは書き込みを開始したデータの書き込みを完了し、停止するのに十分な時間を必要とします。その後、ホストはデータの競合を解決するために、書き込んだデータを読み戻す必要があります。