断片化の激しいデータをFastCopyでコピーしたときの状態

[jmurom...@gmail.com]

作者さま、いつもFastCopyを重宝させていただいております。
質問なのですが、断片化の激しいデータを、"ディスクの管理"でフォーマットしたばかりのハードディスクに
FastCopyでコピーしたのですが、コピーされたデータはデフラグされた状態になると想定しておりました。
しかし、"Auslogics Disk Defrag"というソフトでデフラグをかけてみたところ、かなり断片化してました。
これは速度とのトレードオフと考えてよろしいのでしょうか、よろしくお願いいたします。

[Hiroaki SHIROUZU]

「かなり断片化」とのことですが、より正確な情報をいただけますか？

１．FastCopyのバージョン、OSバージョン

２．（コピー先の）圧縮属性の有無

３．全ファイル数と断片化していたファイル数

４．上位10ファイル程度の、断片化していたファイルのサイズと断片化数のリスト

なお、コピー元ファイルの断片化の有無が、コピー先に影響することはありません。

FastCopyでは１ファイルを書き込む前に、必要サイズ領域の確保を行った後に書き込みます。

領域確保で連続した領域が割り当てあられるかは、NTFS/OS側の空き容量＆アロケーションポリシー次第です。

（ただ、基本的には空きが十分あれば連続することが多い）

速度とのトレードオフという話はありません。

（コピー先に）圧縮属性が付いている場合は、どういう方法を使っても（デフラグする以外に）断片化は避けられません。

[jmurom...@gmail.com]

SHIROUZUさま、返信ありがとうございます。

情報不足で申し訳ないです。
CenturyのCROSU3というUSBリムーバルスタンドに
1TBの3.5インチHDD(今回のコピー先)を挿しています。

タスクトレーのエクスプローラーアイコンから"MassStorage Devieceの取り出し"をクリックすると、
F:\extend\rmmetadata
など４つくらいのファイルにロックがかかっていて切断できまんでした。
ネットで調べると、「ドライブのMFTファイルが断片化しているのが原因」というのが見つかりましたので、
とりあえず、HDDをフォーマットしてFastCopyでコピーしたら解消されるだろうと思い、デフラグツールで
分析しましたら、断片化が進んでいたのに気付いた次第です。

ご質問の点ですが、

１．FastCopyのバージョン、OSバージョン

FastCopy 64bit ver3.24
Windows 10 64bit Pro

２．（コピー先の）圧縮属性の有無

フォーマットした直後で、ボリュームのプロパティで確認すると、
圧縮のところはチェックオフになっています。これで圧縮属性はないということでよろしいでしょうか。

３．全ファイル数と断片化していたファイル数
４．上位10ファイル程度の、断片化していたファイルのサイズと断片化数のリスト

FastCopyでコピーした直後、デフラグツールのよくあるブロック崩しゲームのようなイメージで確認しただけですが、
9割方、断片化しているような感じでした。ツールが出力したHTMLのレポートがあったのですが、どうしても１回目の
実行結果が見つかりませんでした。２回目のものをみると以下のようでした。

ディスク サイズ     0.91 TB
空き領域のサイズ     488.00 GB
クラスター     244189951
クラスターあたりのセクター数     8
セクターあたりのバイト数     512
最適化を開始     2016/10/22 9:13:34
最適化の完了     2016/10/22 12:30:31
経過時間     03:16:56
ファイルの合計数     1340711
ディレクトリの総数     7775
断片化したファイル     5602
デフラグされたファイル     5602
最適化されたファイル     8716
スキップされたファイル     0
前の断片化     0.06% |
後の断片化     0.00%


>NTFS/OS側の空き容量＆アロケーションポリシー次第です。

まだ購入して一週間ほどのデスクトップで、デフォルトの設定は変更されていないと思います。

>（ただ、基本的には空きが十分あれば連続することが多い）

コピー先がフォーマット直後でアロケーションポリシーがデフォルトの設定ですと、FastCopyでもOS標準のコマンドでも
コピーすればコピー元の断片化が解消されて、デフラグと同じ効果が望めるというのは、間違いないということでよろしいでしょうか。

[o o]

　FastCopy の挙動の話と言うより、OS（NTFS)の話っぽいので横から失礼します。

　NTFSは、小さなファイルはMFT内にデータも格納したり（プロパティでディスク上のサイズが 0バイトと表示されるファイルがそうです）、大きなファイルをブロック単位で領域を確保し、その領域へのインデックス情報をMFTに格納・・・・・・に加えて、ファイルシステムの破損からの保護の為にジャーナルを更新しながら行っていますので、どうしてもフラグメントは発生するはずです。

参考（古いですがNTFSであれば8.1以降でも大きな違いはありません）

http://www.atmarkit.co.jp/fwin2k/experiments/defragment/defragment_column.html

[Hiroaki SHIROUZU]

>圧縮のところはチェックオフになっています。これで圧縮属性はないということでよろしいでしょうか。

