はじめに
SSDのスペック（製品仕様）には、容量や性能、寿命に関連する数値、各種環境要件（例：動作保証温度）など、様々な仕様が記載されています。
それらの中には、以下のような機能が存在します。
- 内容があまりよく知られていない機能
- 名前が似ていても内容が異なる機能
- そもそも明確に規定されておらずメーカーにより内容が異なる機能
SSDを選定・購入・使用する立場からみると、2や3に相当する機能の存在は混乱のもとですので、1に相当する機能も含め、今後そのような機能を説明したいと思います。
最初となる今回は、End-to-End Data ProtectionとEnd-to-End Data Path Protectionを説明します。1語("Path")の有無で大きな違いがあります。
まとめ
- End-to-End Data ProtectionとEnd-to-End Data Path Protectionはどちらも、発生するエラーからデータを保護してデータインテグリティを保障する機能だが、保護可能範囲が異なる
- End-to-End Data Protectionは標準化された機能だが、End-to-End Data Path Protectionは標準化された機能ではない
- End-to-End Data Protectionはホストとストレージ両方の対応が必要だが、End-to-End Data Path Protectionはストレージだけの対応で良い
保護可能範囲、使われるシステム、メリットとデメリット
End-to-End Data (Path) Protectionはともに、ストレージのデータインテグリティ（無理やり和訳すると「データの整合性・一貫性」）を保障するための機能です。
「データインテグリティ」とは、言い換えれば「ホストから書き込まれたデータをホストから正しく読み出せること」であり、ストレージの最も重要な機能（というか要件）です。
この機能に支障を及ぼすエラーへの対策には、原因にあわせて様々な方法があり実際に施されていて、End-to-End Data (Path) Protectionもそのひとつです。
具体的な仕組みの説明に入る前に、この2つの保護機能について、保護できる範囲、使用されるシステム、そしてメリットとデメリット、を説明します。
保護可能範囲
End-to-End Data ProtectionとEnd-to-End Data Protectionは保護可能範囲が異なります。これを表したものが図1です。
図1：End-to-End Data (Path) Protectionの保護可能範囲の違い
図1の通り、End-to-End Data Protectionはホスト・ストレージ間の通信経路も保護可能ですが、End-to-End Data Path Protectionはストレージ内を保護可能範囲とする機能です。
この「保護範囲が異なる」ということは、「機能名内の"End"が指す位置が異なる」と言い換えることができます。そこで、End-to-End Data (Path) Protectionそれぞれの"End"がどこか（どの位置を指すのか）を示したものが表1です。
表1：2つの"End"はどこか？
| End | to | End | |
|---|---|---|---|
| End-to-End Data Protection | ホスト・ストレージ間のパスのホスト側の端 | to | メディア |
| End-to-End Data Path Protection | ホスト・ストレージ間のパスのストレージ側の端 | to | メディア |
図1と比較するとわかりやすいと思います。これが保護可能範囲の違いです。
End-to-End Data Protectionは主にSCSI（SAS含む）ストレージで使われてきました。SCSIはパラレルインターフェースであり、用途や使いかたによってはホスト・ストレージ間でのデータ化けが無視できない場面もありました。そのため、ホスト・ストレージ間も保護範囲に含んでいます。
一方End-to-End Data Path Protectionは、ストレージ内でメディア向け誤り訂正符号では保護できない部分（主にコントローラ）を保護可能範囲に入れた機能だと言えます。
使われるシステム
End-to-End Data ProtectionとEnd-to-End Data Path Protectionは使われるシステムが異なります。
End-to-End Data Protectionは、扱うデータの一貫性に非常に高い信頼性が求められるエンタープライズシステムで用いられます。金融システム（例：取引等トランザクションの保存）用ストレージや、政府・企業等の基幹サーバ・データベース用ストレージなどがその例です。
それらのシステムでは、要因を問わずストレージから読み出したデータの間違いが大きな損害・障害に繋がるため、End-to-End Data Protectionを用いてホスト・ストレージ間のパスも保護し、データインテグリティの保障を厚くします。
End-to-End Data Protectionはストレージ側だけでなくホスト側の対応も必要な機能であり、上記のようなシステムではEnd-to-End Data Protectionに対応したホスト側機器およびソフトウェアが使われます。
一方End-to-End Data Path Protectionは、最近ではコンシューマ向けSSDのコントローラでも対応しています。この結果、コンシューマ向け機器をはじめとした幅広いシステムで使われています。
End-to-End Data Path Protectionは、SSDコントローラの製造プロセス微細化し、SSDコントローラ内で発生するエラーへの対応が重要視されるにしたがい実装されはじめた機能です。
私が知る限り、End-to-End Data Path Protectionのほうが後から登場した機能です。そのため、既存のEnd-to-End Data Protectionと区別するために"Path"という1語を追加したのだと思います。
メリットとデメリット
End-to-End Data ProtectionとEnd-to-End Data Path Protectionそれぞれのメリットとデメリットはほぼ表裏一体です。
End-to-End Data (Path) Protectionのメリットとデメリットをまとめると表2のようになります。
表2：End-to-End Data (Path) Protectionのメリットとデメリット
End-to-End Data Protectionは保護可能範囲が広い代わりにホストとホストインターフェースの対応も必要で、対応製品も少ないです。
End-to-End Data Protectionに対応したホストインターフェースはSCSI (SAS)、NVMe程度に限られるため、対応SSDはSAS SSDやハイエンドNVMe SSDの一部などに限られています[1][2][3]。
一方、End-to-End Data Path Protectionは保護可能範囲がストレージ内にとどまりますがその分ホストの対応は不要で対応製品も最近は多いです。
その他には、End-to-End Data Protectionは機能が標準化されているのに対し、End-to-End Data Path Protectionは機能が標準化されていないことが挙げられます。
したがって、End-to-End Data Path Protectionは、その機能や実現方法がメーカーによって異なる可能性があります。
保護の仕組み
それではEnd-to-End Data (Path) Protectionの具体的な内容についてご説明します。
この機能が保護するエラー
まず、End-to-End Data (Path) Protectionが保護するエラーを説明します。
なお、ここで説明するエラーはあくまでも例です。そして、これらのエラーに対してはSRAMやDRAMの誤り訂正機構をはじめ様々な対策方法が存在し、メーカーは求められる信頼性を満足するよう、使用する部品などに応じて対策を施して、製品を設計・開発していることをあらかじめ記載しておきます。
ホストがストレージにデータを書きこむとき、ストレージは図2のような処理を行います。
図2：通常時のライト処理
そして、書き込んだデータをホストが読み出すとき、ストレージは図3のような処理を行います。
図3：通常時のリード処理
ここで、ライト時にコントローラ内で何らかの理由でデータが化けたとします。すると、図2で示した処理は図4のようになる可能性があります。
図4：データが化けたときのライト処理
図4のエラー発生位置はあくまで例です。とにかく図4 (3)の処理の前にエラー（データ化け）が発生してそのエラーが放置されたという想定です。
図4のようにメディア（例えばNANDフラッシュメモリ）でのエラーを検出・訂正するための誤り訂正用データ（パリティ）を作成する前にデータが化けてしまうと、化けたデータからパリティを生成してしまいます。つまり、図4の(4)でメディアにライトされるのは、化けたデータと、化けたデータ用に作成されたパリティ、になります。
このため、図4の書き込みの後に図3の読み出し処理をした場合、図3 (5)の誤り訂正処理は図4 (2')で生じたエラーを訂正できません。その結果、図3 (5)の誤り訂正処理で訂正に成功しても訂正結果は「化けたデータ」であり、ストレージからホストへ転送されたデータは「化けたデータ」となります。
「ホストから書き込まれたデータをホストから正しく読み出せること」が満たされないケースは、図4のケース以外に図5のようなケースも考えられます。
図5：リード処理でのデータ取り違え
コントローラでは、ホストから要求されたデータ（最新データ）が記録されているメディア上の位置を調べ、判明した場所からデータを読み出します。この「メディア上の位置」を調べる際に何らかの理由で異なる場所だと判断してしまう可能性があります。
すると、その「間違った場所」から読み出したデータをホストへ転送してしまいます。
この図4や図5のようなエラーにより「ホストに間違ったデータを返してしまうこと」を防ぐ方法のひとつが、End to End Data (Path) Protectionです。エラーの発生を防ぐのではなくエラーが発生しても検出可能にするということがポイントです。
End-to-End Data Protectionとは
End-to-End Data Protectionは、ホストとストレージが協力して上記のようなエラーに対応する方法です。
というのも、End-to-End Data Protectionという方法は、ホストが別途作成した付加データ（メタデータ）を用いる方法だからです。具体的には、図6のような動作になります。
図6：End-to-End Data Protectionの基本的な仕組み
ホストは、ストレージにデータをライトする際に、データ（512バイトや4096バイト）に対応したProtection Information (PI)と呼ばれるメタデータをストレージに送ります。そして、ストレージからデータをリードする際に、ライト時に送ったメタデータも受領し、そのメタデータが正しいこと（例：ライト時のメタデータと一致すること）を検査することで受領したデータが正しいことを確認する、という仕組みです。
このProtection Informationの内容は、仕様で表3のように規定されています[4][5]。
表3：Protection Informationの内容
| 名称 | サイズ | 内容 |
|---|---|---|
| Guard | 2 バイト | データ部分から計算したCRC16 |
| Application Tag | 2 バイト | ホスト（Host Bus Adapter (HBA)を含む）が自由に使えるフィールド |
| Reference Tag | 4 バイト | データに対応するLBA (Logical Block Address)相当の値 |
End-to-End Data Protectionという名称はNVMe仕様で使われているものですが、その機能はSCSIの機能をベースにしています。これは、NVMeの仕様がSCSIの影響を大きく受けており、SCSIのProtection Informationの仕様をほぼそのまま取り込んだ結果です。
エラー検出の仕組み
このProtection Informationを使うことで、図4や図5で示したエラーを検出できます。
まず、図4で示した現象のように、何らかの理由で化けたデータがメディアに書き込まれてしまい、リード時にそのデータが読み出されてホストに転送された場合です。
図7：Protection Informationのチェックでデータ化けを検出する例
この場合、図7のように、ストレージからデータ（化けたデータ）を受領したホストが、受領したデータ（Protection Informationを除く）から計算したCRC16の値と、Protection Information内のGuardフィールドの値を比較することで、データが化けているかどうかを検査できます（図7 (8)）。
次に、図5で示した現象のように、何らかの理由でストレージがホストの要求したLBAではないLBAのデータを読み出してホストに転送した場合です。
図8：Protection Informationのチェックでデータ取り違えを検出する例
この場合、図8のように、ストレージからデータ（要求したLBAとは異なるLBAのデータ）を受領したホストが、自分がデータを要求したLBAと受領したデータのProtection Information内のReference Tagフィールドの値を比較することで、データが取り違えられていないかどうかを検査できます（図8 (7)）。
このように、Protection Informationを使用することで、ストレージ内で発生し得るいくつかのエラーを検出できます。
なお、ここでは省略しますが、このProtection Informationを利用してストレージ内でエラーチェックを行う方法もあります。ストレージ内でこまめにエラーチェックを行うと、エラー発生場所の絞り込みが可能になります。
ストレージが対応しているか判断する方法
ストレージがこのEnd-to-End Data Protectionに対応しているかどうかをスペック（仕様）で判断するには、Protection Informationへの対応が記載されているか、"T10 DIF"や"DIX"への対応が記載されているか、そして520バイトや4104バイトなどのセクタ長に対応しているか、などの方法があります。
DIF (Data Integrity Field)とDIX (Data Integrity eXtensions)はどちらも、ホストがProtection Informationを作成してストレージに送る方法、そしてストレージから受け取ったProtection Informationをチェックする方法です[6]。したがって、ストレージがDIFもしくはDIXに対応していれば、そのストレージがEnd-to-End Data Protectionに対応していると言えます。
520バイトや4104バイトというセクタ長は、実は「512バイト＋8バイト」や「4096バイト＋8バイト」のことを指し、この「8バイト」がProtection Informationのことを意味します。つまり、ストレージがこの520バイトや4104バイトなどの中途半端なセクタ長をサポートしていたら、それはProtection Informationのサポートを意味し、End-to-End Data Protectionのサポートを意味します。なお、520バイトや4104バイトの他にも、528バイト（512バイト＋8バイト＋8バイト）や4112バイト（4096バイト＋8バイト＋8バイト）などのバリエーションもあります。
End-to-End Data Path Protectionとは
End-to-End Data Path Protectionはストレージに閉じた仕組みで、前半に説明した通り標準化された機能ではありません。
つまり、SSDのカタログ（仕様）に「End-to-End Data Path Protection対応」と書かれていても、メーカーごとに機能（何ができるのか）や実現方法（仕組み）が異なる可能性があります。
したがって、ここで「End-to-End Data Path Protectionは～～という動作です」とは説明できません。
エラー検出の仕組み
「End-to-End Data Path Protectionは～～という動作です」とは説明できませんが、図4や図5で示したエラーを検出するための仕組みとしてのEnd-to-End Data Path Protectionの例を説明します。
それは、Protection InformationのGuardフィールドのようにデータから計算したダイジェスト（CRCなど）を使う方法です。
まず、図4で示した現象のように、コントローラ内で何らかの理由で化けたデータがメディアに書き込まれそうになった場合です。
図9：データ化けを検出するEnd-to-End Data Path Protectionの仕組みの例
この場合、図9のように、ストレージは、ホストからデータを受領するとすぐにそのデータ（化けていないデータ）からダイジェスト（CRCなど）を計算します（図9 (1')）。
そして、少なくともメディア（例：NANDフラッシュメモリ）のエラーに対応するための誤り訂正用データ（パリティ）を計算する直前に、パリティの計算に使用するデータから再度ダイジェストを計算し（図9 (3)）、ホストからデータを受領した時に計算したダイジェスト（図9 (1')）と比較します。何らかの理由でデータ化けが発生した場合（図9 (2')）はこの2つのダイジェストが一致しないので、データ化けを検出できます。
次に、図5で示した現象のように、何らかの理由でストレージがホストの要求したLBAではないLBAのデータを読み出した場合です。
図10：データ取り違えを検出するEnd-to-End Data Path Protectionの例
この場合、図10のように、読み出したデータをホストに転送する直前（コントローラから離れる直前）に、転送しようとしているデータのダイジェストを計算します（図10 (6)）。この時、ホストから要求されたLBAをダイジェストの計算対象に加えます。図9 (1')でデータライト時にダイジェストを計算する際に同じくホストから指示されたLBAを計算対象に加えておくことで、図10 (6)でダイジェストが一致しない場合、LBAの不一致つまりデータの取り違えが発生した可能性を検出できます。
End-to-End Data Path Protectionの機能と実現方法としては、このようなEnd-to-End Data Protectionと似た機能と実現方法が考えられます。
いずれにしても、End-to-End Data Path Protectionは標準化された機能ではなく、メーカーごとに機能や仕組みが異なる可能性があるため、機能の内容や仕組みをメーカーに確認する必要があります。
まとめ
今回は、SSDのスペック（仕様）に記載されていることがあるEnd-to-End Data ProtectionとEnd-to-End Data Path Protectionの違いを説明しました。
どちらの方法もストレージの信頼性（データインテグリティ）をより高いレベルで保障するための機能です。
一方で、保護可能範囲の違いや機能の標準化の有無をはじめとしたメリット・デメリットがあるため、利用にあたっては十分な検討が必要です。
SSDのスペックを読み解く際のご参考になれば幸いです。
References
[1] Seagate、「Nytro SAS SSDシリーズ」、2021年4月5日閲覧
[2] Micron、"Micron 7300 SSD"、2021年4月5日閲覧
[3] Kioxia、「PM6-Mシリーズ」、2021年4月5日閲覧
[4] T10, "SCSI Block Commands - 3 (SBC-3)", Revision 21, November 2009
[5] NVM Express, "NVM ExpressTM Base Specification", Revision 1.4b, September 2020
[6] Jim Williams and Martin Petersen, "Data Integrity in the Storage Stack", SNIA Storage Developer Conference 2008, Santa Clara, CA, September 2008
ライセンス表記
この記事はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。