X25-MのE9が減る（続）

X25-MのS.M.A.R.T.のE9が減っていく件は、24日時点で50になったが、これ以上ユーザーレベルで分かることはなさそうなので、一旦幕引きとする。

ここまでの結論をいえば、E9が使用歴と相関関係があるのは明らかだが、残り寿命といったものではないと思う。というのも、やり方によってはあまりに短時間（8分前後）で減ることが分かったので。いずれにせよ、Intelからの説明がない限り不明である。

1. X25-Mの寿命計算

議論の前提として、X25-M（80GBモデル）の寿命（最低書き換え量）に関しては、現在のところ3通りの計算があり得る。

第一に原理的な計算として、Intelの以前の資料とAnandTechによる予備領域の情報（7.5-8%らしいので、ここでは8%と仮定）に従えば以下のようになる。

{156,301,488（公称セクタ数）×512Byte}（容量）×10,000（MLCフラッシュの書き換え寿命）÷{1.1（Write Amplification）×1.04（Wear Leveling Efficiency）}（SSD特有の機能）×1.08（予備領域分）≒800TB（生の最低書き換え量）×0.94≒755.5TB

[参考]
AnandTech: Intel X25-M SSD: Intel Delivers One of the World's Fastest Drives
PC Watch: 元麻布春男の週刊PCホットライン: SSDの寿命

これは見てのとおり生の最低書き換え量とあまり変わらないので、逆にいえば、原理的にあり得る最大限の数字と見てよいと思う。

第二として、X25-Mの発表時（2008年8月）のIntelの資料に「>100GB/day for 5 years」「5+ Years Useful Life for Client PCs」という記述があるので、これに従えば以下のようになる。

100GB×365（日）×5（年）（閏日は省略。以下同じ）＝182.5TB

[参考]
PC Watch: 本田雅一の週刊モバイル通信: IntelがIDFで1.8/2.5インチの高速SSDを発表
HotHardware: Intel X25-M 80GB SSD, Intel Ups The Ante

第三として、これが現在のIntelの公式情報になると思うが、X25-Mのデータシート（2009年5月版）では「3.5.4 Minimum Useful Life」の項に以下の記述がある。

The drive will have a minimum of 5 years of useful life under typical client workloads with up to 20GB of host writes per day.

これに従えば以下のようになる。

20GB×365（日）×5（年）＝36.5TB

なお、この2009年2月版ではこの項は以下のようなものだった（それ以前のものは残念ながら保存していない）。

A typical client usage of 20 GB writes per day is assumed. Should the host system attempt to exceed 20 GB writes per day by a large margin for an extended period, the drive will enable the endurance management feature to adjust write performance. By efficiently managing performance, this feature enables the device to have, at a minimum, a five year useful life. Under normal operation conditions, the drive will not invoke this feature.

5月版では記述が随分減っているが、特に「the endurance management feature to adjust write performance」と「this feature enables the device to have, at a minimum, a five year useful life」が消えている。

これは以前から引っ掛かっていた部分で、この「endurance management feature」の中身は不明なるも、単純に考えれば、想定されている20GB/日を大きく超えるライトがあれば、最低5年間の寿命を保たせるためにライト速度を抑える機能のようである。ここで、理論的な仮定になるが、もしある人が5年間のうち半分の時間にライトを行うとしたとき、ライト量を寿命の範囲内に収めるには速度をどれだけに抑えればいいかといえば、最も長い原理的な計算の場合で以下のようになる。

