前回のあらすじとこの記事のゴール

　前回の記事では、私の日常業務用ノートPCのSSDからS.M.A.R.T.属性を用いて約半年間取得した「書き込みデータ量」などから、「日常使いのクライアントPCの日々の使いかた（ワークロード）」における「1日の書き込みデータ量」を下記のように推定しました。

　1日の書き込みデータ量は最大でも10 GB以上20 GB未満で平均では6 GB未満程度、年換算では高々8 TB程度

　そしてこの推定ワークロードと対象SSDのスペック上の寿命(TBW)から、SSDの寿命を消費し尽くすまでに要する時間を見積もりましたが、その見積もりを有効とみなすには条件があると書きました。その条件とは以下の内容です。

　推定ワークロードと対象SSDのスペック上の寿命算出の前提であるワークロードが一致する

　この記事の目的（ゴール）は、この条件が満たされているのかどうか、の確認です。

　そのため、まず対象SSDのスペック上の寿命算出の前提であるJEDECのクライアントワークロードを説明し、その後、上記推定ワークロードと比較します。

まとめ

前回の記事で示した「私のSSDの使いかた（ワークロード）における書き込みデータ量」は、JEDECのクライアントワークロードにおける書き込みデータ量よりかなり多く、この2つは一致しない
このため、JEDECのクライアントワークロードをもとに導出されたTBWは、「私の使いかた」では、寿命計算には使えない
- JEDECのクライアントワークロードを使って導出されたTBWは、実使用にあたり寿命（寿命を使い切る期間）の算出に使用可能な値ではない
実使用中に寿命残量を把握するには、NVMeであればPercentage UsedというS.M.A.R.T.属性値を用いることが可能

JEDECのクライアントワークロード概要

　一般に「JEDECのクライアントワークロード」と呼ばれているものは、JEDECがJESD219A^[1]の中で"client endurance workload"と呼んでいるものです。

　このクライアントワークロードは、ざっくり2つの内容から構成されます。ひとつはテストの条件で、もうひとつはテスト用コマンドトレースです。

図1：JESD219Aのクライアントワークロードを使ったテストの手順

　前者の「テストの条件」とは、「プリコンディショニング」と呼ばれる事前準備などを指します。この事前準備には、テスト開始前に製品容量全体（正確にはLBA空間全域）にランダムデータを書き込んで使用率100%にすること、などが含まれます。ランダムデータを使うのは、圧縮効果の排除などが目的です。

　後者の「コマンドトレース」とは、Writeコマンド、Trimコマンド、そしてFlushコマンドから成るアクセスログです。このコマンドトレースはさらに、「マスタートレース」と「テストトレース」に分類されます。「マスタートレース」はJEDECが提供しているコマンドトレースです。一方「テストトレース」とは「マスタートレース」から作成した派生のコマンドトレースのことです。JESD219Aは、「マスタートレース」から「テストトレース」を作成する方法も規定しています。

マスタートレースの中身

　JESD219Aが想定するテスト環境と私がデータを取得したSSDの使用環境（実使用環境）は異なりますので、「テスト条件」については議論しません。

　したがって、JESD219Aのクライアントワークロードについて確認すべき内容は、その「コマンドトレース」から想定される「1日の書き込みデータ量」が、私が採取したデータなどから推定した「1日の書き込みデータ量」と一致しているか、になります。

　そこでまず、JESD219Aの「マスタートレース」の中身を確認します。ここで扱うマスタートレースは容量128GBのSSDのもので、その特徴は以下のように記載されています。

標準的なラップトップPCで採取したもの
主たる用途はオフィス作業で、それ以外には写真や音楽そして映像ファイルの格納用
採取期間は7か月

　実際にこのマスタートレースに出現するWriteコマンドで書き込まれたデータ量を合計すると、およそ780GBとなりました。7か月で780GBであれば、単純平均では、1日換算でおよそ3.72GB（780 ÷ 7 ÷ 30）、1年換算でおよそ1.34TB（780 ÷ 7 × 12）となります。