NTFS圧縮はディレクトリ＆ファイル単位で指定できるため、それだけでは不明ですが、フォーマットして以降 FastCopy しか使っていないのであれば、OFFのままの可能性が高そうですね。

>実行結果が見つかりませんでした。２回目のものをみると以下のようでした。

2回デフラグを行ったということでしょうか？

（最適化前のフラグメント率は0.06%であり、ほとんどフラグメントなしに見えますので）

再度、フォーマット＆FastCopyでコピーして、「Auslogics Disk Defrag」にて「分析」を行い、「ファイル」タブの情報を教えて頂ければ、もう少し何かが言えるかもしれません。

>コピー先がフォーマット直後でアロケーションポリシーがデフォルトの設定ですと、FastCopyでもOS標準のコマンドでも

>コピーすればコピー元の断片化が解消されて、デフラグと同じ効果が望めるというのは、間違いないということでよろしいでしょうか。

標準コマンドに関しては不明ですが、FastCopyに関しては「コピー先ファイル」に関しては、概ねそうなります。

（ただし前に書いた通り、FastCopy側のファイスサイズ分の領域確保要求に対して、OS/ファイルシステム側が連続した領域を割り付けるかどうか、に依存します）

[jmurom...@gmail.com]

もう一度、コピー先のドライブをフォーマットして、再びFastCopyでコピーした直後、auslogics disk defrag で分析しました。
スクリーンショットです。

https://drive.google.com/drive/folders/0B77nAhYhSxSedFJlWG5CV3N3R2c

見た通り、真っ赤でこれは右下のカラーパレットのようのところにカーソルをもっていくと、
 "断片化しています" というポップアップが確かにでます。
ここで、私はほとんど断片化していると早合点しましたが、左上の方をよく見ると、 "断片化しています"(隠れてますが)が
0%(おそらく四捨五入して)とありました。
実際にデフラグをかけると、3時間ほどかかりました。結果、

ディスク サイズ	0.91 TB
空き領域のサイズ	487.99 GB

クラスター	244189951
クラスターあたりのセクター数	8
セクターあたりのバイト数	512

最適化を開始	2016/10/23 8:46:47
最適化の完了	2016/10/23 12:18:46
経過時間	03:31:59
ファイルの合計数	1340711
ディレクトリの総数	7775
断片化したファイル	6495
デフラグされたファイル	6495
最適化されたファイル	9600
スキップされたファイル	0
前の断片化	0.07% |
後の断片化	0.00%

どう解釈していいのか、ちょっとわかりません。。

[jmurom...@gmail.com]

上記の画像へのリンクは勝手知らないGoogleドライブで初めて使って作りました。もし閲覧できないようであれば仰ってください。

[Hiroaki SHIROUZU]

再テストありがとうございました。

１．約134万ファイル中、断片化は6千5百ファイルだった、あたりの意味でしょうね。（追記参照）

　（ただし、これだと 0.7% ではなく 0.4% になるため、ディレクトリや「最適化されたファイル（何をやっているのか知りませんが）」もカウントされているのかもしれません）

２．総クラスタは244,189,951個あるわけですが、多すぎてビットマップには表すことが出来ないため、4000～5000クラスタをまとめて1つの小さな□として表現しているわけです。そして、おそらく、4000～5000クラスタに1つでもフラグメントがあれば、赤く表示しているのだと思います。

というわけで、実際には 0.4% or 0.7%のフラグメントだったとしても、見た目全体がフラグメントのように見えてしまった、という話ではと思います。

ちなみに、もう少し詳細として見たかったのは、

　>「Auslogics Disk Defrag」にて「分析」を行い、「ファイル」タブの情報、

に出てくる具体的なファイル情報でした。

（どういったサイズのファイルがいくつの断片になっているかが判ります）

少し疑問に思っているのは、フラグメント、と表示しているものの大半が、実は「ディレクトリ」ではないかという疑いです。

（この場合、ファイルをコピーする前に、空のファイルをすべて作るような動作をしない限り、（そのディレクトリは）フラグメントと表示されるのではと思います）

追記：0.7%ではなく0.07% でしたね…一桁違いますね、これ。より正確な意味を知りたいところです。その意味でも、ファイルタブで表示されるファイル毎のサイズ＆フラグメント数のリストが見てみたいところでした。

[jmurom...@gmail.com]

お付き合いいただき恐縮です。

> そして、おそらく、4000～5000クラスタに1つでもフラグメントがあれば、赤く表示しているのだと思います。

なるほど、それで合点がいきます。

>「Auslogics Disk Defrag」にて「分析」を行い、「ファイル」タブの情報、に出てくる具体的なファイル情報でした。

ご参考になるかわかりませんが、２回目の分析です。
https://drive.google.com/drive/folders/0B77nAhYhSxSedFJlWG5CV3N3R2c

初日のあいまいな記憶ではたしか、このファイルタブのところにはディレクトリがずらっと並んでいた気がいたします。

