Lansenの現実逃避日記

cuttingedge 2009/02/12 11:47 情報ありがとうございます。Defraggler試してみます。

たぬきち 2009/02/12 18:27 　はじめまして。１年ほど前からSSD（最初はCFカード３枚をCenturyのSDB25CFで変換して、半年前からはMSD3000の32GB IDE版）を使っています。最近こちらのブログに辿り着きまして、JSMonitorやSSDの速度評価など興味深い内容であちらこちら読ませて頂いています。
　ところでSSDフォーマット時のクラスタサイズは標準の4KBで測定されているでしょうか？　JMF602の書き込みが32KB単位ならクラスタサイズを32KBにしてしまえばデフラグ不要になるのでは？・・・と思ったもので。（どこかで4KB最適化という話も見かけましたが）

knc 2009/02/13 09:05 はじめまして

PC Wacthの12日のSamsung SSDのレビュー記事において、比較用のIntel SSDで大幅な
速度低下があった旨が書かれてますが、これも断片化が原因でしょうかね。

pc.watch.impress.co.jp/docs/2009/0212/hirasawa014.htm

いずれにせよ勉強になりました。

Lansen 2009/02/14 01:39 >たぬきちさん
そのアイディアは全然気が付きませんでした。確かに効果あるかも？
ただ、SSDはデータ消去をブロックサイズで行う必要があるため、完全に断片化の影響がなくなるわけではないと思います。

>kncさん
断片化に伴うSSDの書き込み性能の低下は、ランダムライトの遅さに起因しています。
IntelのSSDは非常にランダムライトが速いので、断片化の影響は少ないと思います。
また、HDTuneの書き込みテストはドライブを消去しないと行えないので、やはり断片化は関係なさそうですね。
http://enthusiast.hardocp.com/article.html?art=MTYxMSwyLCxoZW50aHVzaWFzdA==
こちらの記事によると、最も重大なSSDの性能低下の原因はフラッシュ上のデータの断片化であり、外部からその状況を取得することはできない、とあります。
OSのデフラグで解消できるのはファイルシステム上の断片化ですが、OSからではコントローラがアドレスを変換した後のデータの断片化には対処できないということのようですね。
どのようなメカニズムでフラッシュ上のデータが断片化を起こすのかはちょっと分からないです…
なお、こちらの記事では、0fillで性能が元に戻ったとのことです。
http://salt2.air-nifty.com/

774 2009/02/14 01:56 Windowsやデフラグソフトからは物理的にどう配置されているか分からないのではないでしょうか？

HDDの場合はその構造上セクタが連続していますが、SSDではATAとの互換性を持たせるために
SSD側のコントローラが仮想的に示しているに過ぎないのではと思うんですが…

特にウェアレベリングによってデータが特定のセルになるべく集中しないように配置するために
たとえば同一データの上書きだけでも物理的な配置が変わることも考えられます

断片化、という概念がそもそも当てはまらないのではと思いました

たぬきち 2009/02/14 10:39 　フラッシュの消去のことはすっかり失念しておりました。ところで申し遅れましたが、Defraglerを早速downloadして試してみました。

　　MSD-PATA3025-032(公称read100MB/s,write100MB/s)のCrystalDiskMark2.1(テスト容量はお手軽50MB)
　　　　　　write
　　　seq 53→72
　　　512k 42→47
　　　4k 2→3.5

　寿命対策と容量が32GBと少ないので、SSDにはOSのみ。アプリ、データ、ページファイルはHDDに置いていて、あまり速度低下はしていないと思っていたのですが・・・実使用環境でも速度アップしました。

　物理配置までは手が届かない、（一般的なデフラグは寿命に）悪影響しかないということで試そうとも思ってなかったのですが、論理レベルのデフラグでも書き込みが細切れにならず充分に効果が得られるんですね。有益な情報、ありがとうございます。

ひよひよ 2009/02/14 10:50 私も 774 さんと同じ疑問を持っていますが、検証結果を見る限りデフラグの効果はありますねぇ。

私は以前 LBA0 から順番にシーケンシャル読み出しを行うベンチ
マーク機能を実装したことがあるのですが、SSD では、空っぽの
状態と Windows インストール済みの状態でベンチマーク結果が
異なることに気が付き CrystalDiskInfo への実装を断念したこと
があります。

ソフトウェアからは LBA でセクタ指定できますが、そのセクタが
どのメモリセルに含まれているかはわかりませんし、ウェアレベ
リングによって記録されているメモリセルもどんどん変わるので
しょう。

