単位系の件

コンピュータ関係の計算をしていると避けて通れないのが単位系の問題。すなわち、SI接頭辞（1K＝1000）か、2進接頭辞（1K＝1024＝2^10）かの問題だが、TBあるいはTiBともなるとズレが馬鹿にならない。一般的に容量はSI接頭辞、速度は2進接頭辞のことが多いが、必ずしも当てはまらないので、調べた結果を書き留めておく。

SI接頭辞（1KB＝1000Bytes）

• CrystalDiskMark（Readmeに表記）
  
  
• HD Tune Proの容量（マニュアルに表記。4.00ではmB、gBなど小文字を使って示す形式をとる）
  
  
• HD Tach（Resultsのウィンドウに表記）
  
  
• X25-Mの容量（データシートの「Table 2. User Addressable Sectors」のNoteに表記。いずれにせよセクタ数から計算できるが）
  

2進接頭辞（1KB/1KiB＝1024Bytes）

• HD Tune Proの速度（マニュアルに表記）
  
  
• PCMark05のHDD Test Suite（問い合わせに対する回答。IntelのRankDiskを利用）
  
  
• Iometerの速度（User's Guideの「13.5 Selecting a Statistic for Display」中の「Megabytes per Second submenu:」に表記。ちなみに関係ないが、Iometerの表記は、Iometerの中では「Iometer」だが、他の資料では往々にして「IOmeter」になっている。意味的には大文字の方がしっくり来るが）
  
  
• X25-Mの公称速度（データシートの「Table 3. Maximum Sustained Read and Write Bandwidth」のNoteに表記）
  

不明

• SiSoftware Sandraの速度（容量等は2進接頭辞で統一されているので、おそらくは2進接頭辞）
  

• h2benchw（ドキュメンテーションはドイツ語らしい）
  
  
• ATTO Disk Benchmark（もはやヘルプを含めてドキュメンテーションにアクセスできない）

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まで始めているので、オープンになってきていると思う。

X25-Mのシーケンシャルライトの谷

ファームウェアをアップデートしたX25-Mは、ベンチマーク上は少し難しいところがあって、シーケンシャルライトが連続すると、ある間隔で大きな落ち込みが入るようになる。これを仮にシーケンシャルライトの「谷」と呼ぶことにする。

この原因自体は、そもそもX25-MのアルゴリズムについてIntelの説明がない以上、分かりようがないので措くとして、この谷が現象としてどういうものかを確認してみる。

1. 谷の基本的性質

この谷が顕著に見えるのは、領域を移動しつつシーケンシャルライトの速度を追うベンチマークで、HD Tune ProのBenchmark (Write)はその典型である。HD Tune Proではファームウェアをアップデートした時点できれいに谷が出ているが、やり方を変えつつ谷の性質を見てみる。なお、X25-MはThinkPad X61s本体に内蔵し、パーティションはない状態。また、精度はAccurate側一杯に設定している。

まずシーケンシャルライトと谷の関係について、以下は前段階としてX25-MをIometerからシーケンシャルライトとランダムライトが混在したパターン（パターン1。OCZが作成したBootupをライトだけにしたもの）で19時間アクセスした後、HD Tune Proを64KBのブロックサイズ（デフォルト）で、50%までの領域で谷が少なくなって安定するまで繰り返した後に100%まで行った状態（左）と、100%で谷が安定するまで繰り返した状態（右）。

左のグラフの50%までがシーケンシャルライトの繰り返しで谷が少なくなって安定した状態、50%以降が元の谷が激しく出ている状態。右のグラフは全体的に安定した状態を示している。全体としては以下のとおり。

これから次のことが分かる。

• ランダムライトが混在したアクセスを大量に行うと、その後に谷が激しく出る。
  
• シーケンシャルライトを繰り返すと、谷は狭く、少なくなっていき、ごく短時間だけ出るようになって安定する（1回の試行時間は約7分なので、安定した状態では約1分に1回の頻度）。
• シーケンシャルライトを行った領域だけ、谷は少なくなる。アイドル時に自動的に少なくなったりはしない（時間をある程度おいた状態でも変わらないので）。

次にシーケンシャルライトのサイズを変えた場合について、以下はIometerからパターン1で1時間アクセスした後、HD Tune Proを64KB、256KB、1MBとサイズを変えつつ繰り返したもの。