755.5TB÷{60×60×24×365(日）×5（年）÷2}≒9.58MB/s

これは製品としてあり得ない数字で、もしこの速度に抑えたら故障と思われるだろう。したがって、厳密に文字通り5年間の寿命を保証することは元々できない。また、実際に大量のライトの最中でも50-80MiB/sの速度が出ていたので、これとも符号しない。ただ、逆に考えれば、これはファームウェア・アップデートの後のことなので、この部分が消えたのは時期的にファームウェア・アップデートと関係があるのかもしれない（あくまで想像）。

ともあれ、原理的な計算（これも基本的にIntelの情報を元にしたものだが）とIntelの公式情報には大きな差がある。

[追記]

7月11日に行われたIntelのイベント「Intel in Akiba 2009 Summer」での資料を見ると、X25-Mの耐用年数（書込寿命）として「5年 (35TB written, up to 20GB/day for 5 years)」という記述があり、現在のデータシートからの計算と大体一致する。

[参考]
AKIBA PC Hotline!: インテル天野氏がSSDとLynnfieldを語る、34nm版SSDもまもなく？

2. 寿命までの期間

SSDの寿命計算に関しては、SanDiskがその提唱する基準であるLDEのホワイトペーパーの中で考察を加えている。要は、「OSから見た書き換え量とSSD内部の書き換え量にはズレがあるけど、使用状況によっても変わるし、Write Amplificationとかも分かりにくいから、実際の使用状況を調べてアクセスパターンを作って実地にテストした方がよくない？」というもの（その割に、自社が使っているアクセスパターンを公開してないが）。

[参考]
PC Watch: MemCon 2008レポート SanDisk、SSDの寿命を定義する共通指標を提唱

Intelの公式情報がどれだけ実際のX25-Mの寿命を反映したものか分からないが、使用状況によってもズレがある分、データシートでは相当のマージンを見込んでいると考えるのが自然。ということを念頭におきつつ、X25-Mに公称スペックの上限である70MiB/s（＝73.4MB/s）の速度でライトを続けた場合にどれだけ保つかといえば、以下のようになる。

• 原理的な計算の場合: 755.5TB÷73.4（MB/s）≒119.1日 
• Intelの以前の資料からの場合: 182.5TB÷73.4（MB/s）≒28.8日 
• 現在のデータシートからの場合: 36.5TB÷73.4（MB/s）≒5.8日

これは、初めは短そうな印象があって、使ってみると全く気にする必要がないように思えて、しかし計算してみると意外に短いかもしれないSSDの寿命（特にMLC）といったところ。問題は、特に現在のデータシートからの場合にマージンがどれだけあるかだが、これはIntelの人しか分からないし、寿命は個々の使用状況にも左右されるとなればIntelの人でも確たることは分からないかもしれない。

そこで、S.M.A.R.T.で分からないかということになる。

3. E9が減るさま

24日時点でE9は50（初期値から-49）、E8は99（-1）、E1は193（-7）になった。

ここまでの流れは、大まかに以下のようになる。途中のスクリーンショット等はFlickrのX25-Mに載せた。

E9	ライト量 (TiB) (注1)	平均速度 (MiB/s) (注2)	所要時間 (注3)	方法	備考
98-96	-	-	6箇月	True Imageによるレストア他	日常使用。ただし、そんなに使っていない。
95	1.39	28.2	15時間	True Imageによるレストア	SSD全体のレストアを30回。1回にレストアされるのは、レストア後に0.046TiBの容量になる160千のファイルを含む4つのパーティション。
94	>1.60	65.0	-	HD Tune ProのErase 他	HD Tune ProのErase（0fill等による全消去）は22回で、1回につき0.073TiBのライト。パーティションはない状態（以下86まで同じ）。
93	3.64	66.3	18時間	HD Tune ProのErase	50回。
92	3.71	65.5	18時間	HD Tune ProのErase	51回。
91	-	-	-	-	Iometerの試用中だったので、記録なし。
90	1.10	16.8	19時間	Iometer （パターン1）	パターン1はOCZが作成したBootupをライトだけにしたもので、シーケンシャルライトとランダムライトが混在。計38百万IOs。平均速度が遅いのは初めは他のタスクも実行中だったため。終わりは89と同程度。
89	4.61	44.7	28時間	Iometer （パターン2、 パターン3） 他	パターン2はSanDiskのLDEのホワイトペーパーにある使用モデル（Figure 3a）を元に作成したもので、シーケンシャルライトとランダムライトが混在。パターン3はSanDiskのプレゼンテーション中のBapcoの使用モデルの比率から作成したもので、シーケンシャルとランダムの比率が分からなかったのでランダムライトのみ。計172百万IOs。
88	4.10	47.7	25時間	Iometer （パターン3）	計123百万IOs。
87	5.40	63.0	20時間	Iometer （パターン4）	パターン4は大きめのサイズの比率を増やしたもので、シーケンシャルライトとランダムライトが混在。計98百万IOs。
86	5.15	55.6	27時間	Iometer （パターン1）	計176百万IOs。
85-84	0.54	-	-	Iometer （パターン1） 他	気が付いたら減っていた。Iometerは70分、計12百万IOs。パーティション（1GB、NTFS、4KBクラスタサイズ）がある状態（以下50まで基本的に同じ）。
83-73	-	-	-	Iometer 他	気が付いたら減っていたので、記録なし。ただし、さほど大量のライトではない。
72	0.05	89.2	10分	Iometer （パターン7）	パターン7はシーケンシャルライト（サイズは64KB）のみにしたもの。
71	0.10	89.0	20分	Iometer （パターン1、 パターン7）	パターン7は同じもの。
70	0.05	90.6	10分	Iometer （パターン7）	同上。
69	0.06	98.4	10分	Iometer （パターン7）	同上。
68	0.03	98.6	6分	Iometer （パターン7）	同上。
67	0.09	98.0	16分	Iometer （パターン7）	同上。
66	0.04	97.8	8分	Iometer （パターン7）	同上。
65-64	0.09	97.9	16分	Iometer （パターン7）	同上。連続で減るか試したもの。
63-62	0.13	97.7	24分	Iometer （パターン7）	同上。
61	0.02	97.7	4分	Iometer （パターン7）	同上。
60	0.07	97.8	12分	Iometer （パターン7）	同上。
59	0.05	96.0	10分	Iometer （パターン7）	同上。
58	0.05	94.2	10分	Iometer （パターン7）	同上。
57	0.07	119.8	10分	Iometer （パターン7）	パターン7のサイズを128KBに変えたもの。
56	0.11	119.0	16分	Iometer （パターン7）	同上。
55	0.05	74.3	12分	Iometer （パターン7）	パターン7のサイズを32KBに変えたもの。
54	0.04	74.4	10分	Iometer （パターン7）	同上。
53	2.19	84.7	7時間	Iometer （パターン7、 パターン1）	パターン7のサイズを16KBに変えたら、時間がかかるようになった。パターン7は64KB、128KBのサイズも使用。
52	0.05	84.8	10分	Iometer （パターン7）	パターン7のサイズを64KBに戻したもの。
51	0.10	97.7	18分	Iometer （パターン7）	同上。
50	0.12	98.2	22分	Iometer （パターン7）	同上。
合計	>34.83

（注1）ライト量は、Iometerの場合は平均速度と所要時間から計算。

（注2）Iometerの速度に公称スペックを大きく超えるものがあるが、データシートによれば公称スペックもIometerによる測定なるも、queue depthが32で違うほか、使用したアクセスパターンが分からないので、そのまま比較はできない。

（注3）所要時間は、前の値になったのを見てからその値になったのを見るまでの時間。前後に端切れの時間があるので、値が変わる時間を正確に示したものではない。

以上のように95、94から86まで、72から50までの間で違いが大きすぎて、確たる法則性を見つけるのは難しい。しいて挙げれば、

• パーティションがある（ファイルシステムがある）状態の方が、ない状態よりも減りが速い。
• ランダムライトの方がシーケンシャルライトより減りが速いかと思いきや、シーケンシャルライトの方が速い。
• ライトのサイズは小さい方がライト量に対して減りが早いかと思いきや、サイズの大きい方が速い。
  
• IOsはあまり関係なさそう。
• 72から50までは、それ以前に比べてべらぼうに速い。これは偶然発見した方法だが、条件は以下のようなもの。
  
  • パーティション（1GB、NTFS、4KBクラスタサイズ）に対して、
  • Iometerからシーケンシャルライトとランダムライトが混在したパターン1でアクセスした後、
  • Iometerからシーケンシャルライトのみのパターン7でアクセスする。
  
  ただし、53の前で一旦遅くなったので、再現性は今一つ。
  
  
• 速度は落ちていない。

4. E8とE1の動き

同じくE8とE1の動きは、E9に対して以下のとおり。ただし、変わったタイミングはE9とはズレがある。

E9	E8	E1
99（注1）	100
97		200（注2）
95		199
94	99	198
93		197
92		196
84		195
83		194
53		193

（注1）E9の初期値は、明確な記録はないが他のX25-Mを見ても99だったと思う。

（注2）E1がS.M.A.R.T.に入ったのは新ファームウェア後。

E8は1回減っただけ。E1はそれなりに減っているが、この程度では法則性は分からない。

5. まとめ

以上をまとめると、

• E9の72以降のあまりにも短時間での減り方は、E9が例えば残り寿命のパーセント表示であるといった仮説を放擲させるのに十分。仮にこれが何らかのイレギュラーなものであれば、そもそもE9は指標として当てにならないことになる。
  
  
• （それでもE9がSSD内部の書き換え量に関する何らかの定量的な指標だとして）ライトの方法によってE9の減り方が違うのは、アクセスパターンによってSSD内部の書き換え量が違うことを裏付けている。
  
  
• 一方、小さなサイズのランダムライトより大きなサイズのシーケンシャルライトが多い方が減りが速いのは、SSD内部の書き換えに関する定説と合わない。
  
  
• E8とE1も使用歴と相関関係があるが、法則性が分かるほどではない。
  
  
• ライト量は明確な記録がある分だけで34.8TiB（＝37.4TB）になるので、現在のデータシートから計算できる寿命（36.5TB）を超えている。記録していない分も含めれば、とっくにマージンの世界に入っていることになる。
  
  
• 速度は全領域へのこれだけ大量のライトにかかわらず落ちていないので、別に意図したことではないが、新ファームウェアの効果は確認されたといえる。
  

以下は関連スレッド。

• Crystal Dew World 報告版: Intel SSDのS.M.A.R.T. ID [E8] [E9]についてIntelに問い合わせてみた
• AnandTech Forum: An unknown S.M.A.R.T. attribute of X25-M dropping

直接関係ないが、最近はIntelも開発者のBlogやCommunity（Intel側の反応は希だが）にFaceBookまで始めているので、オープンになってきていると思う。