>この場合、ファイルをコピーする前に、空のファイルをすべて作るような動作をしない限り、（そのディレクトリは）フラグメントと表示されるのではと思います

それほど頻繁にアクセスするわけデータ(今回がそうなのですが)ではないものは、末端の方のフォルダをzip化しておけば、とりあえずフラグメントは起こらないということでしょうか。

[Hiroaki SHIROUZU]

>初日のあいまいな記憶ではたしか、このファイルタブのところにはディレクトリがずらっと並んでいた気がいたします。

ということであれば、また総ディレクトリ数とフラグメント数が近いこと、

>ディレクトリの総数 7775

>断片化したファイル 6495

から、やはりディレクトリのフラグメントが表示の原因、ということになりそうです。

（比較的、沢山のファイルが入ったディレクトリが多め、という感じでしょうか？ 平均で1340711/7775=171ファイル/ディレクトリ程度のようですが）

おそらく、世の中のファイルコピーソフトでも、（ディレクトリのフラグメントを防ぐ唯一の方法ではと思いますが）全てのディレクトリと空ファイルを先にすべて作ってから実データコピーを始める、といったものは少ないのではと思います。

一般に、ディレクトリファイルはもともと、巨大なものは少ないですし、NTFSの場合、多少エントリが多くともB+Treeで比較的高速探索してくれますし、最初のコピー以降に差分コピーや新規ファイルを作成すれば追加でエントリが作られて、ディレクトリフラグメントの原因になりえるため、気にしても仕方がない、という面もあります。

>それほど頻繁にアクセスするわけデータ(今回がそうなのですが)ではないものは、末端の方のフォルダをzip化しておけば、とりあえずフラグメントは起こらないということでしょうか。

そうですね。

（ただ、先に書いた通り、ディレクトリに関しては、そこまで気にするレベルでもない気はします）

[jmurom...@gmail.com]

結論としましては、FastCopyでデフラグは起きていなかった、デフラグツールの分析のイメージ(ブロック崩しのようなもの)だけで
早合点しておりました(パーセントの数字を見ていなかった)。

あと、G:\exetend\ ～～のようなファイル４つほどにロックがかかって、ハードディスクが切断できなかった問題ですが、別のドライブでも
同様のことが起こり、数分後には問題なく切断できました。
これは、 o o様が指摘されておられるように、OSがNTFSを管理するためロックがかかっていたためだと判断いたしました。
切断できるかどうかは、OS依存の問題ということでしょうか。

お二方、ありがとうございました。

[o o]

　FastCopyの半紙から外れてしまいますが、OSコマンドで ROBOCOPY があります。

※もし、実際に実行される際には、十分にご注意ください。

　ROBOCOPY では、ｌコマンドラインオプションで /CREATE というのがあり、多数のフォルダ／ファイルの書き込みがある場合、極力フラグメントを防ぎたい場合に、

　最初に、 /CREATE を付け実行し、ディレクトリと 0バイトのファイルを作成

　もう一度 /CREATE を付けずに実行

により、COPY時のフラグメント化を極力防ぐ方法があります。

※ROBOCOPYはバッチ処理でのフォルダ同期では、広く使用されていると思いますが、気軽に実行するコマンドではありませんので、十分にご注意ください。

[jmurom...@gmail.com]

    o o様、鋭いご指摘、ありがとうございます。
ROBOCOPYの /CREATEオプションは今回の話にも関係が深いところですね。
また、機会のあるときに、ROBOCOPYのそのオプションと、

http://www.se-support.com/server/fileserver-copy.html

FastCopyのパフォーマンスで、"合わせ技の一本"、みたいなことをためしてみようと思います。

[mail...@gmail.com]

横入りですが提案です。

XP以降のOSには
fsutil.exe が存在し、

fsutil file createnew ＜ファイル名＞ ＜サイズ＞

にて、領域の予約(実際にはデータは書き込まれない)ができます。
これを利用することで、ファイルコピー時の断片化を極力防ぐことが可能です。
また、ファイルのコピー中に容量が無くなったなんて事もなくなります。

※すでにファイルが存在する場合はエラー

実装する場合は、
コピー処理開始直前に実行
ファイル単位で実行(デフォルト)
ですかね。

無効はデメリットしかないので意味ないかと。

[Hiroaki SHIROUZU]

既に、FastCopyでは事前の領域確保動作は行っています。

SetFilePointer + SetEndOfFile という方法ですが。

ただ、このやり方は（NTFS/FATでない）Linux系NASだとsparse file になって本来の効果は出ない問題はあります。

SetFileValidDataだとその場合も大丈夫になりますが、

１．Admin権限が必要なこと

２．このAPIがlinux-smb側ではfallocate(2)として動作する場合、（xfs や ext4 なら良いものの）ext3など非extent系fsの場合、延々0書き込みして領域確保する動作に

あたりの検証と落としどころが必要になります。