2009/06/24

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)」という記述があり、現在のデータシートからの計算と大体一致する。


2. 寿命までの期間


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


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)になった。
CrystalDiskInfo 3.0 -Moonlight- Dev#10

ここまでの流れは、大まかに以下のようになる。途中のスクリーンショット等はFlickrのX25-Mに載せた。
E9ライト量
(TiB)
(注1)
平均速度
(MiB/s)
(注2)
所要時間
(注3)
方法備考
98-96--6箇月True Imageによるレストア他日常使用。ただし、そんなに使っていない。
951.3928.215時間True ImageによるレストアSSD全体のレストアを30回。1回にレストアされるのは、レストア後に0.046TiBの容量になる160千のファイルを含む4つのパーティション。
94>1.6065.0-HD Tune ProのErase
HD Tune ProのErase(0fill等による全消去)は22回で、1回につき0.073TiBのライト。パーティションはない状態(以下86まで同じ)。
933.6466.318時間HD Tune ProのErase50回。
923.7165.518時間HD Tune ProのErase51回。
91----Iometerの試用中だったので、記録なし。
901.1016.819時間Iometer
(パターン1)
パターン1はOCZが作成したBootupをライトだけにしたもので、シーケンシャルライトとランダムライトが混在。計38百万IOs。平均速度が遅いのは初めは他のタスクも実行中だったため。終わりは89と同程度。
894.6144.728時間Iometer
(パターン2、
パターン3)
パターン2はSanDiskのLDEのホワイトペーパーにある使用モデル(Figure 3a)を元に作成したもので、シーケンシャルライトとランダムライトが混在。パターン3SanDiskのプレゼンテーション中のBapcoの使用モデルの比率から作成したもので、シーケンシャルとランダムの比率が分からなかったのでランダムライトのみ。計172百万IOs。
884.1047.725時間Iometer
(パターン3)
計123百万IOs。
875.4063.020時間Iometer
(パターン4)
パターン4は大きめのサイズの比率を増やしたもので、シーケンシャルライトとランダムライトが混在。計98百万IOs。
865.1555.627時間Iometer
(パターン1)
計176百万IOs。
85-840.54--Iometer
(パターン1)
気が付いたら減っていた。Iometerは70分、計12百万IOs。パーティション(1GB、NTFS、4KBクラスタサイズ)がある状態(以下50まで基本的に同じ)。
83-73---Iometer
気が付いたら減っていたので、記録なし。ただし、さほど大量のライトではない。
720.0589.210分Iometer
(パターン7)
パターン7はシーケンシャルライト(サイズは64KB)のみにしたもの。
710.1089.020分Iometer
(パターン1、
パターン7)
パターン7は同じもの。
700.0590.610分Iometer
(パターン7)
同上。
690.0698.410分Iometer
(パターン7)
同上。
680.0398.66分Iometer
(パターン7)
同上。
670.0998.016分Iometer
(パターン7)
同上。
660.0497.88分Iometer
(パターン7)
同上。
65-640.0997.916分Iometer
(パターン7)
同上。連続で減るか試したもの。
63-620.1397.724分Iometer
(パターン7)
同上。
610.0297.74分Iometer
(パターン7)
同上。
600.0797.812分Iometer
(パターン7)
同上。
590.0596.010分Iometer
(パターン7)
同上。
580.0594.210分Iometer
(パターン7)
同上。
570.07119.810分Iometer
(パターン7)
パターン7のサイズを128KBに変えたもの。
560.11119.016分Iometer
(パターン7)
同上。
550.0574.312分Iometer
(パターン7)
パターン7のサイズを32KBに変えたもの。
540.0474.410分Iometer
(パターン7)
同上。
532.1984.77時間Iometer
(パターン7、
パターン1)
パターン7のサイズを16KBに変えたら、時間がかかるようになった。パターン7は64KB、128KBのサイズも使用。
520.0584.810分Iometer
(パターン7)
パターン7のサイズを64KBに戻したもの。
510.1097.718分Iometer
(パターン7)
同上。
500.1298.222分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とはズレがある。
E9E8E1
99(注1)100
97
200(注2)
95
199
9499198
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)を超えている。記録していない分も含めれば、とっくにマージンの世界に入っていることになる。

  • 速度は全領域へのこれだけ大量のライトにかかわらず落ちていないので、別に意図したことではないが、新ファームウェアの効果は確認されたといえる。
以下は関連スレッド。
直接関係ないが、最近はIntelも開発者のBlogCommunity(Intel側の反応は希だが)にFaceBookまで始めているので、オープンになってきていると思う。

2 コメント :

匿名 さんのコメント...

Intelのサイトにて、SMARTのデータシートが公開されたようです

Intel High Performance SSD S.M.A.R.T. features user’s guide (PDF 237.42 KB)
http://www.intel.com/cd/channel/reseller/asmo-na/eng/products/nand/tech/tech_ref/smart/424742.htm

http://www.intel.com/cd/channel/reseller/asmo-na/eng/products/nand/feature/index.htm

EMO さんのコメント...

承認が大変遅れてすいません。コメントがあった際の通知設定を間違えてました。

このIntelのSMARTのデータシート、残念ながらIntelのリセラー向けのIDがないと見れないので、何とも仕方がないです。残念ながら。