産業用メモリ
NANDフラッシュ デバイスのエラーに関して
概要
NANDフラッシュは、大容量ストレージデバイスにとって適切な選択肢です。 比較的低コストで大容量の記憶装置を可能にします。 従来よりNOR型フラッシュメモリがブート・コードとデータを保持するために、組み込みシステムで使用されていましたが、これは大量のデータを保持するには非効率的でした。
USBまたはSATA / IDEドライブからNORフラッシュ（保護された）BIOSサポートシステムを起動するシステムでは、現在ではNANDフラッシュベースのSDカードとCFカードが設計上の選択肢となっています。
NANDフラッシュにはさまざまな技術があります。
SLC（シングルレベルセル）
MLC（2レベルセル - 擬似SLCとして使用可能）
TLC（トリプルレベルセル）
3D - （X-Y-Z軸グリッド配列）
これらの優れた技術について詳しくはFlash Enduranceで述べられています。 これらが正しく動作するためには、洗練されたハードウェアとファームウェアの両方の高度なインタフェースが必要となります。 MLC/TLCのRawビット誤り率は非常に高く、エラー検出と訂正のために強力なECCアルゴリズムが必要となります。 MLC/TLCにおいては、>96ビットのエラー検出/訂正がほぼ平均となります。
エラーの原因
NANDフラッシュは、その性質（電荷ベースのセル）によって、本質的にエラーを起こしやすい特徴を持っています。 主だったエラーの要因は次のとおりです。
セルの電荷損失または利得
読み出しディスターブ(Read Disturb)
プログラムディスターブ(Program Disturb)
過度のプログラム/消去サイクル
洗練された、よく設計されたNANDコントローラを採用したとしても、ストレージ製品が壊れる可能性はあります。 コントローラでは、エラーの発生を最小限に抑えるために、ハードウェア/ファームウェアに適切に設計されたFlash Translation Layer（FTL）が大変重要です。
FTL
FTLは、論理マッピングから物理マッピングへの変換を担当します。フラッシュ内の物理セクタへの論理セクタ（LBA）（ブロック→ページ→セクタ）マッピングは比較的簡単です。ほとんどのコントローラは、ブロックベースのマッピングまたはページベースのマッピングを使用します。どちらにも長所と短所があります。 FTLにとって最も難しい作業はエラー処理です。 ご想像のように、これは当然MLC/TLCにとっても、またダイ寸法の小型化を実現するためにも重要になります。
ウェアレベリング
ブロックの消耗はP/Eサイクルが数多く行われた後に起こります。 ORTテストは消耗を判断するのに役立ちます。 3000 P/Eサイクルと比較的短寿命のMLC/TLC 小規模プロセスにおいて最初に考慮すべき点は、フラッシュ中のブロックの早すぎる消耗を避けることです。 動的ウェアレベリングはブロックの使用をむらなく分散させ、各ブロックの使用回数（P/Eサイクル）が均等になるようにします。 一方、静的ウェアレベリングが対処するのは、静的データを記憶するブロックを含むすべてのブロックを対象にして、平準化を実行するというものです。 Erase サイクル数の上限に加え、特定のフラッシュ・デバイスでは Erase サイクル間で行われる Read サイクルの最大数も問題になります。つまり、データがブロック内にとどまっている時間が長引き、何度も読み取られることになると、そのデータが消えてデータ損失につながる可能性があるという問題です。静的ウェアレベリングは、古いデータを定期的に新しいブロックに移動させることによって、この問題に対処します。
良好なFTLは、アクティブなブロックそれぞれの消去回数を保持し、予め設定された消去回数に達するとウェアレベリングを起動します。 ウェアレベリングはエラー処理の第一歩です。
エラー検出/訂正
この機能は通常、ハードウェアで実行されます。 データがフラッシュから読み出されたときにエラーが発生し、これは逃れようがありません。 最良のFTL設計では、ECCとCRCの組み合わせが使用され、データの誤検出と訂正が防止されます。 さまざまなアルゴリズムが使用されていますが、最も効果的なアルゴリズムはBCHアルゴリズムです。 これには、訂正される各ビットに対して13ビットのオーバヘッドが必要とされます。
オーバーヘッド検出訂正データはフラッシュのスペア領域に保持されるので、使用される補正量はオーバーヘッド領域内の利用可能なフラッシュに依存します。 フラッシュベンダーはこれに調整されているので、データが訂正された場合でも、各FTLで補正が必要なビット数を把握することができます。
ディスターブエラーを読む
この現象は、多くのコントローラベンダーによって見過ごされがちです。リードディスターブエラーは、この分野の多くの不思議な問題を説明しています。
読取り妨害エラーは、ブロック消去が間に合わずにページに過度の読取り（約1M）が行われた場合に発生します。静的ウェアレベリングはある程度役立ちますが、それだけでは不十分です。ウェアレベリングは、ブロック上で過度に多くのプログラム消去サイクルを防止するための保護メカニズムです。必要とされるのは、ブロック/ページからの読み取り回数のカウントです。しきい値に達すると、データは新たに消去されたブロックに移動され、消去されたブロックは再び使用可能になる。
読み取り障害の問題は、読み取り中のページだけでなく、隣接するページにも影響することです。これは、影響を受けるページを読むときに発生するエラーが訂正できない可能性があるため、危険です。
プログラム妨害エラー
プログラム妨害エラーは、部分ページプログラムが多すぎて隣接ページが乱れた場合に正常に発生します。これを回避する1つの方法は、部分ページプログラムの数を制限することです。リードディスターブのように定義された制限はなく、これを最小限に抑えるために他のメカニズムを使用することができます。影響を受けたページが読み込まれ、エラーが検出されたときに発生します。時にはこれは修正することができますが、ブロックはまだ問題になっています。
では、何ができるのですか？ 1つの操作は、各ページの読み込み時に修正が必要なビット数を追跡することです。利用可能な補正機能のパーセンテージに近づくと、データを別の正常なブロックに移動した後にブロックを消去し、ブロックを使用して戻す必要があります。
プログラム/エラーの消去
プログラムエラーは、消去エラーよりも一般的ではありません。プログラムエラーが発生した場合、必ずブロックをサービス停止状態にする必要はありません。ブロックを非稼働状態にすることは、非効率的で不必要なことになります。単に別のブロックを選択し、古いブロックから新しいブロックにデータをコピーし、エラーの原因となったブロックを消去するだけです。その後、サービスに戻る準備が整いました。
消去が失敗した場合、その結果はより重大である。消去エラーは、ブロックがリタイアされ、置換（リマップ）される必要があります。
不良ブロックの処理 - 不良ブロック再マップ
フラッシュデバイスは、マークされた不良ブロックを含む工場から供給されます。通常、すべての良好なブロックに0xFFがあります。製造元は、ブロックの最初の数ページで不良ブロックを0xFF以外のデータでマークします。コントローラの最初の注文は、これらをスキャンして欠陥テーブルを作成することです。これらのブロックは論理マッピングから物理マッピングには含まれません。製造業者は、通常、初期+過渡発生不良ブロックが全ブロックのパーセンテージを超えないことを指定します。通常、2％が記載されています。これらのブロックを交換するために予備のプールを作成することが重要です。不良ブロックの再マッピングが不可欠です。
コピーページの過剰使用（コピーバック）
NANDフラッシュは、あるブロックから別のブロックにデータを内部的にコピーする機能を備えています。これは、約20％の速度増加を助けることができます。データは決してフラッシュデバイスを離れることはありません。しかし、大きな欠点はエラー訂正がないことです。これで十分な時間とビットエラーが蓄積されます。では、これを防ぐために何ができるのですか？カウンタを使用して実行されるコピーバックの量を制限します。しきい値を超えると、コントローラからデータを読み取ってエラーを修正します。次にカウンタをリセットします。これはスピードと信頼性の間の良い妥協であることが分かります。
ホストデバイスへのエラーの報告
ここで、NANDフラッシュを使用する際にいくつかの方法でエラーが発生することがわかりました。上記の方法は、エラーが発生する可能性を最小限に抑えるためにすべて使用する必要があります。
しかし、とにかくエラーが発生します。フラッシュから読み取りエラーを起こしましょう。上では、すでに読み込みごとにいくつのビットが訂正されているかを追跡する方法について説明しました。このカウンタを見ることで、ブロックが劣化しているかどうかを判断できます。修正能力の75％に達すると、ブロック消去が役立ちます。
それでも、コントローラーがページを読み取り、訂正不能なエラーが発生したとしましょう。これは、これがハードエラーかソフトエラーか、過去に発生した読み出しやプログラムの妨害であるかどうかはわかりません。したがって、コントローラは、訂正が達成されたかどうかを確認するために、連続して数回読む必要があります。もしそうなら、ブロックはリフレッシュのためにスケジューリングされ、消去され、データは別のブロックに移動されます。消去に失敗した場合は、再マップする必要があります。
訂正が達成できない場合、データなしでUNCエラーがホストに返されます。これは、上記の手法を使用すると最小限に抑えることができる悪いシナリオです。システムレベルでは、重要なデータに影響を及ぼすサービスは、ドライブの複数の場所に保存する必要があります。
フラッシュ・プログラムのエラーを伴う書き込みエラーの場合、コントローラーは既存のデータを新しいブロックに移動し、新しいページをプログラムし、ブロックをリフレッシュするようスケジュールする必要があります。ブロックが消去に失敗した場合は、再マップする必要があります。
ドライブ書き込み中のパワーダウンからの回復
書き込みサイクル中に電源が失われた場合（停電）、ストレージデバイスによっては、データが破壊される可能性が高くなります。コントローラ/ディスクの観点からは、できることには限界があります。何が起こるかは、セクタバッファにどれだけのデータがあるか、全体的にどのくらいのデータが後ろにあるかによって決まります。
ディスク電源レールに十分な容量がある場合、コントローラーは最初に電源障害を検出し、セクター・バッファーをフラッシュにフラッシュし、ビジー信号をホスト・インターフェースに提示することができます。同時に、フラッシュを書き込み禁止にしてCPUを停止させます。
このシナリオを実装することは必ずしも可能ではありません。ディスクの観点からすれば、破損を最小限に抑えることができるので、電源が切断されたことを検出すると、上記の手順を実行すると、少なくともフラッシュは書き込み保護されます。
パワーアップ回復は、通常、物事を修正しようとする場所です。合理的なコントローラ設計では、新しいデータをフラッシュバッファに書き込み、既存のデータには触れないことに注意してください。したがって、パワーアップ回復にはこれらのバッファの読み取りと、エラーが発生した場合には、このデータを古いデータに置き換えます。これは理想的ではありませんが、少なくともドライブに格納された破損やナンセンスデータは保証されません。
ホストは停電から復旧する責任を負う。電力損失が検出されると、ホストは書き込みを開始したデータの書き込みを完了するのに十分な時間を必要とし、その後停止します。ホストは、書かれたものを読み返してデータの競合を解決し、可能であれば修正を加える必要があります。これは簡単な作業ではありません。このプロセスについてのさらなる洞察を得るために、さらなる調査を行うことをお勧めします。
NANDフラッシュは、大容量ストレージデバイスにとって適切な選択肢です。 比較的低コストで大容量の記憶装置を可能にします。 従来よりNOR型フラッシュメモリがブート・コードとデータを保持するために、組み込みシステムで使用されていましたが、これは大量のデータを保持するには非効率的でした。USBまたはSATA / IDEドライブからNORフラッシュ（保護された）BIOSサポートシステムを起動するシステムでは、現在ではNANDフラッシュベースのSDカードとCFカードが設計上の選択肢となっています。
NANDフラッシュにはさまざまな技術があります。
SLC（シングルレベルセル）
MLC（2レベルセル - 擬似SLCとして使用可能）
TLC（トリプルレベルセル）
3D - （X-Y-Z軸グリッド配列）
これらの優れた技術について詳しくはFlash Enduranceで述べられています。 これらが正しく動作するためには、洗練されたハードウェアとファームウェアの両方の高度なインタフェースが必要となります。 MLC/TLCのRawビット誤り率は非常に高く、エラー検出と訂正のために強力なECCアルゴリズムが必要となります。 MLC/TLCにおいては、>96ビットのエラー検出/訂正がほぼ平均となります。
エラーの原因
NANDフラッシュは、その性質（電荷ベースのセル）によって、本質的にエラーを起こしやすい特徴を持っています。 主だったエラーの要因は次のとおりです。
セルの電荷損失または利得
読み出しディスターブ(Read Disturb)
プログラムディスターブ(Program Disturb)
過度のプログラム/消去サイクル
洗練された、よく設計されたNANDコントローラを採用したとしても、ストレージ製品が壊れる可能性はあります。 コントローラでは、エラーの発生を最小限に抑えるために、ハードウェア/ファームウェアに適切に設計されたFlash Translation Layer（FTL）が大変重要です。
FTL
FTLは、論理マッピングから物理マッピングへの変換を担当します。フラッシュ内の物理セクタへの論理セクタ（LBA）（ブロック→ページ→セクタ）マッピングは比較的簡単です。ほとんどのコントローラは、ブロックベースのマッピングまたはページベースのマッピングを使用します。どちらにも長所と短所があります。 FTLにとって最も難しい作業はエラー処理です。 ご想像のように、これは当然MLC/TLCにとっても、またダイ寸法の小型化を実現するためにも重要になります。
ウェアレベリング
ブロックの消耗はP/Eサイクルが数多く行われた後に起こります。 ORTテストは消耗を判断するのに役立ちます。 3000 P/Eサイクルと比較的短寿命のMLC/TLC 小規模プロセスにおいて最初に考慮すべき点は、フラッシュ中のブロックの早すぎる消耗を避けることです。 動的ウェアレベリングはブロックの使用をむらなく分散させ、各ブロックの使用回数（P/Eサイクル）が均等になるようにします。 一方、静的ウェアレベリングが対処するのは、静的データを記憶するブロックを含むすべてのブロックを対象にして、平準化を実行するというものです。 Erase サイクル数の上限に加え、特定のフラッシュ・デバイスでは Erase サイクル間で行われる Read サイクルの最大数も問題になります。つまり、データがブロック内にとどまっている時間が長引き、何度も読み取られることになると、そのデータが消えてデータ損失につながる可能性があるという問題です。静的ウェアレベリングは、古いデータを定期的に新しいブロックに移動させることによって、この問題に対処します。
良好なFTLは、アクティブなブロックそれぞれの消去回数を保持し、予め設定された消去回数に達するとウェアレベリングを起動します。 ウェアレベリングはエラー処理の第一歩です。
エラー検出/訂正
この機能は通常、ハードウェアで実行されます。 データがフラッシュから読み出されたときにエラーが発生し、これは逃れようがありません。 最良のFTL設計では、ECCとCRCの組み合わせが使用され、データの誤検出と訂正が防止されます。 さまざまなアルゴリズムが使用されていますが、最も効果的なアルゴリズムはBCHアルゴリズムです。 これには、訂正される各ビットに対して13ビットのオーバヘッドが必要とされます。
オーバーヘッド検出訂正データはフラッシュのスペア領域に保持されるので、使用される補正量はオーバーヘッド領域内の利用可能なフラッシュに依存します。 フラッシュベンダーはこれに調整されているので、データが訂正された場合でも、各FTLで補正が必要なビット数を把握することができます。
ディスターブエラーを読む
この現象は、多くのコントローラベンダーによって見過ごされがちです。リードディスターブエラーは、この分野の多くの不思議な問題を説明しています。
読取り妨害エラーは、ブロック消去が間に合わずにページに過度の読取り（約1M）が行われた場合に発生します。静的ウェアレベリングはある程度役立ちますが、それだけでは不十分です。ウェアレベリングは、ブロック上で過度に多くのプログラム消去サイクルを防止するための保護メカニズムです。必要とされるのは、ブロック/ページからの読み取り回数のカウントです。しきい値に達すると、データは新たに消去されたブロックに移動され、消去されたブロックは再び使用可能になる。
読み取り障害の問題は、読み取り中のページだけでなく、隣接するページにも影響することです。これは、影響を受けるページを読むときに発生するエラーが訂正できない可能性があるため、危険です。
プログラム妨害エラー
プログラム妨害エラーは、部分ページプログラムが多すぎて隣接ページが乱れた場合に正常に発生します。これを回避する1つの方法は、部分ページプログラムの数を制限することです。リードディスターブのように定義された制限はなく、これを最小限に抑えるために他のメカニズムを使用することができます。影響を受けたページが読み込まれ、エラーが検出されたときに発生します。時にはこれは修正することができますが、ブロックはまだ問題になっています。
では、何ができるのですか？ 1つの操作は、各ページの読み込み時に修正が必要なビット数を追跡することです。利用可能な補正機能のパーセンテージに近づくと、データを別の正常なブロックに移動した後にブロックを消去し、ブロックを使用して戻す必要があります。
プログラム/エラーの消去
プログラムエラーは、消去エラーよりも一般的ではありません。プログラムエラーが発生した場合、必ずブロックをサービス停止状態にする必要はありません。ブロックを非稼働状態にすることは、非効率的で不必要なことになります。単に別のブロックを選択し、古いブロックから新しいブロックにデータをコピーし、エラーの原因となったブロックを消去するだけです。その後、サービスに戻る準備が整いました。
消去が失敗した場合、その結果はより重大である。消去エラーは、ブロックがリタイアされ、置換（リマップ）される必要があります。
不良ブロックの処理 - 不良ブロック再マップ
フラッシュデバイスは、マークされた不良ブロックを含む工場から供給されます。通常、すべての良好なブロックに0xFFがあります。製造元は、ブロックの最初の数ページで不良ブロックを0xFF以外のデータでマークします。コントローラの最初の注文は、これらをスキャンして欠陥テーブルを作成することです。これらのブロックは論理マッピングから物理マッピングには含まれません。製造業者は、通常、初期+過渡発生不良ブロックが全ブロックのパーセンテージを超えないことを指定します。通常、2％が記載されています。これらのブロックを交換するために予備のプールを作成することが重要です。不良ブロックの再マッピングが不可欠です。
コピーページの過剰使用（コピーバック）
NANDフラッシュは、あるブロックから別のブロックにデータを内部的にコピーする機能を備えています。これは、約20％の速度増加を助けることができます。データは決してフラッシュデバイスを離れることはありません。しかし、大きな欠点はエラー訂正がないことです。これで十分な時間とビットエラーが蓄積されます。では、これを防ぐために何ができるのですか？カウンタを使用して実行されるコピーバックの量を制限します。しきい値を超えると、コントローラからデータを読み取ってエラーを修正します。次にカウンタをリセットします。これはスピードと信頼性の間の良い妥協であることが分かります。
ホストデバイスへのエラーの報告
ここで、NANDフラッシュを使用する際にいくつかの方法でエラーが発生することがわかりました。上記の方法は、エラーが発生する可能性を最小限に抑えるためにすべて使用する必要があります。
しかし、とにかくエラーが発生します。フラッシュから読み取りエラーを起こしましょう。上では、すでに読み込みごとにいくつのビットが訂正されているかを追跡する方法について説明しました。このカウンタを見ることで、ブロックが劣化しているかどうかを判断できます。修正能力の75％に達すると、ブロック消去が役立ちます。
それでも、コントローラーがページを読み取り、訂正不能なエラーが発生したとしましょう。これは、これがハードエラーかソフトエラーか、過去に発生した読み出しやプログラムの妨害であるかどうかはわかりません。したがって、コントローラは、訂正が達成されたかどうかを確認するために、連続して数回読む必要があります。もしそうなら、ブロックはリフレッシュのためにスケジューリングされ、消去され、データは別のブロックに移動されます。消去に失敗した場合は、再マップする必要があります。
訂正が達成できない場合、データなしでUNCエラーがホストに返されます。これは、上記の手法を使用すると最小限に抑えることができる悪いシナリオです。システムレベルでは、重要なデータに影響を及ぼすサービスは、ドライブの複数の場所に保存する必要があります。
フラッシュ・プログラムのエラーを伴う書き込みエラーの場合、コントローラーは既存のデータを新しいブロックに移動し、新しいページをプログラムし、ブロックをリフレッシュするようスケジュールする必要があります。ブロックが消去に失敗した場合は、再マップする必要があります。
ドライブ書き込み中のパワーダウンからの回復
書き込みサイクル中に電源が失われた場合（停電）、ストレージデバイスによっては、データが破壊される可能性が高くなります。コントローラ/ディスクの観点からは、できることには限界があります。何が起こるかは、セクタバッファにどれだけのデータがあるか、全体的にどのくらいのデータが後ろにあるかによって決まります。
ディスク電源レールに十分な容量がある場合、コントローラーは最初に電源障害を検出し、セクター・バッファーをフラッシュにフラッシュし、ビジー信号をホスト・インターフェースに提示することができます。同時に、フラッシュを書き込み禁止にしてCPUを停止させます。
このシナリオを実装することは必ずしも可能ではありません。ディスクの観点からすれば、破損を最小限に抑えることができるので、電源が切断されたことを検出すると、上記の手順を実行すると、少なくともフラッシュは書き込み保護されます。
パワーアップ回復は、通常、物事を修正しようとする場所です。合理的なコントローラ設計では、新しいデータをフラッシュバッファに書き込み、既存のデータには触れないことに注意してください。したがって、パワーアップ回復にはこれらのバッファの読み取りと、エラーが発生した場合には、このデータを古いデータに置き換えます。これは理想的ではありませんが、少なくともドライブに格納された破損やナンセンスデータは保証されません。
ホストは停電から復旧する責任を負う。電力損失が検出されると、ホストは書き込みを開始したデータの書き込みを完了するのに十分な時間を必要とし、その後停止します。ホストは、書かれたものを読み返してデータの競合を解決し、可能であれば修正を加える必要があります。これは簡単な作業ではありません。このプロセスについてのさらなる洞察を得るために、さらなる調査を行うことをお勧めします。