0fill で性能が回復するのは LBA とメモリセルの対応関係が
最速となるように再調整されるからかもしれませんね。
適当な憶測です(汗

SSD は大変興味深いですねぇ〜。そろそろ買うかな……

> たぬきちさん
大変お手数ですが、CrystalDiskMark 2.2 への移行を……バグバグでご迷惑おかけします。

Lansen 2009/02/14 15:36 おお、ひよひよさんではありませんか。CrystalDiskInfo/Mark双方ともに愛用させていただいてます。

>774さん、ひよひよさん
実際には、この断片化の原理は簡単な話です。
OSのファイルシステム上でのデータのアドレスを"論理アドレス"、実際のSSD上でのデータのアドレスを"物理アドレス"と呼ぶことにします。
SSDコントローラの役割のひとつは、この論理アドレスと物理アドレスの変換です。
OSは、論理アドレス上の位置を指定して読み込み・書き込み命令をSSDに送るわけですが、コントローラはその論理アドレスを物理アドレスに変換して実際の読み書きをおこないます。
手紙に送り先の名前を書いておくだけで正しい住所に届けてくれる超親切な郵便局のようなものです。
送り主(=OS)は"佐藤さん宛て"(=論理アドレス上の位置)とだけ書いた手紙(=データ)を投函すると、郵便局(=コントローラ)が佐藤さんの家が"3丁目2番地"(=物理アドレス上の位置)にあることを調べ、正しく手紙を届けることができる、という感じです。
佐藤さんの家が老朽化してしまって、いつの間にか2丁目5番地に引越ししていた(=スタティックウェアレベリング)場合でも、郵便局側はそのことを知っているので、送り主は前と変わらず"佐藤さん宛て"と書いた封筒を送ればよいということです。
(この例で言うと老朽化した家からの立ち退きを迫るのも郵便局の仕事になってしまいますが…)
ここで空き領域の断片化が発生したときのことを考えて見ます。OSが8KBのファイルを書き込もうとしたとき、論理アドレス上の空き領域が断片化していて、4KBx2に分割されて書き込まれたとします。これは、SSDから見れば、4KBの書き込み要求が2回あったのと同じことになります。すなわち、OSが4KBのファイルを2個書き込んだのと全く同じことになってしまいます。SSDはファイルシステムを理解していないので、同じファイルだからまとめて書き込むといった動作はできません。
前の例で言うと、佐藤さんに2通手紙を送ればいいはずのところが、佐藤さんと田中さんに1通ずつ手紙を送らなければいけない状況になってしまうということです。別々の家を訪問するわけですから、時間は2倍かかってしまいます。

>たぬきちさん
前述したように、断片化の解消は特にランダムライトの遅いSSDに効果があります。
特にMTRONはランダムライト速度が遅いので（2.2にバージョンアップ後テストサイズを1000MBとかにしてみてください）、効果が分かりやすいと思います。

ひよひよ 2009/02/14 18:08 > Lansen さん
ご丁寧な解説ありがとうございます。
なぜデフラグが有効かよ〜くわかりました。解説していただくと、本当に当たり前の話ですね。なんで気がつかなかったのかと……
SSD = デフラグ不要 が固定観念としてしみついていたようです。

774 2009/02/14 19:08 ＞Lansenさん
詳しい説明をして頂き恐縮です。

つまり論理的な空き領域の断片化は、そこへ書き込む際に
SSDコントローラの論理⇔物理アドレス変換の際にオーバーヘッドとなり
結果として書き込み性能（特にランダムライト）の悪化を招くという解釈でよろしいでしょうか。

しかしそうなると、既に書き込まれたデータ領域が論理的に断片化していて
そこを読み書きする場合でも同様のペナルティが発生するようにも思われますが
原理的に空き領域へテスト用領域を確保するベンチマークでは測定が難しい…？


＞ひよひよさん

Crystalシリーズにはいつも大変お世話になっています。この場を借りてお礼を。

Lansen 2009/02/14 22:23 もちろん、読み込み速度も断片化の影響を受けます。完全に断片化した状態のCrystalDiskMarkの結果を見ると、若干読み込み速度も遅くなっているのが分かります。
ですが、本文中にもありますが、SSDはランダムリードは非常に早く、ランダムライトは非常に遅いという特徴があります。そのため、読み込みは断片化の影響を受けにくくなります。
また、すでに書き込み済みのファイルの同じところに繰り返しデータを書くという使い方はまれで、おそらくページファイルぐらいなのではないでしょうか。
それを考えると、寿命を削ってまで書き込み済みのファイルをデフラグする必要性があるかどうかは微妙です。
なお、同様の理由で、IntelのSSDのように非常にランダムライトが速い製品は、空き領域が断片化してもあまり書き込み速度は下がらないはずです。この場合、空き領域のデフラグはあまり意味が無いでしょう。

通りすがり 2009/02/15 04:56 SSDに対して同意見の人がいて、なおかつ実証結果まで公開されいて素晴らしいと感じています。
某掲示板では話が合わないんですよね・・・。

で、憶測まじりですが僭越ながら追加説明をさせて頂きます。MLCはブロック単位で書き込まれる訳ですが、ブロックには
「空き領域か否か」といった情報が必ず存在しているハズです（ウェアレベリングで必要）。空き領域なら
そのまま上書き。空き領域でない場合は保持されている情報をいったん待避し、新たな情報と結合して書き込まれます。

この「いったん待避し結合」が遅いため、断片化するとそれが複数発生し速度低下になります。
空き領域の断片化を解消すれば「空き領域」と記されたブロックが増え、「待避結合」が無くなるため速度が
戻るのだと考えています。

間違いがありましたらご遠慮なくご指摘ください。

通りすがりその２ 2009/02/15 10:37 遅くなる理由は同意しますが、空き領域の断片化が解消されても空き領域と記されるブロックは増えないようです。
自分で調べたわけでは無いのですが、以下の記事がわかりやすいです。
http://nabe.blog.abk.nu/0252
記事中の「ウェアレベリングの実際」を参照ください。
またSSDにそれなりの空き領域がある状態でも速度低下が起きることからCFと同じくSSDにおいてもEraseSectorコマンドに相当する動作は行われていないと思われます。
OSから見える空き領域は、SSDの認識している空き領域とは異なる模様ですがWindows7とかだと改善されてるのかな？

Lansen 2009/02/15 12:51 NAND-FLASH製品では、論理アドレス上の"空き領域"と、物理アドレス上の"空き領域"は完全に別物です。
まず、"論理アドレス上の空き領域"は、今回デフラグの対象となっている空き領域のことです。普通に空き領域と言ったらこちらのことですね。
それに対し、"物理アドレス上の空き領域"はコントローラが管理しており、OSからは全く関与できません。JMF601/602搭載SSD限定ですが、"物理アドレス上の空き領域"が何ブロックあるかはJSMonitorから取得可能です。
例えば、今回使用したSSDの場合、使用可能なブロック数は8164、空き領域となっているブロック数は520です。
そして、OSが使用できる記憶領域の量は、8164-520=7644ブロックで、それにブロックサイズである1MBをかけた7644MBとなります。また、"物理アドレス上の空き領域"は520MBあることになります。
SSDはファイルシステムを理解していないので、当然どこが"論理アドレス上の空き領域"なのかは分かりません。たとえ0x00や0xFFでFillしても、それが中身が全部0x00や0xFFである有効なファイルなのか、それともOSが空き領域だと伝えたいのかはコントローラには分からないのです。
そのため、OSが"論理アドレス上の空き領域"をいくら増やしても、"物理アドレス上の空き領域"は増えません。
さて、NANDフラッシュの"消去状態"は、全てのセルが1になっている状態です。NANDフラッシュへの"書き込み"は、1ページ(上記のSSDの場合16KB)中の任意のセルを0にすることで行われます（書き込み）。しかし、0->1に戻すためには、そのセルを含むブロック(同1MB)中のすべてのセルを1にしなければなりません（消去）。
このように不便な構造なので、データの上書きには一手間必要です。
例えば、OSがファイルを4KB書き込むとします。このとき、今の論理アドレスと対応する物理アドレス上にデータをそのまま上書きすることはできません。なぜなら、0から1に上書きしなければならないセルがひとつでもあったら、ブロック全体を消去しなければならないためです。
そこで、コントローラはまず書き込み先のページ全体をDRAM上に読み込み、OSからの書き込みがあった部分だけを書き換えます。次に、その1ページ分のデータを空き領域となっているブロック(消去済み)のうち、最も書き換え回数が少ないブロックに書き込みます(ダイナミックウェアレベリング)。それだけでは、元のブロックのうち1ページ分だけが無効になり、新しく書き込んだブロックのうち1ページだけが有効になる状態になってしまいます。それでは困るので、元のブロック上のデータのうち、書き換えが無かった分も全部新しいブロックにコピーする必要があります。そして、コピーが終了してはじめて、元のブロックには有効なデータがなくなるので、そのブロックは消去され、空き領域に移されます。
要するに、OSは4KBの書き込みを行っているだけなのに、SSD内部では1MBのデータを移し変えないといけないわけで、時間がかかって当たり前なのです。これがランダムライトが遅い原因です。
なお、以上の話は非常に実直な実装で、おそらく各種SSDはこの辺の処理を工夫しています。そうしないと寿命の面でもパフォーマンスの面でもよろしくありません。MTRONやPhisonのようにランダムライトが遅い製品はこの通りの実装なのでしょうが、例えばIntelの場合書き込みキャッシュを無効にしてもかなりランダムライトが速いので、何かしらの工夫があるはずです(多分)。JMF602も、「ランダムライトだけならしばらくは速い」「ランダムライトとランダムリードを交互に行うと異常に遅い」といった不思議な特性があるので、「しばらくは速い」を実現する何かがありそうな気がします。
＃IntelやJMicronの特許とかを調べれば分かるかもしれませんが、さすがにそこまでの根性はないです…

aua 2009/02/15 23:51 CrystalDiskMarkはアルゴリズムがアホの子なのであまりアテに出来ないです。
誤差じゃないですか？
iometer等の他のソフトでやってみてくれませんか？

Lansen 2009/02/17 00:23 テスト回数は5回にしていますが、見ている限り結果の変動は大きくなく、せいぜい数%というところでした。
そのため、誤差であることは考えにくいです。
「アホの子」の意味が分からないのですが、具体的にどの部分のアルゴリズムのことでしょうか？

通りすがりその２ 2009/02/18 00:04 大変丁寧な解説ありがとうございます。じっくり読ませていただきました。
おかげさまで自分の頭の中で何やらモヤモヤしてた部分がすっきりしたような気がします。

論理ページと物理ブロックに何の関連性も無いのであれば、Windowsの圧縮ドライブのごとくデータ圧縮して書き込むとか書き換えられたページを抜粋して1ブロックにまとめてしまうとか（変換テーブルが大量に必要ですが）色々と細工の余地がありそうですね。ていうか、それがExtremeFFSなのか。

SSDにPC並みのハイパワーなプロセッサとメモリが搭載される日も遠くないのかもしれませんね。

Lansen 2009/02/18 01:10 どうやら、IntelのSSDはすでにページ単位でアドレス変換を行っているようですね。
それであのランダムライト性能を実現しているようですが、逆にそのせいで物理アドレス上の断片化が発生してしまうようです。
この物理アドレス上の断片化は、論理アドレス上のデフラグでは直せず、むしろ状況を悪化させる可能性もあるようです。そもそも、空き領域デフラグはランダムライトが遅いSSDの性能回復方法ですから、Intelのようにランダムライト性能が高いSSDではデフラグは不要といってもいいと思います。

ささもと 2009/02/24 21:48 ＞また、すでに書き込み済みのファイルの同じところに繰り返しデータを書くという使い方はまれで、おそらくページファイルぐらいなのではないでしょうか。
＞それを考えると、寿命を削ってまで書き込み済みのファイルをデフラグする必要性があるかどうかは微妙です。

いえいえ、WindowsUpdateやイベントログなど各種ログファイルやシステム復元データなど、同じところに繰り返しデータを書き込んだりする場合も多々あります。
ウチのブログでその辺書かせてもらいましたのでご参照を。
http://orbit.cocolog-nifty.com/supportdiary/2009/02/post-a7d9.html
しょっちゅうアクセスするファイルの断片化が1ファイルで4000近くになると…やっぱり影響は大きいのではないかと。

Lansen 2009/02/25 01:34 >ささもとさん
ページファイルは、最初から一定の容量が確保してあり、そこに繰り返し上書きが行われます。
ログファイルは、先に書いたデータを上書きせず、後からデータを付け足すという違いがあります。
ですが、まあさすがに4000個にも断片化されると、SSDでも読み込み速度に影響あるでしょうね…

ささもと 2009/02/25 21:57 早速のご返答ありがとうございます。
なるほど、ログファイルはデータの追加のみですか…。となると、ほとんどの場合はログファイルへの追加のたびに、ログファイルもですが、時間的に平行して書き込まれるファイルに、くさびが打ち込まれるがごとく断片化が発生することになるわけですね…。
断片化は個別で勝手に発生するわけではなく、空き領域なり他のファイルの断片化の隙間なりとセットで起こる訳ですから。
システムが起動ファイルに書き込みを発生させるものの一覧って、どこかにないですかねぇ…。
それらを別ドライブへ追放して完全にゼロにすれば、OS自体が周辺機器のファームウェアと同じになりますので、SSDも使い出があるんですけどねぇ。

Lansen 2009/02/26 23:21 >ささもとさん
プログラムAがファイルAにちょっとだけ書き込んで保存、プログラムBがファイルBにちょっとだけ書き込んで保存、プログラムAが…というように別のファイルへの書き込みが交互に起こると、かなり激しく断片化しそうです。
Windowsが黙ってどんなファイルを書き込んでいるのかは確かに興味深いですね。ちょっと調べてみた感じではよくわかりませんでした…

あ、あとどうやら昨日の夜ははてなのサーバに障害があったようです。重複書き込みは削除しておきました。

cuttingedge 2009/03/09 16:45 こんにちは。これってPC PerspectiveのX25-Mの記事にあるHDDEraseで消去するとどうなるんでしょうね？時間がある時に試してみていただけるとありがたいです。

ｋ 2009/03/10 20:19 窓の杜掲載おめでとうございます。

Lansen 2009/03/12 01:10 >cuttingedgeさん
IntelのSSDの件は、物理アドレスレベルの断片化を直す方法についてですね。
JMF602はブロック単位でしかウェアレベリングを行いません。すなわち、1MB〜4MB単位のデータの順番を入れ替えているだけなので、物理アドレスレベルでは断片化が生じず、継続使用時のパフォーマンス低下は起こりません。
上のコメントでもちょっと触れましたが、IntelのSSDはよりブロックより小さな単位、おそらくページ単位（4KBx10=40KB?）でウェアレベリングを行うため、ランダムライト性能が高いかわりに継続使用で物理アドレスレベルでの断片化が発生してしまい、完全に性能を戻すにはSECURE_ERASEで初期化するしかないということのようです。

>ｋさん
どうもです。どうやら記事になっただけで、まだライブラリに登録されたわけではないようですね。
次期バージョンも準備中ですが、最近なかなか現実から逃れられません…

cuttingedge 2009/03/12 11:21 Lansenさん、コメントありがとうございます。なるほど。速度低下のメカニズムが違うわけですね。インテルの方はwrite combineの副作用ということだと、X25-Eでもヘビーな使い方をするとX25-Mと同様の現象が起きる可能性もありますね。今のところ手元の個体は問題ありませんが・・・　　SamsungやIndilinxなど他のコントローラではどうなのか興味深いところです。

Lansen 2009/03/13 01:51 原理的にはX-25Eでも性能低下しそうなものですが、かなり予備領域を多めにとってある(8GB)のが効いているのかもしれません。
あと、どうもVertexも性能低下するみたいですね…
http://www.exa5.jp/diary/eid369.html
これらの性能低下を完全に直すには今のところHDDEraseしか方法がないってのが痛いですね。

cuttingedge 2009/03/13 07:22 現状では最大使用領域は80%くらいに留めておいた方が無難なようですね。VertexもHDDEraseで回復した例がForumにあがってました。たぶん、いずれ他にもToolが開発されてくるのでしょうね。

ささもと 2009/03/16 11:22 今回、手元のMLCのSSDで、空き領域の断片化がパフォーマンスに影響を与える情況を確認しました。
時間がなくて不充分な実験ながら、空き領域の影響が裏づけできたと思います。

ところで、意図的な断片化を起こす「みじん切りソフト」は公開されないのでしょうか？

Lansen 2009/03/17 01:16 >ささもとさん
記事拝見しました。既にわざとフラグメント化を起こすソフトってあったんですね。そんな意味ないものを作る人いないだろうと思って調べていませんでした。
こちらで作ったソフトは他人に見せるつもりがなかったので超適当で、そもそも実行しても何の意味もないので特に公開するつもりはないです…
ちなみに、プチフリの原因はJMicronのコントローラと考えてほぼ間違いないようです。
JMF602はコスト削減のためか、Intel8051という非常に低性能なプロセッサを利用しています(他社の製品はほとんどARM)。また、独立したDRAMチップを持っておらず、コントローラに内蔵されたわずか96KBのDRAMで全てをまかなっているようです。
96KBのうち、ブロックコピーに使用するバッファは64KBということなので、MLCの場合はブロックコピー完了までに64回のコピー処理が必要になってしまいます。これでは遅くても仕方がないです。IntelやVertexは独立したDRAMチップを搭載しているので、おそらくブロックコピーは一発で完了してしまいます。
個人的にはその限られたリソースの中ではかなりうまくやっているように感じていますが、いかんせんプロセッサは非力すぎ、メモリは少なすぎです。コスト重視の設計が裏目に出てしまっていますね。

cuttingedge 2009/03/17 19:52 こんばんは。0Fillの実行後にランダム書き込み性能が劣化したままだったSAMSUNG SLCをHDDerase3.3で（enhansed) secure eraseしてみたところ、だいたい初期の状態まで戻りました。この製品でもこの手が使えるようで安心しました。しかし、全域書き込みは出来るだけ避けたほうが無難ですね。近いうちにBlogにアップします。