マスタートレースからテストトレースを作る方法

　私がデータを採取したSSDの容量は512GBでした。一方、上記の通りマスタートレースは容量128GBのSSDで採取したものです。512GBのSSDのテストに使用するテストトレースは、マスタートレースから作成しなければなりません。

　JESD219Aは、マスタートレースを取得した容量（ここでは128GB）ではカバーできないテストトレースを作成する方法も規定しています。

　具体的には、より大きな容量のSSD向けに「拡大」する時も、逆に小さな容量のSSD向けに「縮小」する時も、コールドエリアつまりデータが書き込まれないLBA領域のみ拡大・縮小する、としています。

図2：マスタートレースからテストトレースを作成する方法

　この拡大縮小によって読み書きする領域の位置（アドレス；LBA）が変わるため、マスタートレースからテストトレースを作成する際は、マスタートレース内のコマンド（Write、Trimコマンド）のアドレス(LBA)を調整します。

テストトレースの総書き込みデータ量

　前節でマスタートレースからテストトレースを作成する方法を紹介しましたが、ここにはとても重要なことが含まれています。

　というのも、テストトレース作成時に拡大・縮小するのはデータが書き込まれないLBA領域のみですから、マスタートレースから作成したテストトレースでも総書き込みデータサイズはマスタートレースと変わらないのです。

　繰り返しになりますが、テストトレース作成時に行うことは、前節で説明した通り、データが書き込まれないLBA領域のサイズを拡大・縮小し、それに合わせてマスタートレース内のコマンド（Write、Trimコマンド）のアドレス(LBA)を調整することのみです。つまり、コマンド数の増減や各コマンドのサイズ（書き込み領域サイズなど）増減をしているわけではありません。

　これは、SSDの容量が増減しても「使いかた」が変わらなければ書き込みデータ量も変わらないと考えれば、直感的に納得できる内容かと思います。

　結果、128GBのマスタートレースから512GB用のテストトレースを作成しても、「書き込みデータ量」は780GBで変わりません。言い換えると、JEDECのクライアントワークロードに従う限り、「7か月で780GB」という総書き込みデータ量は変わりません。1日の書き込み量およそ3.72GB、1年の書き込み量およそ1.34TB、という値も変わらないことになります。

推定した「書き込みデータ量」とJEDECクライアントワークロードの比較

　ここまでで、この記事の目的である「書き込みデータ量について推定ワークロードと対象SSDのスペック上の寿命算出の前提であるワークロードが一致するかどうか」を検証する準備ができました。

　前回の記事で推定した内容を再掲すると以下の通りです。

1日の書き込みデータ量は最大でも10 GB以上20 GB未満で平均では6 GB未満程度、年換算では高々8 TB程度

　そして今回の記事で明らかにした、同一容量換算でのJEDECクライアントワークロードにおける「書き込みデータ量」は以下の通りです。

1日の書き込み量およそ3.72GB、1年の書き込み量およそ1.34TB

　これらを比較すると、単純平均による計算ではありますが、推定ワークロードのほうが、1日の書き込み量で1.5倍以上、年換算の書き込み量でおよそ6倍、それぞれ大きいです（図3）。

図3：SSDへの書き込み量に関する、実測に基づく推定とJEDECクライアントワークロードの比較

　1日換算の書き込み量の差はそこまで大きくないように見えますが、年換算の書き込み量の差を考えると、この2つのワークロードの差は思った以上に大きいと考えられます。そもそも、年単位の書き込み量がTBWの単位と同じTB単位で差がついている時点でこの差は誤差とは呼べないと考えられます。

　以上より、今回の目的である「書き込みデータ量について推定ワークロードと対象SSDのスペック上の寿命算出の前提であるワークロードは一致するかどうか」は、「一致しない」と結論づけられます。まあそもそも「JEDECのクライアントワークロードと同じ使いかたをする（使いかたになる）」というのがあり得ないわけですね。

　この比較の結果、私のPCにおけるSSDの使いかたはJEDECのクライアントワークロードとはかなり異なるため、JEDECのクライアントワークロードを基準としたSSDのカタログスペック上のTBWは寿命予測には使えないことがわかりました。

