Windows Server 2008 システムに、きれいにフォーマットされた 8TB NTFS ドライブがあります。並列 robocopy を使用して、6TB のドキュメントをそのドライブにコピーしています。多数の小さなファイル (約 1 億 5000 万) があります。これらは、いくつかのディレクトリに分散しています。全体的に、ファイルは大きすぎて MFT にインラインで収まりません。コピーの約 4 分の 3 が経過した時点で、コピーのパフォーマンスが大幅に低下しました。
procmon を見ると、ボトルネックとなっているのは MFT の拡張のようです。各 robocopy プロセスが CreateFile に約 3.5 秒かかっていることがわかります。最初の呼び出しが発行された直後に、$Mft で IRP_MJ_READ が END OF FILE を返しているのがわかります。CreateFile が成功する直前に、別の $Mft 読み取りで SUCCESS が返されているのがわかります。
関連情報: MFT はすでに 115 GB と大きくなっています。ただし、これはドライブの 12.5% というデフォルトの予約よりはるかに少ないです。MFT は急速に断片化しています。Contig.exe は 100,000 個のフラグメントを報告します。新しいフラグメントが頻繁に追加されています (1 秒あたり複数回)。
私の質問：
MFT をより大きなチャンクで拡張できますか?
予約サイズをはるかに下回っているのに、MFT が断片化されているのはなぜか、気になります。MFT が予約サイズから開始されないことはわかっていますが、連続して予約サイズまで拡張できないのであれば、予約の意味は何でしょうか。ドライブにはまだ 33% の空き領域があるので、通常のデータはまだ予約を使用していないはずです。
アップデート fsutil fsinfo ntfsinfo は、MFT に関する次の情報を提供します。
Mft Valid Data Length: 0x0000001ca90c0000
Mft Start Lcn: 0x0000000000000000
Mft Zone Start: 0x000000003c828360
Mft Zone End: 0x000000003c828380
ゾーンが非常に小さいのですが、これは正常ですか?
答え1
SysInternals contig の最新バージョンでは、空き領域を報告できます。
contig64 -f
それが示している：
Free cluster space : 2,838,753,701,888 bytes
Free space fragments : 89,747,382 frags
Largest free space block : 90,112 bytes
これですべてが説明できたと思います。2TB/8TB (25%) 以上の空き容量があるにもかかわらず、空き領域は完全に断片化されています。これは MFT の増加に影響し、この段階ではデフラグ オプションを検討する以外にできることは何もありません。
そもそもこの状況を回避する方法があったかどうかはわかりません。このレベルの断片化を起こさずに、既知のサイズのファイルを新しくフォーマットされたディスクに並行してコピーできるはずです。