ささもと 2009/03/18 07:24 そうですか、公開の予定なしなんですね。
まぁ、本当にみじん切りにしたら、どんな影響が出るかわかりませんので「凶器」にもなりかねないでしょうから…。
でも、SSDという特殊なデバイスにおいての検証には必要なツールなんですけどね…。

＞ちなみに、プチフリの原因はJMicronのコントローラと考えてほぼ間違いないようです。

うーん、その表現は適切ではないような気がします。
「『起動ドライブ』において『プチフリーズが顕著に現れる』のはJMicronのコントローラの性能が低いため」
ですよね。
数MB単位の書き込みが当たり前に発生するドライブで、バッファがたった64KBでは、無理があるのは当たり前でしょうけどね…。

「原因」は、あくまで「ウェアレベリングと過度の断片化の兼ね合い」であり、「断片化が発生しなければ」「書き込みが発生しなければ」という条件下（たとえばあまり書き換えのないデータドライブとか）ではプチフリーズなど発生しうるはずもなく、JMicronでもMLCでも何の問題もなく使えるはずです。

記事（コメント）にも書きましたが、フラッシュメモリのSSDが真価を発揮するのは、起動ドライブへの書き込みのないOSとか、HDD前提ではなくSSDに最適化されたインターフェース・ファイルシステムとかが必要だと思います。
「システムファイルの読み出しがメイン・書き込みはインストール時のみ」であれば、それこそ以前から言われている通り「SSDにデフラグは不要（というより問題となりうる程度の断片化は発生し得ない）」なのですから。
まぁ、素子が書き換え寿命有限のフラッシュメモリでなくなれば（たとえばバッテリーバックアップ＋SRAM/DRAMなど）、ウェアレベリングもないので、プチフリーズなどありえないのでしょうけど。

