おことわり
この記事は、2024年7月にQiitaに投稿した記事を加筆修正したものです。
また、この記事のオリジナルは日本語で書かれています。記事が日本語以外の言語で表示されている場合、それは機械翻訳の結果です。当社は機械翻訳の精度に責任を負いません。
はじめに
前回の記事では、NANDフラッシュメモリをメディアとするSSD（以降単にSSDと記載）にまつわるSilent Data Corruption (SDC)と呼ばれるエラーのうち、NANDフラッシュメモリで発生するエラーとその対策を説明しました。
今回の記事では、SSDを構成するNANDフラッシュメモリ以外の要素で起きる事象と対策を説明します。
まとめ
- SRAMやDRAMのビット化けは誤り訂正符号(ECC)で対応する
- それ以外のデータの誤りは、バスでの誤りを含めて誤り検出機能（CRCなど）を用い、誤り検出時は再読出しで対応する
- ハードウェアだけでなくファームウェア(FW)要因でSDCが起こることもあり、適切な機能の設計と実装が必要
サイレントエラーはなぜ悪なのか？
ストレージデバイスにおけるサイレントエラーは、データが不正に変更されたにもかかわらず、エラーとして検出されない現象を指します。つまり、データが損傷していることに気づかず、システムが誤ったデータを正しいものとして処理してしまうエラーです。
サイレントエラーが発生してそれを見過ごしてしまうと、ストレージデバイスは誤りを含むデータをホストに返してしまいます。これはストレージデバイスの誤動作であり何としても避けなければなりません。
すなわちSDCを防ぐ仕組みとは、誤りを含むデータをホストに返さないための仕組み、誤りを発見したら適切に管理してホストには正直にエラーを申告するための仕組み、とも言えます。
サイレントエラーは、運用中には検出されにくいですが、ストレージデバイスの評価やテスト段階でミスコンペアとして検出されることがあります。
SSDのブロック図とSDCが起こり得る箇所
以下の図1は典型的なSSDのブロック図です。ブロック図中の吹き出しで示した箇所が、NANDフラッシュメモリ以外でSDCが起こり得るSSD内の主要な箇所です。
SSDコントローラは、これらの箇所で発生する可能性があるデータ化けに対して、その発生確率と用途をはじめとした製品仕様に基づいて対策を講じます。
また、SDCが発生する要因には、図1に示したハードウェアに加えてコントローラ上で動作するFWのバグや設計不備も含まれます。
この記事ではSSDが講じるそれらの対策について説明します。
SRAMやDRAMのビット化け
＜誤り訂正符号(ECC)で保護＞
SSDコントローラは、製品により容量の違いはあるもののSRAMを搭載しています。また、最近では搭載しない製品も多いですが、特に高いデータアクセス性能や高い信頼性を実現するSSDはDRAMを搭載します。
このSRAMやDRAMに格納されるデータは、大きく2種類に分類できます。
1つは主にSSDコントローラ内のプロセッサコアがアクセスするデータです。4バイトや8バイトなどの単位でアクセスされるデータです。
もう1つは、NANDフラッシュメモリとの間で読み書きするデータです。こちらは512バイトとか4キロバイトさらには16キロバイト（NANDフラッシュメモリのページサイズ）などの単位でアクセスされるデータです。
これらのデータは共にECCで保護します。15年ほど前に私が設計に参画していたSSDコントローラでも既に1ビット誤り訂正2ビット誤り検出(SECDED)のECCを備えていました。
製品により異なるものの、高い信頼性を求められるエンタープライズ向けやデータセンター向けそしてインダストリアル向けSSDではSRAMやDRAMのビット化け対策を搭載するのが一般的だと思われます。
ソフトエラーの一種である中性子線（例えばα線）によるビット誤りは、正しい値をもう一度書き込む（リフレッシュする）までメモリセルから正しいデータを読み出すことができないため、誤り訂正できることが必要です。
また、プロセッサコア上で動作するFWとしては1ビットの誤りが致命的な誤動作につながりかねないため、やはり誤り訂正できることが重要です。
各種バスなどでのエラー
＜CRCなどの誤り検出符号による保護で対応＞
図1に示した通りSDCが起こり得る場所にはバスが含まれます。特に、NANDフラッシュメモリとの間でデータの送受信を行うバスで発生するエラーは、SSDとして致命的なエラーになる可能性があり、対策が必要です。
SSDでは一般的に、このバスでのエラーをCRCなどの誤り検出可能な符号で対応します。エラーの訂正機能は求めません。エラーを検出したときは主にデータの再送で対応します。エラーの原因がバス上でのソフトエラーであれば、メモリから再読出しすればその転送時にはバス上でのエラーは生じない可能性が高いからです。ホストとSSD間のインターフェースが備える誤り検出機能と再送機能と同じような機能です。
こちらの場合も、再送してもエラーが検出されるときは相応の対応が必要になります。
それでは具体的な保護の仕組みを説明します。この記事では説明用に誤り検出符号としてCRCを使います。また、ここで記載した仕組みはあくまで一例であり実際には製品により異なりますので注意してください。
基本的な仕組み
SSDへのデータ書き込み時
基本的な設計では、SSDへのデータ書き込み時、SSDコントローラは図2のような処理を行います。
SSDコントローラはホストから受領したデータに対してすぐにCRCを付与します(CRC1)。そしてSSD内部では常にデータとCRCを組にして扱います。
SRAMやDRAMに加えその他のバッファに格納するときもデータとCRCを組にします。
そしてNANDフラッシュメモリに書き込むときに、データとCRCを合わせたデータに対してNANDフラッシュメモリ用の誤り訂正符号によるパリティを付与します。
SSDからのデータ読み出し時
一方SSDからのデータ読み出し時、SSDコントローラは図3のような検査を実施します。
NANDフラッシュメモリから読み出したデータとCRCに対して誤り訂正を行い、再びデータとCRCを組にして扱います。
そして、ホストインターフェースを経由してホストにデータを返すときにこれまで常にデータと組にしていたCRCを用いてデータに誤りがないかどうかを検査します。
このような仕組みにより、NANDフラッシュメモリを除くSSD内部でデータにエラーが発生していないかどうかを検査できます。
構成要素別に保護する仕組み
図2と図3の仕組みの場合、CRCによるチェックはホストにデータを転送する直前しか行わないため、エラーが起きた場所がSRAMなのかDRAMなのかその他のバッファなのかが判別できません。
エラーの発生場所を特定するためだけであれば検査箇所を増やせば良く、実際そのようにしている製品もあります。
一方エンタープライズ向けSSDなど一部の製品では、各部品の特性に応じて個別に保護することがあります。
本節ではその方法を説明します。
SSDへのデータ書き込み時
この方法では、SSDへのデータ書き込み時、SSDコントローラは図4のような処理を行います。
図2との違いは、CRCを増やすことで各CRCの担当範囲を限定してかつ各範囲で最適な仕組みを適用できるようにしていることです。
ここでは簡単のためにCRCと記載していますが、実際に付与される検査用符号がCRCではないこともあり得ます。 加えて特徴的なのはCRC3です。CRC3は、NANDフラッシュメモリ用誤り訂正符号による誤訂正を検出するために付与されるものです。
SSDからのデータ読み出し時
この仕組みでも、SSDからのデータ読み出し時に行う処理はCRCが増えたこと以外変わりません。
NANDフラッシュメモリから読み出したデータとCRC3に対して誤り訂正を行い、その後CRC3を用いて誤訂正が行われていないかどうかチェックします。そしてCRC3を取り除き新たにCRC2を付与します。
CRC2はデータがホストインターフェースに転送される直前の検査に用いられて除去され、CRC1が新しく付与されてホストインターフェースに送られます。そしてホストインターフェースからホストにデータが転送される時にCRC1による検査が行われます。
NANDフラッシュメモリバスでのエラー検出用
NANDフラッシュメモリバスのソフトエラー、例えば一時的なクロックずれによりデータと位置がずれるなどの転送失敗を検出するには、SSDへのデータ書き込み時の処理フローを図4から図6のように変える必要があります。
図6のようにNANDフラッシュメモリバスの両端でCRCの付与および検査を行えば、NANDフラッシュメモリバスで発生したエラー（ソフトエラー含む）を検出可能です。
NANDフラッシュメモリバスは低消費電力化や広帯域化が進みかつ実装密度も上がり続けていることから、何らかの信頼性向上策が求められています。
この図6の方法はそれを実現する方法のひとつなのですが、これを実現するにはNANDフラッシュメモリ側もCRC計算回路を備える必要があり、なかなか実現が難しいです。
※ 2024年7月の時点では、NANDフラッシュメモリにはDDR5 DRAMに見られるようなWrite/Read CRC機能は実装されていません
このバスの入口と出口におけるCRCの計算および付与と検査をどこまで厳密に行うかは、SSDが実現する信頼性の高さに応じて決まります。
（参考）End-to-End Data Protectionが有効な場合
NVMeやSASなどSCSI由来のストレージプロトコルには、ホストがデータに検査用データを付与してストレージに記録するEnd-to-End Data Protectionと呼ばれる機能があります（以前説明した記事はこちら）。
そのEnd-to-End Data Protectionが有効である場合、図4の仕組みは図7のようになります。
図7を見ると、ホストの付与したCRCが一番内側（データに近いところ）にあり、データがSSDの内部で移動するときには常にこのCRCがついて回ることがわかります。
このホストが付与したCRCは、データ本体と合わせて、SSD内ではSSDコントローラが付与するCRCやその他の誤り訂正符号による保護が常に施された状態となります。
ファームウェアのバグや設計不備によるSDC
これまでに説明したハードウェア起因のエラーによるSDC以外に、FWの設計不備やバグにより発生したエラー（不具合）を要因とするSDCも考えられます。
ひとつの例は、Garbage Collection (GC)などの内部処理時に誤り訂正に失敗してデータを喪失するケースです。
内部処理はホストから受領したコマンドに基づく処理ではないため、内部処理時に発生したこのデータ喪失はすぐにはホストに通知されません。つまりこのエラーもホストから見ると「サイレント」なエラーです。
FWは（というかSSDとして）、このような事象が発生しないように、前回説明したパトロールやリフレッシュを適切な条件で実施する、RAIDなどのより強力な誤り訂正機構を実装する、などの対策を講じる必要があります。
これらの機能がないとSDCが発生してしまいます。
これらの機能を備えていてもデータ喪失が発生した場合にそのエラーを伝播（拡大）させないため、FWはデータが失われたことを適切に管理できることも必要です。
おわりに
この記事では、SSDにおけるSDCについて、NANDフラッシュメモリを除く部分で発生する事象とその対策を説明しました。
具体的には、SSDが搭載するSRAMやDRAMで発生するエラーにはECCが、バスなどでのエラーにはエラー検出用の符号（CRCなど）が適用され、SSDとして切れ目のない保護を実現します。
またFWにも適切な機能の設計と実装が求められます。
もちろん、製品によりこれらの保護の有無や方法は異なります。使用するSSDが備える機能や実現する信頼性は、システム全体が実現すべき信頼性にあわせて定めることが重要です。
他社商標について
記事中には登録商標マークを明記しておりませんが、記事に掲載されている会社名および製品名等は一般に各社の商標または登録商標です。
記事内容について
この記事の内容は、発表当時の情報です。予告なく変更されることがありますので、あらかじめご了承ください。
