OCP向けNVMe SSD仕様でS.M.A.R.T.属性が大幅に追加されていた件

# はじめに

　[以前の記事](https://qiita.com/ken-yossy/items/4d1f84f3c783caccc336)で、NVMeが定めるS.M.A.R.T.属性について以下のように書きました。

> 各社のSATA SSDにおけるS.M.A.R.T.属性の傾向と比較すると、（NVMeが定めるS.M.A.R.T.属性は）NANDフラッシュメモリに関連する属性、特にNANDフラッシュメモリのエラーを直接示す属性がないことが特徴です。また、SATA SSDのS.M.A.R.T.属性に見られた、「（NANDフラッシュメモリの）Program / Erase回数」のような属性も存在しないことがわかります。

　これは、各社のSATA SSDがS.M.A.R.T.属性としてよく備えている、SSD内で発生したNANDフラッシュメモリの各種エラーや、Program / Erase回数の最大値や平均値、（残）寿命計算に必要な統計情報などが、NVMeが標準仕様として規定したS.M.A.R.T.属性には存在しないことを指摘したものです。

　これに対して、データセンター向け各種技術の標準仕様を策定している[Open Compute Project (OCP)](https://www.opencompute.org/)が作成したNVMe SSD向け仕様<sup>[1]</sup>では、その「SATA SSDにはよくあるのにNVMeの標準仕様にないS.M.A.R.T.属性」と思われる内容を独自に追加しています。

　今回の記事では、このOCPが定めたNVMe SSD向けS.M.A.R.T.属性について説明します。

# まとめ

* OCPが策定した「OCP向けNVMe SSD仕様」には、NVMe標準仕様にはないS.M.A.R.T.属性が追加されている
* 追加規定された属性には、NANDフラッシュメモリブロックの最多・最少消去回数といった、SATA SSDのS.M.A.R.T.属性では良く見られる属性がある
* 追加された属性を正しく理解するには、SSDおよびNANDフラッシュメモリの深い理解が必要となる

# OCPが定めたNVMe SSD向け仕様とは
　OCPでは、"NVMe Cloud SSD Specification"というタイトルの文書を発行しています。記事執筆時点での最新版はバージョン1.0.3（2020年3月18日発行）となっています。検索すると仕様書(PDF)を直接ダウンロードするリンクが見つかります。

![OCP Cloud SSD Specificationの表紙](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/34074f7b-e83b-e7c9-d033-cd10ef4ce6ef.png "OCP Cloud SSD Specificationの表紙")
図1：OCP Cloud SSD Specificationの表紙

　この仕様書は17章（15章＋付録2章）で構成されていて、「OCP向けNVMe SSD」が満たすべき要件がまとめられています。例えば以下のような内容が記載されています。

* NVMe仕様ではオプションとされているコマンドや機能の中でサポートすべきもの
* 独自のログページや機能
* 信頼性や寿命
* フォームファクタ
* セキュリティ
* 衝撃や振動のテスト条件
* 性能要件

　まるで、購買側が調達元に提示するProduct Requirement Document (PRD)（日本語で言う「製品要求仕様書」）のようですが、それがOCPがこの仕様書を作成した目的だと思われます。

　と言うのも、購買側（データセンター事業者など）と調達元（SSD製造者）との間で「OCPのCloud SSD仕様」という共通言語をベースとして会話することで、SSDの開発と導入がよりスムーズになることが期待できるからです。ざっと読んでみると曖昧な部分も結構ありますが……

　今回ご紹介する「独自のS.M.A.R.T.属性」は、上記の「独自のログページや機能」に相当します。

# 独自S.M.A.R.T.属性の内容
　この仕様が定める独自S.M.A.R.T.属性の内容は、仕様書4.8.4節"SMART Cloud Attributes Log Page"に記載されています。このログページは、ログページID C0hで取得できることが求められています。

　NVMe仕様<sup>[2]</sup>では、ログページIDのうちC0hからFFhまでを「ベンダ固有」と規定しています。つまり、NVMe仕様上この範囲のログページIDであれば自由に使用できるので、OCPとして、C0hに割り当てたのでしょう。

　余談ですが、「ベンダ固有」と規定されている範囲からどの値を選択するか、ということは結構重要です。なぜかと言うと、「ベンダ固有」なので別々のベンダで同じIDに異なる内容のログや機能を割り当ててしまうことがあるからです。

　具体的な独自S.M.A.R.T.属性の内容（23項目）は表1の通りです。

**表1：OCP Cloud SSD Specificationが規定する独自S.M.A.R.T.属性（23項目）**

| 項目名 | 内容（筆者訳） |
|-------|------|
| Physical Media Units Written | メディア（NANDフラッシュメモリ）に書き込まれたデータのサイズ（バイト単位）。この値には、ユーザデータだけでなくメタデータやシステムデータも含まれる。|
| Physical Media Units Read | メディア（NANDフラッシュメモリ）から読み出したデータのサイズ（バイト単位）。この値には、ユーザデータだけでなくメタデータやシステムデータも含まれる。|
|Bad User NAND Blocks | 「使わない」ことにした、ユーザデータ用NANDフラッシュメモリブロックの数|
| Bad System NAND Blocks | 「使わない」ことにした、システムデータ用NANDフラッシュメモリブロックの数|
| XOR Recovery count | XORが発動した回数。ユーザデータだけでなくNANDフラッシュメモリからの全ての読み出しが対象。|
| Uncorrectable read error count | あらゆる手段を用いてもデータを訂正（復元）できなかった回数。ホストに「アンコレクタブルリードエラー」を返した回数になる。|
| Soft ECC error count | 第一段の誤り訂正機構(ECC)では訂正できず、中間(intermediate)の訂正・復元機構の起動が必要となった回数。ユーザデータだけでなくNANDフラッシュメモリからの全ての読み出しが対象。|
| End to End Correction Counts | NANDフラッシュメモリに記録したデータ向けのECCを除く、ECCやCRCといった機能が検出・訂正したデータ誤りの数。DRAMやSRAMのビットエラーもこれに含まれる。|
| System data % used | システムデータ用NANDフラッシュメモリブロックの消去回数を、保証消去（書き換え）回数に対して正規化した値。"100"は予想寿命を消費したことを意味する。|
| Refresh Counts| データ保護のために再割り当てされたNANDフラッシュメモリブロックの数。空き容量作成のためのいわゆる"Garbage Collection"による再割り当てブロック数は含まない。|
| User data erase counts | ユーザデータ用NANDフラッシュメモリブロックの消去回数（最高回数と最低回数） |
| Thermal throttling status and count | サーマル（温度）スロットリングの現時点での設定と、サーマルスロットリングが発生した回数|
| PCIe Correctable Error count | PCIeインターフェースの訂正可能エラー（"bad TLP"など）の合計回数|
| Incomplete Shutdowns | 全てのユーザデータやメタデータがメディア（NANDフラッシュメモリ）に書き込まれずに電源が落ちた（シャットダウンした）回数|
| % Free Blocks | フリー（利用可能な）ブロックの数（正規化した値）|
| Capacitor Health | シャットダウン時に電源を供給するためのキャパシタに蓄えられている電力量（正規化した値）|
| Unaligned I/O | デバイス（SSDのこと）の管理単位サイズに対して、アクセス範囲の先頭LBAがアラインしていないアクセスの回数|
| Security Version Number | 動作中ファームウェア(FW)のセキュリティバージョン番号|
| NUSE | Identify Namespace Dataの"NUSE"フィールドのコピー。「割り当てられているLBA」の数|
| PLP Start Count | Power Loss Protection (PLP)処理が発動した回数|
| Endurance Estimate | 残寿命。今後ずっとWrite Amplification Factor (WAF)が1のままと仮定した場合に、メディアの残りの寿命でホストから書き込めるデータサイズ（バイト）で表現される。|
| Log Page Version | このログページのバージョン|
| Log page GUID | このログページの識別子(Globally Unique Identifier; GUID) |

　以下、いくつかの属性をピックアップして説明します。

## Physical Media Units Written / Read
　NANDフラッシュメモリにアクセスしたサイズを示す"Physical Media Units Written / Read"や、消去回数（書き換え回数）を示す"User data erase counts"、そしてバッドブロック数を示す"Bad User / System NAND Blocks"など、SATA SSDのS.M.A.R.T.属性には良く見られる属性が含まれていることがわかると思います。

　仕様書には、"Physical Media Units Written"という属性について以下のように記載していて、ホスト側でWrite Amplification Factor (WAF)を計算したいことがわかります。

> It shall be possible to use this attribute to calculate the Write Amplification Factor (WAF).
 
　この属性値とNVMe標準仕様のS.M.A.R.T.属性に含まれる"Data Units Written"を用いてホスト側でWAF（の概算値）を計算することにより、SSDの寿命消費の効率をチェックするのだと思われます。

## Refresh Counts
　その他にも、Garbage Collectionを除いたブロック再割り当ての回数を示す"Refresh Counts"などは特徴的です。この属性値が増える事象としては、長期放置（Data Retention対策が必要）や読み出し回数増加（Read Disturb対策が必要）への対応などが考えられますが、それらの事象の発生を別途知りたい、というのは細かいです。

　この属性値を見ることでわかるのは、長期間読み書きされないデータが存在することや、逆に高い頻度で読み出しのみ行われるデータが存在するということなので、「別のティア(tier)に移動させたほうが良いデータが存在する」ことを知るために使われるのかもしれません。

## 誤り訂正機構関連属性
　また、SSD内の誤り訂正機構に関する属性も細かいです。メディア（NANDフラッシュメモリ）のデータ誤りに対する誤り訂正機構については、"XOR Recovery count"と"Soft ECC error count"という2つの属性があります。

　前者は、名称に"XOR"が含まれてはいますが、実際には[以前説明したRAIDのような誤り訂正機構](https://qiita.com/ken-yossy/items/0f43eb4d7c3cdbc47713)のことを指していて、実装がXORかどうかは関係ないと思われます。いわゆる大規模エラー対策としての誤り訂正機構が発動した回数のことですね。

　一方後者は、前者とは異なりいわゆる「ランダム（ビット）エラー」向けの誤り訂正機構に関するものです。SSDコントローラには、メディアのランダムエラー向け誤り訂正機構として、誤り訂正能力が異なる複数の方式を備えるものがあります。このOCPの仕様によると、最も訂正能力の低い第1段の誤り訂正機構で訂正できず、次に誤り訂正能力の低い第2段の誤り訂正機構を発動した時にこの属性値を更新すること、と規定しています。

　2番目に訂正能力が低い誤り訂正機構の発動を記録する、というのは、誤りビット数の増加を早い段階で検出することに繋がりますから、誤りビット数の増加に気を配っているように見受けられます。

## Power Loss Protection (PLP)関連属性
　Power Loss Protection (PLP)関連属性としては、"Capacitor Health"と"PLP Start Count"の2つが挙げられます。

　PLPとは、**メーカーによってかなり大きな差がありますが**、概して「SSDが何らかの要因でシステムから供給されている電源を準備なしに突然喪失した際に、SSDとしてデータやシステムの整合性を保つための機能」と定義できます。

　このPLPを実現するために以前より採られている方法が「SSDに搭載したキャパシタ（コンデンサ）に電力を貯めて、システムから供給されている電源を喪失した時にキャパシタに貯めておいた電力を使う」というものです。

　このOCPの仕様では、上記キャパシタの存在を考慮して、キャパシタの状態を示す値を属性値として規定しているものと思われます。

## Bad User / System NAND Blocks
　SSDやNANDフラッシュメモリのことをお聞きになったことがあれば、「バッドブロック」という単語も聞かれたことがあるかと思います。この"Bad User / System NAND Blocks"という2つの属性は、この「バッドブロック」に関するものです。「バッドブロック」とは、ユーザデータ・システムデータにかかわらず、データの記録に使用しないことを決めたブロックのことを指します。

　SSDが、搭載するNANDフラッシュメモリのブロックを「バッドブロック」として扱う条件は、NANDフラッシュメモリのメーカーや種類、そしてSSDコントローラによって異なります。「データの読み出し時に規定以上の誤りビット数を検出した」とか、「データの書き込みに失敗した」とか、「消去処理に失敗した」など、いくつかの判断基準が考えられます。複数の基準（事象）を組み合わせることもあります。

　バッドブロックが増えるという事象はNANDフラッシュメモリの疲弊を示す事象と考えられることから、この属性値は、例えば単位時間あたりのバッドブロックの増加数を監視することでSSDの異変をより早期に察知する、などを目的として規定されていることが考えられます。

# OCP向けNVMe SSD仕様への準拠を謳っているSSD
　この仕様に準拠していることを謳うSSDは既に存在します<sup>[3][4]</sup>。とはいえ、OCP向け、つまりデータセンター向けSSDですので、私たち個人がそう簡単に購入・使用できるような代物ではありません（個人でなくても色々と難しいです……）。

　ちなみに、OCP向けNVMe SSD仕様では、対象となるフォームファクタにはM.2の他にE1.SおよびE1.Lがあります。E1.SおよびE1.Lは、"Enterprise and Data Center SSD Form Factor (EDSFF)"と呼ばれるフォームファクタ群に分類されます。EDSFFに含まれるフォームファクタについてはSNIAのWebページ<sup>[5]</sup>に記載されている説明がわかりやすいと思います。また、2020年秋時点での状況については、解説記事（英語）<sup>[6]</sup>が参考になると思います。

# まとめ
　この記事では、OCPが定めたNVMe SSD仕様に規定されている、NVMe標準仕様にはないS.M.A.R.T.属性の内容を説明しました。

　追加された属性には、NANDフラッシュメモリブロックの最多・最少消去回数といった、SATA SSDのS.M.A.R.T.属性では良く見られる属性があることや、PLPといったコンシューマ向けには不要と思われる機能に関する属性があることが特徴です。

　これらはいずれも、データセンターというある意味特殊な環境で使用されるSSDに対して、データセンターを運営する側が必要とする情報であると考えることができます。

　ただし、この追加された属性の内容と意味を正しく理解するには、SSDおよびNANDフラッシュメモリの深い理解を要することに注意が必要です。

# 参考文献
[1] Open Compute Project, _"[NVMe Cloud SSD Specification](https://www.opencompute.org/documents/nvme-cloud-ssd-specification-v1-0-3-pdf)"_, version 1.0.3, March, 2020
[2] NVM Express, _"NVM Express<sup>TM</sup> Base Specification"_, Revision 1.4b, September, 2020
[3] キオクシア、_「[業界初、PCIe<sup>(R)</sup> 4.0対応でOCPの「NVMe<sup>TM</sup>クラウドSSD仕様」に準拠したSSDの評価用サンプルの出荷について](https://business.kioxia.com/ja-jp/news/2020/20201104-1.html)」_、2020年11月20日閲覧
[4] FADU, _"[FADU Technology Announces World’s First E1.S SSDs in the Channel](http://www.globenewswire.com/fr/news-release/2020/11/09/2122684/0/en/FADU-Technology-Announces-World-s-First-E1-S-SSDs-in-the-Channel.html)"_, Retrieved on November 20, 2020
[5] Storage Networking Industry Association (SNIA), _"[Solid State Drive Form Factors](https://www.snia.org/forums/cmsi/knowledge/formfactors)"_, Retrieved on November 20, 2020
[6] Billy Tallis, _"[EDSFF Form Factor Updates In 2020: New Versions, Growing Adoption](https://www.anandtech.com/show/16248/edsff-form-factor-updates)"_, Retrieved on November 26, 2020

# ライセンス表記
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="クリエイティブ・コモンズ・ライセンス" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />この記事は <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンス</a>の下に提供されています。