64KBの最初では谷が激しく出ているが、これが一旦安定した後は、256KBの最初で谷が少し広がるがすぐに安定し、1MBでは初めから安定している。また、試行によって谷の出るタイミングに脈絡がないように見えるが、前後の試行をつなげると谷の間隔は微妙に揃っている。これから次のことが分かる。

• シーケンシャルライトによって谷が一旦安定すれば、ライトのサイズを変えても基本的に安定した状態は変わらない。
• 谷の出る位置、間隔は、単純に特定の場所、時間で決まっているわけではない（試行と試行の間の時間は不定なので）。
  

さらに前段階をシーケンシャルライトだけにした場合について、Iometerからシーケンシャルライト（サイズは1MB）だけのパターン（パターン5）で1時間アクセスした後では、以下のようになる。

最初から谷はほぼ安定した状態になっている。これから次のことが分かる。

• 谷が激しく出るのは、ランダムライトを行った後だけ。
• シーケンシャルライトのサイズが小さい方が、谷の数は多くなる傾向がある。
  

2. 別の方向から

この谷がHD Tune Proの何らかの癖によるものである可能性と、ファイルシステムがある状態ではどうなるかという点を確認するため、Iometerでも見てみる。

X25-M上のパーティション（1GB、NTFS、4KBクラスタサイズ）に対し、前段階としてランダムライトが混在したパターン1で10分アクセスした後、シーケンシャルライト（サイズは64KB）のパターン（パターン7）で6分アクセスした状態を撮影した（Maximum Disk Sizeは256MBに設定）。タコメーター表示は速度（MB/s）で、1秒ごとに更新。

大体1分おきに（0:48、2:39、3:56、4:47）谷が入っていることが分かる。また、谷は1秒以内に起きている。最終状態は以下のとおり（タコメーターの青い円弧が動いた範囲を示している）。

3. 谷が直接見えない場合

ベンチマークでもテストサイズを順に切り替えて速度を計測していくものでは、谷は直接は見えないが、無関係でもない。そのようなベンチマークとしてHD Tune ProのFile Benchmarkと、ATTO Disk Benchmarkの場合を見てみる。

以下は2つのパーティション（1GB、NTFS、4KBクラスタサイズ）に対し、前段階としてIometerからパターン1で10分アクセスした後、それぞれにHD Tune ProのFile Benchmarkを繰り返した中からの例（File lengthは256MBに設定）。

1回の試行時間は約1分だが、その間にサイズに関係ない不自然な落ち込みが2回ある。全体としては以下のとおり。

同様にATTO Disk Benchmarkを繰り返した中からの例（Total Lengthはデフォルトの256MB）。

1回の試行時間は約3分だが、その間に不自然な落ち込みが3、4回ある。全体としては以下のとおり。

以上からの推測として、

• これらの落ち込みはサイズに関係なく常にある間隔で起きること、落ち幅が妙に大きいことから、あるサイズの計測中にシーケンシャルライトの谷とかち合ってしまった結果、そのサイズの速度が落ちたと考えれば合点がいく。
• HD Tune Proの方が落ち幅が大きいが、サイズごとの計測時間がHD Tune Proでは約2秒、ATTO Disk Benchmarkでは約5秒なので、もしこの間の平均を出すアルゴリズムになっていれば、HD Tune Proの方が大きな影響を受けても不思議ではない。
  

なお、PC Perspectiveの記事（Intel Responds to Fragmentation with New X25-M Firmware）にはATTO Disk Benchmarkの結果がある。この1回目の試行では落ち込みが出ているが、2回目の試行では出ていない。この理由は分からないが、次の4.でHD Tune ProのBenchmark (Write)では谷が出ない状態になった後でATTO Disk Benchmarkを行ってみたが、やはり落ち込みは出ていた。

4. 谷が出ない場合

先のPC Perspectiveの記事にはHD Tach RWの結果があるが、1回目の試行では谷が一部の領域に出ているが、2回目の試行では出ていない。これは何故か。HD Tach RW自体は入手してないが、そのReadmeには以下の説明がある。

The full bench will benchmark every sector of the hard drive instead of picking small zones on the drive like quick or full. A full bench could take one to two hours on a 120 gigabyte hard drive. Full bench uses varying zone sizes for different device sizes to minimize the number of zones benchmarked. Under 1GB, 8MB zones are used. Under 40GB 64MB zones are used, under 100GB 128MB zones are used and for all other disk sizes 512MB zones are used.

つまり、HD Tach RWのFull benchのWrite Testでは、全セクタをなめるように128MBのサイズ（80GBのX25-Mなので）のシーケンシャルライトを行って計測するようである。