　さらに踏み込めば、JEDECのクライアントワークロードと同じ使いかたをする（使いかたになる）のが困難である以上、「JEDECのクライアントワークロードを使って導出されたTBW」は「製品の特徴を非常に大雑把に把握することが可能な参考値程度のもの」であり、「実使用にあたり寿命（寿命を使い切る期間）の算出に使用可能な値ではない」と言えます。

では寿命についてどの値を気にしたら良いのか？

　上記の通り、私の使いかたではSSDのカタログスペック上のTBWを寿命予測に使えないことがわかりました。

　となると、「それでは何を（どの値を）見て寿命を気にすれば良いのか」ということになります。

　この問いに対しては、NVMeであれば、S.M.A.R.T.属性にある"Percentage Used"（使用率）という値が答えの一つになります。この"Percentage Used"という値は、SSDがバックグラウンド処理で消費したNANDフラッシュメモリの寿命なども反映させたものです。図3はNVMe仕様^[2]から抜粋したものです。

![NVMeのSMART属性値の一つ"Percentage Used"](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/549d40d6-fb43-298a-e12f-22a2e47df783.png "NVMeのSMART属性値の一つ"Percentage Used"")
図3：NVMeのSMART属性値のひとつ"Percentage Used"

　ちなみに、NVMeの"Percentage Used"に相当する値はATA Command Set（ACS；SATAが採用）にも存在します。それは、Device Statistics logのSolid State Device Statisticsにある、"Percentage Used Endurance Indicator"という値（サイズは1バイト）です。名前が似ていますね。図4がACS-3^[3]の抜粋です。この通り、NVMeのPercentage Usedと意味は同じです。

図4：ACS-3のPercentage Used Endurance Indicatorの定義

　このDevice StatisticsというログページをサポートしているかどうかはSSDによって異なりますが、もしサポートしていれば、NVMeのPercentage Usedと同じ解釈ができるので、統一的に扱うことができます。

　SATA SSDの場合、もしかしたらS.M.A.R.T.属性にこれらPercentage Usedと同内容の属性値が存在する可能性もありますが、ACSのS.M.A.R.T.属性値の種類や内容はメーカーにより異なりますので、個別対応が必要となります。

まとめ

　今回の記事では、私の実際に使用中のSSDから採取したデータなどから推定した「日常使いのクライアントPCの日々の使いかた（ワークロード）」における「1日の書き込みデータ量」が、SSDのカタログスペック上のTBWの算出に使われたJEDECのクライアントワークロードと一致しているかどうかを調べました。

　調べた結果、私の使いかたはJEDECのクライアントワークロードとは異なり、SSDのカタログスペック上のTBWは寿命予測に使えないことがわかりました。

　TBWの代わりとなる寿命の消費度合いを知る方法としては、NVMeであればS.M.A.R.T.属性のPercentage Usedという値が使えることも示しました。

　SSDのカタログスペックに記載されたTBWの多くは、JEDECのクライアントワークロードを用いて導出されたものです。このため、実際の使用に供しているSSDの寿命予測に利用するにはその実際の「SSDの使いかた」とJEDECのクライアントワークロードの差が重要になります。というか普通は異なります。

　この「SSDの使いかた」の違いがSSDの内部処理の違いを引き起こし、かつこの内部処理の違いはSSD外部からではわからないことがほとんどであるため、カタログスペック上のTBWは実使用中の寿命予測には使えない、と言えます。

参考文献

[1] JEDEC, "SOLID-STATE DRIVE (SSD) ENDURANCE WORKLOADS", JESD219A, July 2012
[2] NVM Express, "NVM Express Base Specification", Revision 1.4b, September 2020
[3] T13, "ATA/ATAPI Command Set - 3 (ACS-3)", Revision 4o, August 2013

ライセンス表記

この記事はクリエイティブ・コモンズ表示 - 継承 4.0 国際ライセンスの下に提供されています。