SSDへの三大禁忌
ちょっと大げさでしたかな。 ギガファイルコピー、デフラグ、そしてベンチマーク。 前者2つも数値を見てみたくなりましたのでトライ。 ◆ギガファイルコピー メイン機からLAN経由でmpegファイルを SK3WX06L のDドライブにコピーしました。 ファイル数は1本、ファイルサイズは 1,486,827,524 バイトです。
(2)−(1) リードセクタカウント:199,750,176 − 199,712,137 = 38,039 ライトセクタカウント:177,374,099 − 174,439,337 = 2,934,762 FAT領域へのアクセスもありますが、ファイルサイズに比べたら僅かな量です。 ライトセクタカウントから、ファイルサイズ÷ライトセクタ数=507≒512バイト/セクタ、という数字が導けます。 ◆ギガファイルムーブ 上でコピーしたDドライブのmpegファイルを、Cドライブに移動しました。
(3)−(2) リードセクタカウント:202,665,198 − 199,750,176 = 2,915,022 ライトセクタカウント:180,285,030 − 177,374,099 = 2,910,931 こちらの方が一致がよいですね。 ファイルサイズ÷ライトセクタ数=511≒512バイト/セクタ。 ネットワークからファイルコピーするときには一部がディスク上に書かれる時があるかもしれません。 そしてもう1つ注目すべきこと。 ライトセクタカウントが「1ファイル分」だということです。 ファイルの移動は、実際にはファイルの複写と削除の組合せ処理です。 『ファイルをただ削除しただけでは、まだディスク上のデータは完全に消去されていない』 とは散々言い尽くされていることですが、なかなか目で見て確認できないのでピンと来ない方もおられたかもしれません。 ドライブ間のファイル移動で、移動前のファイルが完全に削除(内容消去)されるには、少なくとも2ファイル分のライトアクセスが必要です。移動先ドライブにファイルを作成した後、移動前ドライブでそのファイルが使っていたディスク領域を無意味なデータで上書きしなければなりませんから。 上でカウントされた1ファイル分は、明らかに移動先のファイル作成分のみのカウント。 これ以上分かり易い証明は無いのではないでしょうか。 ◆デフラグ Cドライブのデフラグを実施しました。
Cドライブには 23,805本、6,356,927,833 バイトのファイルがあります。 全部がフラグメントを起こしているわけではありませんが・・・
最適化しろ、とは言ってきてます(汗 ようし、やってやるぜ!
約40分くらいかかって終わりました。 そういえば、exFAT のドライブ(D)が挙がってきていません。デフラグ対象外なんでしょうか。コマンドラインからは実行可能かもしれませんが。
(4)−(3) リードセクタカウント:209,785,111 − 202,665,198 = 7,119,913 ライトセクタカウント:187,519,932 − 180,285,030 = 7,234,902 リードライトほぼ同数で満遍なく読み書きしてます。当たり前といえばそれまでですが。 フラグメントの状態、対象ファイル数など、変動条件が多いので此の一例で全てを語るには乱暴ですが。 少なくともこれだけは言えるでしょう。 SSD へのデフラグは ベンチマーク実行時並みに負担が大きいです。 可能な限り実行すべきでない のは本当です。 ◆仕上げにベンチマーク やらないとドライブの状態を測れないので(涙
左が今回、右が2010/3/9のときのベンチマーク結果。 やはり少し遅くなってきましたよ。体感的には大して遅さは気になりませんが。
(5)−(4) リードセクタカウント:220,397,427 − 209,785,111 = 10,612,316 ライトセクタカウント:192,500,071 − 187,519,932 = 4,980,139 ライトカウントが前回 よりかなり減りました。 リードカウントはほぼ同じなので、Crystal Disk Mark がベンチ用ファイルを作る時のパターンが1つではなかったりするのかしら。それにしても約150万カウントも書き込み量に差があるとは?? とはいえベンチばかりを試すわけにもいきません。少し様子見ですね。 ※3/19 22:45 追記 ライトセクタカウントだけ大幅な差異が発生した原因ですが、前回のベンチマーク中にはスワップが発生した、と仮定したら、あり得そうな気がしてきました。 こういうことがありますので、本来実験は同じ手順を数回繰り返したのち結果の平均を取るものですが、試す物がSDなだけに実験回数は1回とさせてもらってます。
この記事へのコメントは以下のフォームからどうぞ