これに対してHD Tune ProのBenchmark (Write)では、全領域の計測にかかるのは約7分で、平均速度は約60MB/sなので（谷が安定した状態では）、その間にアクセスする領域は多くて約24GBと、全体の1/3程度に留まる。また、シーケンシャルライトのサイズは最大でも8MBである。

ここでHD Tach RWに近づけた条件ではどうなるかについて、試しに、Iometerからパターン1で1時間アクセスした後、HD Tune Proを8MBのサイズで繰り返したのが以下。

繰り返すにつれ谷は安定していくが、けっして消えはしない。

次に、Iometerからシーケンシャルライト（サイズは8MB）だけのパターン（パターン6）で1時間アクセスした後（平均速度を60MB/sとすると計210GBのライトとなり、全領域を2回は埋め尽くす計算）、HD Tune Proを64KB、8MB、4MB、2MBとサイズを変えつつ繰り返すと以下のようになる。

64KBでは最初は谷は出なかったが、繰り返すにつれパターン1の後のように谷が出るようになった。8MBでは谷は出ていない。4MBでは最初は出なかったが、次第に少し出るようになった。2MBでは4MBより谷の数が増えた。

確認のため、Iometerから同様にアクセスした後、HD Tune Proを8MBのサイズだけで繰り返したのが以下。

谷は全くないわけではないが、ほとんど出ていない。

さらに確認のため、前段階を変えてHD Tune ProのErase（これもシーケンシャルライトのはず）を1回行った後、8MB、64KBとサイズを変えつつ繰り返したのが以下。

8MBでは谷はほとんど出ていない。一方、64KBでは普通に出ている。

さらにやり方を変えて、全領域を前半と後半の2つのパーティションに分け、Iometerから前半をランダムライトが混在したパターン1で、後半をシーケンシャルライトだけのパターン6でそれぞれ30分アクセスした後、パーティションを削除してHD Tune Proを8MBのサイズで繰り返したのが以下。

前半は谷が激しく出て当然として、後半は谷が出なくなるかと思いきや、結構出ている。繰り返しても全領域をパターン1でアクセスした後と変わらないぐらいである。

以上から谷が出ない条件は次のように考えてよいと思う。

• 先行して全領域がシーケンシャルライトで埋められている。
• 8MB以上のサイズのシーケンシャルライトで計測する。

HD Tach RWの2回目の試行はこの条件に当てはまる。また、副次的に次のことが示唆されていると思う（こちらの方もかなり興味深い）。

• シーケンシャルライトでも4MB以下のサイズでは谷が出る原因になる。
• 一部の領域を限定してシーケンシャルライトで埋めようとしても、他の領域の影響を受ける。

5. ランダムライトについて

一応ランダムライトへの影響については、HD Tune ProのRandom Access (Write)では以下のようになる。これはIometerからパターン1で27時間アクセスした後、HD Tune Proを繰り返したもの。

64KB以下では最初は影響があるが、すぐに元に戻る。1MBでは最初は約500msと長いアクセスタイムがかかるときがかなりあるが、すぐに短くなる。安定した状態でもたまに約100msのアクセスタイムがかかるときがあるのは谷と関係があるのかもしれない。

6. まとめ

簡単にまとめると、

• ある領域で先行してランダムライトが行われていると、シーケンシャルライトの谷が出る。シーケンシャルライトを繰り返すと谷は少なくなって安定する。
• 全領域をシーケンシャルライトで埋めた後、大きなサイズのシーケンシャルライトを行う場合は、谷は出ない。
• シーケンシャルライトが入るベンチマークは、谷が出ている可能性、その時点の谷の状態を考慮しないとズレた評価になる危険性がある（谷自体の善し悪しは別として）。
  

そう考えると、例えばTom's Hardwareの記事（The SSD Workload Performance Analysis）のh2benchwのシーケンシャルライトの結果はよく理解できる。ただ、これをもって「the firmware adjusts to the workload much more efficiently」と表現するのは大まか過ぎる感じがする。

実用上の影響については、先行してランダムライトが混在しているのが普通なので、谷が出る可能性は常にある。一方で、谷が出るのはシーケンシャルライトがかなり連続する場合で、そのような場合は途中で谷が出てもまず問題にならないこと（平均速度が高ければよい）、それを繰り返すような状況では谷は頻度が低く、ごく短時間になっていくことから、ほとんど影響はないと思う。