アカウント名:
パスワード:
HDDの場合、デフラグはHDD領域全体に連続的な負荷を要求するため、やり過ぎは寿命を縮めるということらしい。
そりゃ当然だろ。むしろ、大量にアクセスするが効率化された結果寿命が増える、とかの調査結果が出たならニュースバリューがあるが。
また、SSDの場合はフラッシュメモリの書き換え回数に制限があるため、やはりデフラグにより寿命が縮まる可能性があるらしい。
寿命が減るのはいちいち言われないとわからないのかよ!レベルの話として、いやそもそもSSDでデフラグって、なんか間違ってなくね?ディスクと違って順番に読み込む必要がないんだから、そもそもデフラグなんてほぼいらないような・・・
元記事を見ると
リンクスインターナショナルはHDD製品の取り扱いをしておらず、特定のHDDメーカーから特別な情報協力等は受けていない、同社独自の見解となります。
と書かれてて、元記事自体がエビデンスなしの一般論(HDD取り扱っていないPCパーツ代理店のお話)にすぎない様です。よく読むと「デフラグで寿命縮むかもしれません。でも一番影響するのは熱ですよ」と書かれています。
デフラグが必要かどうかはユースケースに大きく依存しますよね。空き容量が2割を切るような使い方をしていると断片化しやすいです。NTFSに代表されるような最近のファイルシステムはなるべく連続領域を割り当てるように設計されてますが、空き容量が少なくなるとそもそも空き連続領域が存在しない、なんてことになります。
確かに過度な断片化は性能に悪影響を及ぼしますが、そもそも多くのI/O単位はそんなに大きくないので数十MB以上に連続してファイルが配置されていることが重要だとは思いません。
Windows 8 では SSD にたいして「最適化」すると、TRIMを全空き領域に対して発行しますね。そもそも削除するときにTRIMしているような気がするんですが、これは効果あるんでしょうか。
と書かれてて、元記事自体がエビデンスなしの一般論(HDD取り扱っていないPCパーツ代理店のお話)にすぎない様です。
エビデンスについての記述が無いのは確かなんだけど、記事の引用部分はエビデンスの有無について言っているのではなく、ハードディスク製造者に有利な発言をしているわけではない、と言う主張なんだと思うけど。
デフラグが必要かどうかは<<略>>数十MB以上に連続してファイルが配置されていることが重要だとは思いません。
それってエビデンスは…
>でも一番影響するのは熱ですよもともと80GB/SATAしか無かったノートパソコンのHDDをホップステップジャンプで750GB/SATA2まで増量したらHDDが飛びまくる。保証期間なので返送して同じ物が送られてきてはまた飛ぶ。3回飛んだので「同等の別な製品に換えてくれ」とメールで送っても無視された。送られてきたものはファン付きの外付けケースにしなきゃ使えないのかなぁ。
アンペア数大丈夫?ノートPCの場合、電源設計がシビア過ぎて、安易にHDD載せ換えると、電流が足りなくて飛ぶよ。元々載っていたHDDの低格消費電流と比べてみては。
私の経験だと、一般に省電力と思いこまれているSSDだけど、最近の高速タイプは意外と電流食いで、古いノートPCに載らなかった事があるよ。
> NTFSに代表されるような最近のファイルシステムはなるべく連続領域を割り当てるように設計されてますが、
うちのVistaや7や8はそんな動きをしないけど。
最初にデフラグしてファイルをディスクの先頭に詰めておき、その中のファイルを削除して穴ができると、次に大きなファイルを書き込むときにはファイルの削除跡の小さな穴から埋めていくため、ほとんどの場合断片化するよ。
ちなみにディスクの使用量は30%以下ね。
# しょっちゅうDiskeeperやO&O defragでファイル配置を見ていると、# 広大な空き領域から使っていくことも確かにあるが、# NTFSが必ず連続領域を優先的に使うという感じは全くしない。
ファイルの種類で割り当て方を変えてるとかないのかな。シーケンシャルにしか利用しないファイルなら多少断片化してても問題なし、とか。ランダムアクセスするファイルなら(先読み分のキャッシュなどで)連続してる方が望ましい、とか。
ファイルシステムはそんな用途は分からないから無理なんじゃないかなー。
拡張子で判別とか、利用状況の統計とるとか。
大きなファイルを入れるドライブはクラスタサイズを大きく設定してますが、それでもディスクの断片化の影響は実感できますね。時々、他のドライブに移動する擬似的なデフラグ操作をしたりします。
>NTFSに代表されるような最近のファイルシステムはなるべく連続領域を>割り当てるように設計されてますが、空き容量が少なくなるとそもそも>空き連続領域が存在しない、なんてことになります。
XPですがエクスプローラーでファイルコピーするとおおむね連続領域にコピーされることに最近気が付きまして、(特に巨大ファイルを)あえてコピーして元ファイルを消すことでピンポイント簡易デフラグしています。(対象ファイルは勘で選ぶ、「分析」で確認しながら)でも通常の open()->write() でファイルを作るもの (たとえば zip.exe とか)は open() 時に最終ファイル長がわからないからなのか、ファイル長がでかくなると当然断片化するのです。
これは open() 時に長さをヒントとして与えられるようは特別な open() 相当のシステムコールがあるのか、エクスプローラーのファイルコピー機能の努力の結果なんでしょうか?
いや、もろに CopyFile http://msdn.microsoft.com/ja-jp/library/cc429185.aspx [microsoft.com] とか CopyFileEx http://msdn.microsoft.com/ja-jp/library/cc429187.aspx [microsoft.com] とかいうそのものずばりの API 関数があるのですが。
Cドライブが余りまくっていてもWindowsUpdateでボロボロになるのは最初に個々のファイルサイズが分からないということなのかな?
SetFilePointerとSetEndOfFileであらかじめファイルサイズを拡張しておくと連続領域を確保できるらしい
デフラグは寿命を縮める、熱はもっと縮めるってとっくの昔にGoogleが発表してましたよね?
あれって、ディスクの故障とデフラグの因果性を、ディスクをばらして故障原因まで突き止めたんだっけ?
# 個人的には、単なる経験則を発表しただけで、信用に値しないと考えている
そんな都市伝説みたいな話、信じてる人まだいるんだ。デフラグのやりすぎで壊れるなら、やらずに非効率なアクセスを続ける方が圧倒的に寿命縮むだろ。あほくさ。
若いなぁ
断片化してるファイルが頻繁に使われるとは限らない。滅多に使わないファイルなら断片化してようがたいして影響はない。
そして、昨今のファイルシステムは、ファイルオープン時に断片数が既定値を超えていたら自動でデフラグするんじゃないの? 全体を一括でデフラグするよりは空き領域に対しての効果は落ちるが(空き領域の連続化)、十分な空き領域を確保した上での運用であれば、これでも十分だと思う。
滅多に使われないファイルなら一度デフラグしたら以後はいくらデフラグをスタートさせても移動は発生しない。
そして、全体を一括でデフラグしようが、ちょこちょこやろうが、寿命にはなんの違いもない。だいたいW/Rの回数やシーク量と寿命にはほとんど相関無いし。
だいたいW/Rの回数やシーク量と寿命にはほとんど相関無いし。
そうなの?Winnyが盛んだった頃、そのあまりのHDD酷使っぷりに、金子氏はHDDメーカーの回し者だのと揶揄されてた記憶があるのだけれど・・・あれはディスクスペース的な意味だけ?
HDD前方に空き容量ができた時に、既に整列しているファイルでも詰めようとして移動することがあるけれど?
移動しようとしているファイルより大きな連続領域が先頭方向にあるときだけ移動するDiskeeper系のアルゴリズムですね。
「やりすぎ」の意味、ご存じですか?必要最低限のデフラグまでは誰も否定していませんよ。
デフラグのやり過ぎが寿命を縮めるなんて、専門家でなくてもすぐに予想できると思う。
そこで問題になるなのは「どのくらいの頻度でやるのが『最適』なのか?」とか「どのくらいやり過ぎたら、(たとえば)寿命が半分になるのか?」とかじゃね?
ねぇねぇ、なんで寿命が縮むの?
磁性体やヘッドがすり減るの?
ヘッドの軸受け部分に負荷がかかるだろうが。ヘッドの移動量が増えればそれだけ摩耗も早くなる。
やりすぎればの話でしょ。全体のデフラグでは空き領域を連続化するために断片化していないファイルの移動も発生するんだから。
ただ詰めるだけじゃなく、ソフトによってはファイルの種類によって、ディスクの内周に集めたり外周にどかしたりもしてるんだから。最近のは知らんけど、旧MacOSの頃のNortonSpeedDiskとか。DiskWarriorはどうだったかな。
G3Mac+MacOSXの頃「8GBの壁」問題で、先頭から8GBの領域内にシステムファイルが入ってないと起動しないなんてのがあって、SpeedDiskで集めてなんとか起動させたってことがあった。
家庭用なら、デフラグする頻度を上げれば1回のデフラグで移動するデータも大したことがなく、軸受けの摩耗なんか誤差だよ。
フラッシュメモリデバイスの場合は,極端に寿命が縮まるから デフラグしちゃダメよ! というのが一般論だと思ってたんですが,違うんですかね?:SSDだと,効果がない じゃなくて,むしろ害悪 じゃないかと.USBメモリなんかに デフラグかけちゃダメ,と言われてたのと同じで.
ウェアレベリングで 書き込みが極端に集中してバカになる箇所が出ないよう 大体平滑化してるのに,わざわざデフラグで偏らせるなんて!って理解してました.
ファイルシステムのメタデータは、デフラグする方が好ましい。これは、メタデータ自身がキャッシュされるんで、カーネルの消費メモリ削減になって、システム全体が若干高速になるから。
あと、SSDなら、ブロック範囲に収まるデータは、一ブロックに集約するのが良いが、それ以前に、良く書き換えるファイルと書き換えないファイルを同一ブロックに入れない様にする事が肝要。
でも、SSD内の論理-物理変換方式は、各社研究中の流動的且つ重要な機密情報なんで、サードパーティーツールで最適化する事は実質不可能。
でも、断片化してるとメタデータが増えているのは確実だから、SSDでもデフラグは無意味じゃない。如何に優秀な方式でも、余分なデータが無い方が確実に効率を上げられるからね。
ただ、SSDの場合は、頻度と積極性は下げる方が良い。つまり、極端にフラグメントが進んでる場所だけを必要最小限の移動でデフラグする方式がベストになる。具体的には、解析にやや時間が掛かるが、実行自体は瞬時に終わる物が良いって事になる。
ところで、ちょっと疑問なのですが。SSDで、ファイルの領域が連続しているとデフラグソフトで表示されていたときでも、内部のメモリのアドレスとして必ずしも連続していないのでは?メモリの使用頻度の平準化とか不具合部分の回避とかするんですよねぇ?ちがうの?
SSD内の論理-物理変換に粒度の制限がある。
ぶっちゃけ、セクタ単位での個別物理変換テーブルなんて持たせたら、容量の無駄遣い。更に、論物変換データ自体もフラッシュに格納される事を忘れない様に。
論理-物理変換の変更量が増えると、やはり寿命を縮める事になる。なので、論理側で不変領域を一箇所に集中させる(変動領域を一箇所に集中させるのと等価)と、論物変換の管理領域の更新量が減って、性能と寿命が両方向上する訳。
SSDでは論理セクタと Flash のアドレスは相関が弱いので、デフラグしても偏らせることにはならないと思います。もちろん寿命の観点からはデフラグしない方が良いのでしょうが、パフォーマンスという観点ではプリフェッチやリードアヘッドの効果はデフラグした方が高くなると考えているのですが違いますかね。別の視点ですがリードディスターブが怖いので、SSDは年に一回程度全部HDDにコピーして、SSDにコピーバックしてます。
SSDの論理セクタと Flash のアドレスは相関が弱い,とおっしゃっているのにパフォーマンスという観点ではデフラグに効果がある,とか> SSDは年に一回程度全部HDDにコピーして、SSDにコピーバックしてます。というのは矛盾しています.
特に後者のコピーバックは,注意しないと Flash側(アドレス空間)が断片化し,パフォーマンスが大幅に低下します.特に, TRIMコマンドを発行し忘れた場合は悲惨なことになります.
SSD内の転送はそうですね。一方で、SSDコントローラとSATAホストコントローラ間の転送を考えると(プリフェッチは論理セクタなので)デフラグの効果はあると思います。コピーバックの話はリードディスターブ回避の保険なので、Secure Erase してからコピーバックしているものの、パフォーマンス的にはマイナスでしょうね。でも、書き換え回数ばかりが騒がれてSSDのデータ保持期間のスペックが明示されていないので、消えるよりはマシと考えざるを得ない気がします。
でSSDでも断片数が10万を超えてるようなファイルはデフラグしたくなる
年季の入った人には「何をいまさら・・・」なのだが、昨日今日はじめた輩には新鮮なんだよ。次にこの話題が上がるのは2,3年後かな。
なんでこんなしょうもないタレコミをストーリー起こしてまで採用したのかと首を傾げていたが、昨日今日はじめた輩であるhylomにとっては新鮮だったってことか。
しょうもないと思うならスルーすればいいだけなのに。
ソフトやOS, メディアによって全部違ってくるんだから、ホントは誰にとっても有益だろ。しょうもないと思うのは世界が狭いだけ。オレも色々な状況でのコメントを読む前はそう思ったけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
何をいまさら・・・ (スコア:1)
そりゃ当然だろ。むしろ、大量にアクセスするが効率化された結果寿命が増える、とかの調査結果が出たならニュースバリューがあるが。
寿命が減るのはいちいち言われないとわからないのかよ!レベルの話として、いやそもそもSSDでデフラグって、なんか間違ってなくね?ディスクと違って順番に読み込む必要がないんだから、そもそもデフラグなんてほぼいらないような・・・
Re:何をいまさら・・・ (スコア:2)
元記事を見ると
と書かれてて、元記事自体がエビデンスなしの一般論(HDD取り扱っていないPCパーツ代理店のお話)にすぎない様です。
よく読むと「デフラグで寿命縮むかもしれません。でも一番影響するのは熱ですよ」と書かれています。
デフラグが必要かどうかはユースケースに大きく依存しますよね。
空き容量が2割を切るような使い方をしていると断片化しやすいです。
NTFSに代表されるような最近のファイルシステムはなるべく連続領域を割り当てるように設計されてますが、
空き容量が少なくなるとそもそも空き連続領域が存在しない、なんてことになります。
確かに過度な断片化は性能に悪影響を及ぼしますが、そもそも多くのI/O単位はそんなに大きくないので
数十MB以上に連続してファイルが配置されていることが重要だとは思いません。
Windows 8 では SSD にたいして「最適化」すると、TRIMを全空き領域に対して発行しますね。
そもそも削除するときにTRIMしているような気がするんですが、これは効果あるんでしょうか。
Re:何をいまさら・・・ (スコア:2)
リンクスインターナショナルはHDD製品の取り扱いをしておらず、特定のHDDメーカーから特別な情報協力等は受けていない、同社独自の見解となります。
と書かれてて、元記事自体がエビデンスなしの一般論(HDD取り扱っていないPCパーツ代理店のお話)にすぎない様です。
エビデンスについての記述が無いのは確かなんだけど、記事の引用部分はエビデンスの有無について言っているのではなく、ハードディスク製造者に有利な発言をしているわけではない、と言う主張なんだと思うけど。
デフラグが必要かどうかは
<<略>>
数十MB以上に連続してファイルが配置されていることが重要だとは思いません。
それってエビデンスは…
Re:何をいまさら・・・ (スコア:1)
>でも一番影響するのは熱ですよ
もともと80GB/SATAしか無かったノートパソコンのHDDをホップステップジャンプで750GB/SATA2まで増量したらHDDが飛びまくる。
保証期間なので返送して同じ物が送られてきてはまた飛ぶ。
3回飛んだので「同等の別な製品に換えてくれ」とメールで送っても無視された。
送られてきたものはファン付きの外付けケースにしなきゃ使えないのかなぁ。
Re:何をいまさら・・・ (スコア:2, 興味深い)
アンペア数大丈夫?
ノートPCの場合、電源設計がシビア過ぎて、安易にHDD載せ換えると、電流が足りなくて飛ぶよ。
元々載っていたHDDの低格消費電流と比べてみては。
私の経験だと、一般に省電力と思いこまれているSSDだけど、最近の高速タイプは意外と電流食いで、古いノートPCに載らなかった事があるよ。
Re: (スコア:0)
Re: (スコア:0)
> NTFSに代表されるような最近のファイルシステムはなるべく連続領域を割り当てるように設計されてますが、
うちのVistaや7や8はそんな動きをしないけど。
最初にデフラグしてファイルをディスクの先頭に詰めておき、
その中のファイルを削除して穴ができると、次に大きなファイルを
書き込むときにはファイルの削除跡の小さな穴から埋めていくため、
ほとんどの場合断片化するよ。
ちなみにディスクの使用量は30%以下ね。
# しょっちゅうDiskeeperやO&O defragでファイル配置を見ていると、
# 広大な空き領域から使っていくことも確かにあるが、
# NTFSが必ず連続領域を優先的に使うという感じは全くしない。
Re: (スコア:0)
ファイルの種類で割り当て方を変えてるとかないのかな。
シーケンシャルにしか利用しないファイルなら多少断片化してても問題なし、とか。
ランダムアクセスするファイルなら(先読み分のキャッシュなどで)連続してる方が望ましい、とか。
Re: (スコア:0)
ファイルシステムはそんな用途は分からないから無理なんじゃないかなー。
Re: (スコア:0)
拡張子で判別とか、利用状況の統計とるとか。
Re: (スコア:0)
大きなファイルを入れるドライブはクラスタサイズを大きく設定してますが、それでもディスクの断片化の影響は実感できますね。
時々、他のドライブに移動する擬似的なデフラグ操作をしたりします。
Re: (スコア:0)
>NTFSに代表されるような最近のファイルシステムはなるべく連続領域を
>割り当てるように設計されてますが、空き容量が少なくなるとそもそも
>空き連続領域が存在しない、なんてことになります。
XPですがエクスプローラーでファイルコピーするとおおむね連続領域にコピーされる
ことに最近気が付きまして、(特に巨大ファイルを)あえてコピーして元ファイルを消すことで
ピンポイント簡易デフラグしています。(対象ファイルは勘で選ぶ、「分析」で確認しながら)
でも通常の open()->write() でファイルを作るもの (たとえば zip.exe とか)は open() 時に
最終ファイル長がわからないからなのか、ファイル長がでかくなると当然断片化するのです。
これは open() 時に長さをヒントとして与えられるようは特別な open() 相当のシステム
コールがあるのか、エクスプローラーのファイルコピー機能の努力の結果なんでしょうか?
Re:何をいまさら・・・ (スコア:1)
いや、もろに CopyFile http://msdn.microsoft.com/ja-jp/library/cc429185.aspx [microsoft.com] とか CopyFileEx http://msdn.microsoft.com/ja-jp/library/cc429187.aspx [microsoft.com] とかいうそのものずばりの API 関数があるのですが。
Re: (スコア:0)
Cドライブが余りまくっていてもWindowsUpdateでボロボロになるのは
最初に個々のファイルサイズが分からないということなのかな?
Re: (スコア:0)
Re: (スコア:0)
SetFilePointerとSetEndOfFileであらかじめファイルサイズを拡張しておくと連続領域を確保できるらしい
Re: (スコア:0)
デフラグは寿命を縮める、熱はもっと縮めるってとっくの昔にGoogleが発表してましたよね?
Re: (スコア:0)
あれって、ディスクの故障とデフラグの因果性を、ディスクをばらして故障原因まで突き止めたんだっけ?
# 個人的には、単なる経験則を発表しただけで、信用に値しないと考えている
Re:何をいまさら・・・ (スコア:1)
そんな都市伝説みたいな話、信じてる人まだいるんだ。
デフラグのやりすぎで壊れるなら、やらずに非効率なアクセスを続ける方が圧倒的に寿命縮むだろ。
あほくさ。
Re: (スコア:0)
若いなぁ
Re: (スコア:0)
断片化してるファイルが頻繁に使われるとは限らない。
滅多に使わないファイルなら断片化してようがたいして影響はない。
そして、昨今のファイルシステムは、ファイルオープン時に断片数が既定値を超えていたら自動でデフラグするんじゃないの? 全体を一括でデフラグするよりは空き領域に対しての効果は落ちるが(空き領域の連続化)、十分な空き領域を確保した上での運用であれば、これでも十分だと思う。
Re: (スコア:0)
滅多に使われないファイルなら一度デフラグしたら
以後はいくらデフラグをスタートさせても移動は発生しない。
そして、全体を一括でデフラグしようが、ちょこちょこやろうが、寿命にはなんの違いもない。
だいたいW/Rの回数やシーク量と寿命にはほとんど相関無いし。
Re: (スコア:0)
だいたいW/Rの回数やシーク量と寿命にはほとんど相関無いし。
そうなの?Winnyが盛んだった頃、そのあまりのHDD酷使っぷりに、金子氏はHDDメーカーの回し者だのと揶揄されてた記憶があるのだけれど・・・あれはディスクスペース的な意味だけ?
Re: (スコア:0)
HDD前方に空き容量ができた時に、既に整列しているファイルでも詰めようとして移動することがあるけれど?
Re: (スコア:0)
移動しようとしているファイルより大きな連続領域が
先頭方向にあるときだけ移動するDiskeeper系の
アルゴリズムですね。
Re: (スコア:0)
「やりすぎ」の意味、ご存じですか?
必要最低限のデフラグまでは誰も否定していませんよ。
Re:何をいまさら・・・ (スコア:1)
Re:何をいまさら・・・ (スコア:1)
デフラグのやり過ぎが寿命を縮めるなんて、専門家でなくてもすぐに予想できると思う。
そこで問題になるなのは「どのくらいの頻度でやるのが『最適』なのか?」とか
「どのくらいやり過ぎたら、(たとえば)寿命が半分になるのか?」とかじゃね?
Re: (スコア:0)
ねぇねぇ、なんで寿命が縮むの?
磁性体やヘッドがすり減るの?
Re: (スコア:0)
ヘッドの軸受け部分に負荷がかかるだろうが。
ヘッドの移動量が増えればそれだけ摩耗も早くなる。
Re: (スコア:0)
Re: (スコア:0)
やりすぎればの話でしょ。
全体のデフラグでは空き領域を連続化するために断片化していないファイルの移動も発生するんだから。
ただ詰めるだけじゃなく、ソフトによってはファイルの種類によって、ディスクの内周に集めたり
外周にどかしたりもしてるんだから。最近のは知らんけど、旧MacOSの頃のNortonSpeedDiskとか。
DiskWarriorはどうだったかな。
G3Mac+MacOSXの頃「8GBの壁」問題で、先頭から8GBの領域内にシステムファイルが入ってないと
起動しないなんてのがあって、SpeedDiskで集めてなんとか起動させたってことがあった。
Re: (スコア:0)
家庭用なら、デフラグする頻度を上げれば1回のデフラグで移動するデータも大したことがなく、
軸受けの摩耗なんか誤差だよ。
Re:何をいまさら・・・ (スコア:1)
寿命が減るのはいちいち言われないとわからないのかよ!レベルの話として、いやそもそもSSDでデフラグって、なんか間違ってなくね?ディスクと違って順番に読み込む必要がないんだから、そもそもデフラグなんてほぼいらないような・・・
フラッシュメモリデバイスの場合は,極端に寿命が縮まるから デフラグしちゃダメよ! というのが一般論だと思ってたんですが,違うんですかね?:
SSDだと,効果がない じゃなくて,むしろ害悪 じゃないかと.
USBメモリなんかに デフラグかけちゃダメ,と言われてたのと同じで.
ウェアレベリングで 書き込みが極端に集中してバカになる箇所が出ないよう 大体平滑化してるのに,わざわざデフラグで偏らせるなんて!
って理解してました.
Re:何をいまさら・・・ (スコア:1)
ファイルシステムのメタデータは、デフラグする方が好ましい。
これは、メタデータ自身がキャッシュされるんで、カーネルの消費メモリ削減になって、システム全体が若干高速になるから。
あと、SSDなら、ブロック範囲に収まるデータは、一ブロックに集約するのが良いが、それ以前に、良く書き換えるファイルと書き換えないファイルを同一ブロックに入れない様にする事が肝要。
でも、SSD内の論理-物理変換方式は、各社研究中の流動的且つ重要な機密情報なんで、サードパーティーツールで最適化する事は実質不可能。
でも、断片化してるとメタデータが増えているのは確実だから、SSDでもデフラグは無意味じゃない。
如何に優秀な方式でも、余分なデータが無い方が確実に効率を上げられるからね。
ただ、SSDの場合は、頻度と積極性は下げる方が良い。
つまり、極端にフラグメントが進んでる場所だけを必要最小限の移動でデフラグする方式がベストになる。
具体的には、解析にやや時間が掛かるが、実行自体は瞬時に終わる物が良いって事になる。
-- Buy It When You Found It --
Re: (スコア:0)
ところで、ちょっと疑問なのですが。
SSDで、ファイルの領域が連続しているとデフラグソフトで表示されていたときでも、内部のメモリのアドレスとして必ずしも連続していないのでは?
メモリの使用頻度の平準化とか不具合部分の回避とかするんですよねぇ?
ちがうの?
SSDの論理と物理 (スコア:1)
SSD内の論理-物理変換に粒度の制限がある。
ぶっちゃけ、セクタ単位での個別物理変換テーブルなんて持たせたら、容量の無駄遣い。
更に、論物変換データ自体もフラッシュに格納される事を忘れない様に。
論理-物理変換の変更量が増えると、やはり寿命を縮める事になる。
なので、論理側で不変領域を一箇所に集中させる(変動領域を一箇所に集中させるのと等価)と、論物変換の管理領域の更新量が減って、性能と寿命が両方向上する訳。
-- Buy It When You Found It --
Re: (スコア:0)
SSDでは論理セクタと Flash のアドレスは相関が弱いので、デフラグしても偏らせることにはならないと思います。もちろん寿命の観点からはデフラグしない方が良いのでしょうが、パフォーマンスという観点ではプリフェッチやリードアヘッドの効果はデフラグした方が高くなると考えているのですが違いますかね。
別の視点ですがリードディスターブが怖いので、SSDは年に一回程度全部HDDにコピーして、SSDにコピーバックしてます。
Re: (スコア:0)
SSDの論理セクタと Flash のアドレスは相関が弱い,とおっしゃっているのに
パフォーマンスという観点ではデフラグに効果がある,とか
> SSDは年に一回程度全部HDDにコピーして、SSDにコピーバックしてます。
というのは矛盾しています.
特に後者のコピーバックは,注意しないと Flash側(アドレス空間)が断片化し,パフォーマンスが大幅に低下します.特に, TRIMコマンドを発行し忘れた場合は悲惨なことになります.
Re: (スコア:0)
SSD内の転送はそうですね。一方で、SSDコントローラとSATAホストコントローラ間の転送を考えると(プリフェッチは論理セクタなので)デフラグの効果はあると思います。
コピーバックの話はリードディスターブ回避の保険なので、Secure Erase してからコピーバックしているものの、パフォーマンス的にはマイナスでしょうね。
でも、書き換え回数ばかりが騒がれてSSDのデータ保持期間のスペックが明示されていないので、消えるよりはマシと考えざるを得ない気がします。
Re: (スコア:0)
でSSDでも断片数が10万を超えてるようなファイルはデフラグしたくなる
Re: (スコア:0)
年季の入った人には「何をいまさら・・・」なのだが、昨日今日はじめた輩には新鮮なんだよ。
次にこの話題が上がるのは2,3年後かな。
Re: (スコア:0)
なんでこんなしょうもないタレコミをストーリー起こしてまで採用したのかと首を傾げていたが、
昨日今日はじめた輩であるhylomにとっては新鮮だったってことか。
Re:何をいまさら・・・ (スコア:1)
しょうもないと思うならスルーすればいいだけなのに。
Re:何をいまさら・・・ (スコア:1)
ソフトやOS, メディアによって全部違ってくるんだから、ホントは誰にとっても有益だろ。
しょうもないと思うのは世界が狭いだけ。
オレも色々な状況でのコメントを読む前はそう思ったけどね。
the.ACount