コメントであまり持論を展開するのも気が引けますので、また後ほど自分ちでまとめてみます。

Lansen 2009/03/18 22:59 >cuttingedgeさん
いつも返信が遅くてすみません。
Samsungも継続使用で速度低下を起こすんですね。MTRONよりRandomWriteが速い代償というわけですか…
ということは、現時点で空き領域デフラグを推奨できるのはJMicron、MTRON、Phisonで、非推奨なのはIntel、Indilinx(Vertex)、Samsungと言ったところですね。
例のPC Perspectiveの記事では、Intelのはでかいファイルをシーケンシャルライトするとよくなることもあることが示されています。ノートの場合はスタンバイよりハイバネーションを使うとよかったりするかも？

>ささもとさん
確かに、JMicronも書き込みが無ければ高速ですね。
割と以前から、振動などの問題でHDDが使用できない環境(主に組み込み系)では、産業用のSSDやコンパクトフラッシュにOSをインストールして使われています。これらは非常にランダムライト速度が遅いのでWindows XPはまともに動作しません。そこで、XPのEmbedded EditionではEnhanced Write Filter(EWF)という機能があります。これは、書き込みの命令が来ても実際にはディスクには書き込みを行わずにメモリに蓄えておき、後で反映させるかまたは全て変更を廃棄するかを選ぶというソリューションです。
JMicronの場合は、ランダムライト速度は速いとき (CrystalDiskMarkの結果)と遅いとき(HDTune 3.5の結果)があります。それが、「ずっと遅くて全然使い物にならない」と「ずっと速くて快適」の中間であるプチフリという現象(ときどき遅くて使い物にならない)を発生させてしまうようです。すなわち、この現象はJMicron以外のSSDやコンパクトフラッシュにも、HDDにも見られない現象なわけです。
ちなみに、現在JMicronのそのパフォーマンスの謎を解析中です。週末に結果と考察をアップできたらいいなあと思っています。

