>34.83(注1)ライト量は、Iometerの場合は平均速度と所要時間から計算。depthが32で違うほか、使用したアクセスパターンが分からないので、そのまま比較はできない。(注3)所要時間は、前の値になったのを見てからその値になったのを見るまでの時間。前後に端切れの時間があるので、値が変わる時間を正確に示したものではない。以上のように95、94から86まで、72から50までの間で違いが大きすぎて、確たる法則性を見つけるのは難しい。挙げれば、パーティションがある(ファイルシステムがある)状態の方が、ない状態よりも減りが速い。ランダムライトの方がシーケンシャルライトより減りが速いかと思いきや、シーケンシャルライトの方が速い。ライトのサイズは小さい方がライト量に対して減りが早いかと思いきや、サイズの大きい方が速い。IOsはあまり関係なさそう。72から50までは、それ以前に比べてべらぼうに速い。これは偶然発見した方法だが、条件は以下のようなもの。パーティション(1GB、NTFS、4KBクラスタサイズ)に対して、Iometerからシーケンシャルライトとランダムライトが混在したパターン1でアクセスした後、Iometerからシーケンシャルライトのみのパターン7でアクセスする。53の前で一旦遅くなったので、再現性は今一つ。E8とE1の動き同じくE8とE1の動きは、E9に対して以下のとおり。変わったタイミングはE9とはズレがある。1989319792196841958319453193(注1)E9の初期値は、明確な記録はないが他のX25-Mを見ても99だったと思う。(注2)E1がS.M.A.R.T.に入ったのは新ファームウェア後。E8は1回減っただけ。E1はそれなりに減っているが、この程度では法則性は分からない。まとめ以上をまとめると、E9の72以降のあまりにも短時間での減り方は、E9が例えば残り寿命のパーセント表示であるといった仮説を放擲させるのに十分。仮にこれが何らかのイレギュラーなものであれば、そもそもE9は指標として当てにならないことになる。(それでもE9がSSD内部の書き換え量に関する何らかの定量的な指標だとして)ライトの方法によってE9の減り方が違うのは、アクセスパターンによってSSD内部の書き換え量が違うことを裏付けている。小さなサイズのランダムライトより大きなサイズのシーケンシャルライトが多い方が減りが速いのは、SSD内部の書き換えに関する定説と合わない。E8とE1も使用歴と相関関係があるが、法則性が分かるほどではない。ライト量は明確な記録がある分だけで34.8TiB(=37.4TB)になるので、現在のデータシートから計算できる寿命(36.5TB)を超えている。記録していない分も含めれば、とっくにマージンの世界に入っていることになる。速度は全領域へのこれだけ大量のライトにかかわらず落ちていないので、別に意図したことではないが、新ファームウェアの効果は確認されたといえる。dropping直接関係ないが、最近はIntelも開発者のBlogやCommunity(Intel側の反応は希だが)にFaceBookまで始めているので、オープンになってきていると思う。ストレージ2009/06/21X25-Mのシーケンシャルライトの谷ファームウェアをアップデートしたX25-Mは、ベンチマーク上は少し難しいところがあって、シーケンシャルライトが連続すると、ある間隔で大きな落ち込みが入るようになる。これを仮にシーケンシャルライトの「谷」と呼ぶことにする。この原因自体は、そもそもX25-MのアルゴリズムについてIntelの説明がない以上、分かりようがないので措くとして、この谷が現象としてどういうものかを確認してみる。(Write)はその典型である。Proではファームウェアをアップデートした時点できれいに谷が出ているが、やり方を変えつつ谷の性質を見てみる。X61s本体に内蔵し、パーティションはない状態。精度はAccurate側一杯に設定している。シーケンシャルライトと谷の関係について、以下は前段階としてX25-MをIometerからシーケンシャルライトとランダムライトが混在したパターン(パターン1。Proを64KBのブロックサイズ(デフォルト)で、50%までの領域で谷が少なくなって安定するまで繰り返した後に100%まで行った状態(左)と、100%で谷が安定するまで繰り返した状態(右)。左のグラフの50%までがシーケンシャルライトの繰り返しで谷が少なくなって安定した状態、50%以降が元の谷が激しく出ている状態。右のグラフは全体的に安定した状態を示している。全体としては以下のとおり。これから次のことが分かる。ランダムライトが混在したアクセスを大量に行うと、その後に谷が激しく出る。シーケンシャルライトを繰り返すと、谷は狭く、少なくなっていき、ごく短時間だけ出るようになって安定する(1回の試行時間は約7分なので、安定した状態では約1分に1回の頻度)。シーケンシャルライトを行った領域だけ、谷は少なくなる。アイドル時に自動的に少なくなったりはしない(時間をある程度おいた状態でも変わらないので)。Proを64KB、256KB、1MBとサイズを変えつつ繰り返したもの。64KBの最初では谷が激しく出ているが、これが一旦安定した後は、256KBの最初で谷が少し広がるがすぐに安定し、1MBでは初めから安定している。試行によって谷の出るタイミングに脈絡がないように見えるが、前後の試行をつなげると谷の間隔は微妙に揃っている。これから次のことが分かる。シーケンシャルライトによって谷が一旦安定すれば、ライトのサイズを変えても基本的に安定した状態は変わらない。谷の出る位置、間隔は、単純に特定の場所、時間で決まっているわけではない(試行と試行の間の時間は不定なので)。前段階をシーケンシャルライトだけにした場合について、Iometerからシーケンシャルライト(サイズは1MB)だけのパターン(パターン5)で1時間アクセスした後では、以下のようになる。最初から谷はほぼ安定した状態になっている。これから次のことが分かる。谷が激しく出るのは、ランダムライトを行った後だけ。シーケンシャルライトのサイズが小さい方が、谷の数は多くなる傾向がある。Proの何らかの癖によるものである可能性と、ファイルシステムがある状態ではどうなるかという点を確認するため、Iometerでも見てみる。Sizeは256MBに設定)。タコメーター表示は速度(MB/s)で、1秒ごとに更新。大体1分おきに(0:48、2:39、3:56、4:47)谷が入っていることが分かる。谷は1秒以内に起きている。最終状態は以下のとおり(タコメーターの青い円弧が動いた範囲を示している)。谷が直接見えない場合ベンチマークでもテストサイズを順に切り替えて速度を計測していくものでは、谷は直接は見えないが、無関係でもない。Benchmarkの場合を見てみる。lengthは256MBに設定)。1回の試行時間は約1分だが、その間にサイズに関係ない不自然な落ち込みが2回ある。全体としては以下のとおり。Lengthはデフォルトの256MB)。1回の試行時間は約3分だが、その間に不自然な落ち込みが3、4回ある。全体としては以下のとおり。以上からの推測として、これらの落ち込みはサイズに関係なく常にある間隔で起きること、落ち幅が妙に大きいことから、あるサイズの計測中にシーケンシャルライトの谷とかち合ってしまった結果、そのサイズの速度が落ちたと考えれば合点がいく。Proの方が大きな影響を受けても不思議ではない。Benchmarkの結果がある。この1回目の試行では落ち込みが出ているが、2回目の試行では出ていない。Benchmarkを行ってみたが、やはり落ち込みは出ていた。RWの結果があるが、1回目の試行では谷が一部の領域に出ているが、2回目の試行では出ていない。RW自体は入手してないが、そのReadmeには以下の説明がある。Testでは、全セクタをなめるように128MBのサイズ(80GBのX25-Mなので)のシーケンシャルライトを行って計測するようである。(Write)では、全領域の計測にかかるのは約7分で、平均速度は約60MB/sなので(谷が安定した状態では)、その間にアクセスする領域は多くて約24GBと、全体の1/3程度に留まる。シーケンシャルライトのサイズは最大でも8MBである。Proを8MBのサイズで繰り返したのが以下。繰り返すにつれ谷は安定していくが、けっして消えはしない。Proを64KB、8MB、4MB、2MBとサイズを変えつつ繰り返すと以下のようになる。64KBでは最初は谷は出なかったが、繰り返すにつれパターン1の後のように谷が出るようになった。8MBでは谷は出ていない。4MBでは最初は出なかったが、次第に少し出るようになった。2MBでは4MBより谷の数が増えた。Proを8MBのサイズだけで繰り返したのが以下。谷は全くないわけではないが、ほとんど出ていない。ProのErase(これもシーケンシャルライトのはず)を1回行った後、8MB、64KBとサイズを変えつつ繰り返したのが以下。8MBでは谷はほとんど出ていない。64KBでは普通に出ている。Proを8MBのサイズで繰り返したのが以下。前半は谷が激しく出て当然として、後半は谷が出なくなるかと思いきや、結構出ている。繰り返しても全領域をパターン1でアクセスした後と変わらないぐらいである。以上から谷が出ない条件は次のように考えてよいと思う。先行して全領域がシーケンシャルライトで埋められている。8MB以上のサイズのシーケンシャルライトで計測する。RWの2回目の試行はこの条件に当てはまる。副次的に次のことが示唆されていると思う(こちらの方もかなり興味深い)。シーケンシャルライトでも4MB以下のサイズでは谷が出る原因になる。一部の領域を限定してシーケンシャルライトで埋めようとしても、他の領域の影響を受ける。(Write)では以下のようになる。Proを繰り返したもの。64KB以下では最初は影響があるが、すぐに元に戻る。1MBでは最初は約500msと長いアクセスタイムがかかるときがかなりあるが、すぐに短くなる。安定した状態でもたまに約100msのアクセスタイムがかかるときがあるのは谷と関係があるのかもしれない。まとめ簡単にまとめると、ある領域で先行してランダムライトが行われていると、シーケンシャルライトの谷が出る。シーケンシャルライトを繰り返すと谷は少なくなって安定する。全領域をシーケンシャルライトで埋めた後、大きなサイズのシーケンシャルライトを行う場合は、谷は出ない。シーケンシャルライトが入るベンチマークは、谷が出ている可能性、その時点の谷の状態を考慮しないとズレた評価になる危険性がある(谷自体の善し悪しは別として)。Analysis)のh2benchwのシーケンシャルライトの結果はよく理解できる。efficiently」と表現するのは大まか過ぎる感じがする。実用上の影響については、先行してランダムライトが混在しているのが普通なので、谷が出る可能性は常にある。一方で、谷が出るのはシーケンシャルライトがかなり連続する場合で、そのような場合は途中で谷が出てもまず問題にならないこと(平均速度が高ければよい)、それを繰り返すような状況では谷は頻度が低く、ごく短時間になっていくことから、ほとんど影響はないと思う。Communitywww.flickr.comコメントについてコメントは承認制です。承認まで時間がかかるときがあります。感想、間違いの指摘など歓迎します。間違いについては、その場所と内容を明記してください。エントリと関係がないもの、不適当と思われるものは承認しません。プロフィールEMOGitHub詳しくないプロフィール当てにならないカスタマイズ。