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」と表現するのは大まか過ぎる感じがする。

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