cuttingedge 2009/03/19 00:13 いやいや、学会シーズンだし本業の方も大変でしょうから気にされなくてもOKです。Option 1の方はちょっと結果が微妙な気もしますね〜（笑
この件を含めたタイムリーな記事がAnandtechに本日付けで出ましたね。

ささもと 2009/03/19 01:21 お忙しいのに丁寧なご返答をありがとうございます。
無理なさらずに。

ところで、決してJMicronの攻撃でも擁護でもないのですが、HDDでもプチフリーズらしき現象は起こります。
私の環境では、メモリ不足の環境において、それらしき現象がしばしば発生します。
たとえばメモリ実装256MBでXPのSP2〜3環境でウイルス対策ソフトを使っているとか、1GBでもブラウザウィンドウを30個ぐらい開きっぱなしとか、そういう環境だと、時折反応がなくなったりすることがあります。
こういうのをプチフリーズと呼んでいいものかどうかはなんとも言えませんが、「時々反応がなくなる」という点では同じかと思いましたので。

ところで、コンパクトフラッシュって、ウェアレベリングはありましたっけ？
なければ「発生しない」ことにおいては比較対象にならないような気がするんですが、いかがでしょうか。

Lansen 2009/03/20 01:12 お二方ともお気遣いありがとうございます。
来週末にはハッピーになれるはずです…

>cuttingedgeさん
Anandtechの記事は気合い入りすぎですね。
これは読むのに時間と体力がかかりそう…

>ささもとさん
確かに、メモリを使い果たしてスワップが多発している状態でさらに読み書きを行うとそうなりますね。
本業ではやたら常駐するソフトの多いノートを使っているのですが、HDD時代は起動直後ではかならずそんな症状になっていました。
ただ、JMicronの場合は空きメモリに余裕があってもプチフリが発生してしまいます。せっかく高いお金かけてPC組んだのになんで？と怒っている方がよく見受けられますね…
ちなみに、コンパクトフラッシュでもウェアレベリングは働いています。
もしかするとウェアレベリングのない物もあるかもしれないですが…

SSD 2009/08/14 19:40 Defragglerで、空きスペースのデフラグをすると、使用済みディスクの容量がどんどん増えるのですがなぜでしょうか？解決策ありますか？　教えていただければ助かります。よろしくお願いいたします。

Lansen 2009/08/14 22:36 うーん、ちょっと分からないですね…
別の原因ではないでしょうか？
どのフォルダ・ファイルが容量を食っているかを調べるには、FileSumというツールが便利です。これを使って、どのフォルダが肥大化しているかを調べてみてはどうでしょうか。

ＳＳＤ 2009/08/15 00:54 ありがとうございます。色々いじってたら、システムの復元を無効にすると１０ＧＢくらい一気に減りました。こんなにとってるんでしょうか〜？　なので、色々アップデートしてちゃんと安定しているようであれば、一回復元無効にして、その後すぐ有効にしてっていう、面倒なことしながらやってます。　紹介いただいたソフト使ってみます。また何かありましたら教えていただけると助かります。ありがとうございました！

Lansen 2009/08/15 21:00 普通のデフラグなら復元には反映されないはずですが、Defragglerは違うのかもしれないですね。
復元に使用するディスク容量は、システムのプロパティから変更できます。デフォルトだと総容量の12%とかになってたりするので、もっと少なめの容量にするのが一般的ですね。

SSD 2009/08/23 21:51 度々すみません。
復元に使用するディスク容量は、システムのプロパティから変更できます
どうやってやるのか分かりません。ＸＰのように簡単にできないのでしょか？
お手数ですが、やり方、設定するとこにいく方法教えていただけないでしょうか？　よろしくお願いいたします。

Lansen 2009/08/24 20:49 http://plusd.itmedia.co.jp/pcuser/articles/0705/10/news022.html
これでできませんか？

SSD 2009/08/25 21:01 ありがとうございました。一応８ＧＢくらいに設定しました。２５６ＧＢあるのですが、このくらいで大丈夫でしょうか？　色々とありがとうございます。かなり役に立てさせていただいてます。

shige 2009/11/15 02:36 はじめまして^^

さっそく　Defraggler　DLして使ってみました。

軽く♪　飛べるかも^^;

ひげ３３９ 2010/08/22 11:59 >SSDさん
下記にデスク容量減少に関する記述があります。
intel SSD Tool Box で解決できるそうですが、intel 製に限られます。
当方Samsung 64Gですが、FileSumでは３０Gしか表示されませんが、デスクのプロパテイでは95%使用で空きが5%で使い物になりません。調べているうちに下記WEBとここへたどり着きました。

LANSEN さん、お忙しいとは思いますが解決していただけませんか。
http://www.intel.co.jp/jp/consumer/Shop/diy/features/ssd/optimizer/p2.htm
＞こうして、ファイルの生成・削除を繰り返していくと、Windows* 上では空き領域が多くあるのに、SSD にとっては空き領域がほとんどない状態が生じ (下図の右下)、使い込むにつれて性能が低下することになってしまいます。

Lansen 2010/08/22 13:30 それはSSDとは関係ない症状だと思います。
SSD ToolBoxでWindowsから認識される空き領域が増えることはありません。ディスクのプロパティで"空きが5%"と表示されているなら、それはWindowsがそのように認識している(=論理ドライブの空き容量がそれしかない)ことを示します。"SSDにとっての空き領域"をOSから取得する方法はありません。
おそらく、FileSumで取得できないファイルが20GB以上存在しているのでしょう。(具体的に何かは分かりません)
とりあえず、ディスクのクリーンアップと、上記の復元ポイントの容量の削減を行ってみてください。あとはhiberfil.sysの削除、ページングファイルの無効化またはサイズ縮小(手動でサイズ設定)とかでしょうか。

ひげ３３９ 2010/08/22 20:23 >Lansenさん
ありがとうございます。

インテルが下記でSSDをXp,Vistaで使用する時には容量の減少はしょうがない、7では解消されていると記載されています。
http://www.intel.co.jp/jp/consumer/Shop/diy/features/ssd/optimizer/p2.htm
＞こうして、ファイルの生成・削除を繰り返していくと、Windows* 上では空き領域が多くあるのに、SSD にとっては空き領域がほとんどない状態が生じ (下図の右下)、使い込むにつれて性能が低下することになってしまいます。

ハードの制限上、Xpで使うしかない機種での、intel以外のSSDでの解決策を探しているところです。

Lansen 2010/08/23 00:44 ちょっと誤解があるようですね。
ひげ３３９さんが仰る「空き領域」（空きが5%）というのは、「論理アドレス上の空き領域」のことです。
一方、SSD ToolBoxで回復できるのは「物理アドレス上の空き領域」です。
両者は似ているようで全く異なります。前者はWindowsが認識している情報で、後者はSSD内部のコントローラしか知り得ない情報です。従って、例えひげ３３９さんの環境でSSD ToolBoxを実行可能だったとしても、「空きが5%」の状態から増えることはありません。
以下のような例えで理解していただけるでしょうか。
最近話題になっている100歳超の高齢者問題の逆パターンみたいなものです。お役所の記録(論理アドレス)では100軒の家のうち70軒に人が住んでいることになってますが、実際の家々(物理アドレス)では100軒中90軒に人が住んでいます。そこで、一斉家宅捜索(SSD ToolBox)を行うことで、お役所の記録に無い20軒から住人を追い払う(物理アドレス上の空き領域を増やす)ことができます。
ひげ３３９さんの環境では、お役所の記録に"100軒中95軒が入居中です"と書いてあるようなものです。従って、お役所の記録(Windows上のファイル)を消さない限り、問題を解決することはできません。
そういうわけで、空き容量の計算が合わない原因は、FileSumでカウントされていない大容量のファイルが存在するためだと推測されます。

ひげ３３９ 2010/08/24 21:54 Lansenさん

>空き容量の計算が合わない原因は、FileSumでカウントされていない大容量のファイルが存在するためだと推測されます。
最初は私も、何らかのエラーで消え残ったテンポラリーファイルが残ってるのだろうと思っていました。
ところが、隠しファイルから何から探しても見つかりません。探し方が悪いのかもしれませんが。

原因は別なところにあるのでは、と探していたら下記インテルのWEBに行き着きました。
http://www.intel.co.jp/jp/consumer/Shop/diy/features/ssd/optimizer/p2.htm
>こうして、ファイルの生成・削除を繰り返していくと、Windows* 上では空き領域が多くあるのに、SSD にとっては空き領域がほとんどない状態が生じ、

これはインテルのSSDに限ってのことかもしれませんが、少なくてもインテルのSSDでは空き領域が減少する現象が発生しているようです。
この現象の解決に　intel SSD Tool Box を使用すると。

>お役所の記録(論理アドレス)では100軒の家のうち70軒に人が住んでいることになってますが、実際の家々(物理アドレス)では100軒中90軒に人が住んでいます。そこで、一斉家宅捜索(SSD ToolBox)を行うことで、お役所の記録に無い20軒から住人を追い払う(物理アドレス上の空き領域を増やす)ことができます。

Filesum で空きが３０％なのに、デスクのプロパテイでは空きが１０％しかない。
これに intel SSD Tool Box　を使うと、強制退去で空きが３０％になる。その結果、デスクのプロパテイでも空きが３０％に増える、と思いました。

当方のSamsung製SSDにintel SSD Tool Box を試しましたが、intel only表示で不可能でした。
その為、intel SSD Tool Boxの効果を確認できていない状況です。

Lansen 2010/08/25 00:32 >これはインテルのSSDに限ってのことかもしれませんが、少なくてもインテルのSSDでは空き領域が減少する現象が発生しているようです。
いえ、そうではありません。IntelでもSamsungでもそのようなことは起こりません。
原理的にも考えられませんし、僕もかなり長いことIntelのSSDをXPで使っていたので信じてください。また、Samsung用のSSD ToolBox相当のツールは存在しませんので、どうしようもありません。
とりあえず、システムの復元の最大使用量と現在の使用量は何GBですか？あと、念のためチェックディスク(「不良セクタをスキャンし回復する」のオプション付き)とディスクのクリーンアップも行ってみてください。

ひげ３３９ 2010/08/26 21:14 Lansenさん
総てのSSDで起こる訳ではないと思います。もし、そうなら大問題になってる筈です。

下記はインテルの公式サイトです。
http://www.intel.co.jp/jp/consumer/Shop/diy/features/ssd/optimizer/p2.htm

この公式サイトで下記が公表されています。
１．＞こうして、ファイルの生成・削除を繰り返していくと、Windows* 上では空き領域が多くあるのに、SSD にとっては空き領域がほとんどない状態が生じ、
２．Xp,Vistaでは発生するが、Windows7では発生しない。
３．解決策として　intel SSD Tool Box　を提供している

intel ではどんな時に本現象が発生するか、熟知していると推測されます。対策ツールまで提供しているのですから。

多分、Windowsの何らかのシステムエラーが発生してるPCで発生すると思われます。

そこで、Windowsの修復セットアップをしようと思ったら、PCの持ち主から「CDが見つからない、探している」との事で修復セットアップは試せてません。

やむを得ないので、Windows7にアップグレードしようとしたら、「１６Gの空き容量が必要」の表示でアップグレード不可能でした。

現在、次の一手をどうしようか思案中です。

Lansen 2010/08/27 02:07 うーん…
ちょっと失礼な言い方になってしまいますが、ひげ３３９さんはIntelの説明文を誤解されています。ひげ３３９さんの環境でたとえIntel SSD ToolBoxを実行することができても、この問題の解決はできません。まずそれを受け入れてください。
「Windows上では空き領域が多くあるのに」とあるのが「論理アドレス上の空き領域」(ディスクのプロパティで表示される空き領域)のことで、「SSD にとっては空き領域がほとんどない状態が生じ」とあるのは「物理アドレス上の空き領域」(Windowsから取得する方法はない)のことです。要するに、ひげ３３９さんの環境では、
「Windows上では空き領域が多くあるのに」ではなく「Windows上で空き領域がほとんどない」状態なのです。
Intelが解説しているのは、SSDを使い込む(具体的には多数回のランダムライトを行う)うちに性能が下がる現象についての対策です。性能が下がるだけで、Windowsから使用できる容量が減少することは絶対にありえません。
なお、Windows 7でこの現象が発生しないのは"Trim"というコマンドが追加されたためです。SSD ToolBoxはXPやVistaでTrimを使うためのツールです。

> 多分、Windowsの何らかのシステムエラーが発生してるPCで発生すると思われます。
というのには僕も賛成なのですが、それはSSDそのものが原因ではありません。
その解決法として、とりあえずシステム復元の使用量を調べるのとチェックディスクの実行をおすすめしたのですが、もう実行されましたか？

Lansen 2010/08/27 03:15 先ほどサブマシンで確認してみたのですが、やはりFileSumではシステム復元が使用しているディスク領域はカウントされないみたいです。
ディスクのプロパティでは、最初は約21.0GBを使用中でしたが、システム復元領域を一時的に200MBにしてみたら約18.0GBになりました。
一方、FileSumの集計では、システム復元領域の変更の前後でほとんど変わらず、ともに約19.0GB程度でした。

ひげ 2010/08/29 11:16 Lansenさん
大いなる誤解をしておりました。

入居者のたとえですが、
windows　は入居者のリスト(FileSum,Explorer等で表示)だけを管理しており、実際のリストはSSDにお任せ。
入退出後、windows　のリストは３０人の状態で、SSDに空きを問い合わせたら６０のうち空きは１０のリスト（デスクのプロパテイで表示）が返ってくる。
リストが合わないので一斉捜索(intel SSD Tool Box)をすると、SSDも６０のうち空きは３０のリストになり、使用状況が合致するものと解釈していました。


>とりあえずシステム復元の使用量を調べるのとチェックディスクの実行をおすすめしたのですが、もう実行されましたか？

デスクのチェックは完全スキャンをしましたが、空きは変わりませんでした。

システムの復元領域ですが、最新の１個だけにしていましたが、vssadmin で確認したら９G近くありましたので
シャドウ コピーの記憶域の使用領域: 8.405 GB MB
シャドウ コピーの記憶域の割り当て領域: 8.648 GB
シャドウ コピーの記憶域の最大領域: 8.944 GB

シャドウ コピーの記憶域の使用領域: 110.453 MB
シャドウ コピーの記憶域の割り当て領域: 400 MB
シャドウ コピーの記憶域の最大領域: 2 GB

これで空きは一気に１５Gまで増えましたが、１６G必要ですので。
とりあえず不要なフォントの削除、office,AdbeReader　などのアンインストールをしても空きが増えない状態でした。

ここで、止むなく力業に移りました。
SSDの内容をHDDにコピーし、HDDで起動させてデフラグをしたら空きが２４Gになりました。
次にHDDの内容を、SSDを初期化後にコピーして空きを確保しました。
とりあえず、初期の目的を達成したので、良しということで。

非常なるお手数をおかけしました。

Lansen 2010/08/30 01:31 お、デフラグしたら領域増えることってあるんですか…
まあ、解決できたのであれば良かったです。
ちなみにSamsungもSSD ToolBoxに相当するソフトを作成中らしいです。現行のモデルが対応しているかどうかは分からないんですが、もし対応しているのであればXPやVistaでも性能低下の心配なく使用することができますね。

ひげ３３９ 2010/08/31 14:17 Lansenさん

＞ちなみにSamsungもSSD ToolBoxに相当するソフトを作成中らしいです。
やっぱり、そうですか。

HDDにコピーしてSSDに戻す、と云う姑息な手段で空き容量ができたので、Windows7にアップグレードしました。
そして、Windows７でDefragglerを実行してみました。
CCleaner を実施して、１９Gの空き容量でした。
結果は、１９Gから２２Gへ空き容量が増加しました。

同じSSDでありながら、Vistaでは減少するだけで増えることはなかったのに。
Windows7 では解決されている、を実感しました。