/ j Robocopyオプションの長所と短所はありますか（バッファリングされないコピー）
Robocopyには/J大きなファイルをコピーする場合に推奨されるコマンドラインオプション（バッファなしのI/Oを使用してコピーします）。
（もしあれば）どんな欠点がありますか？これがデフォルトで有効になっていない理由は何ですか？ （それが私にそこにマイナス面があるかもしれないと思った理由です。）
すばらしい質問です。
バッファなしI/Oは、ソースの場所から宛先の場所への単純なファイルコピーです。バッファI/Oは、仮想メモリの領域である filesystem cache にファイルをコピーすることにより、同じファイルの将来の読み取り（および書き込み）を最適化するために単純なコピーを拡張します。バッファリングされたI/Oは、メモリにファイルをコピーする必要があるため、最初にファイルにアクセスするときにパフォーマンスが低下します。ただし、メモリアクセスはディスクアクセスよりも高速であるため、その後のファイルアクセスも高速になります。オペレーティングシステムは、ディスクへのファイルの書き込みの同期を処理し、読み取りはメモリから直接プルできます。
使用上の注意では、バッファI/Oに対して大きなファイルについて言及しています。
- 初期費用は高くつきます。バッファードI/Oによるパフォーマンスの低下は、大きなファイルの場合は大幅に低下します。
- 見返りはほとんどありません。比較的大きなメモリがない限り、大きなファイルブロックは非常に長い間キャッシュにとどまる傾向はありません。ファイルサイズ。
- ディスクI/Oを回避できない場合があります。大きなファイルデータブロックの読み取りと書き込みを行うと、ディスクI/Oが必要になる可能性が高くなります。
- おそらくとにかくバッファリングする必要はありません。大きなファイルは、小さなファイルよりも実際にアクセスされる頻度が低くなる傾向があります。
したがって、トレードオフがありますが、どちらが適切かは、特定のケースによって異なります。大量のファイルを圧縮して、Zipをバックアップターゲットに送信する場合は、バッファなしの方法が適しています。変更されたばかりの一連のファイルをコピーしていますか？バッファリングされた方が速いはずです。
最後に、ファイルサイズは、バッファリングと非バッファリングを決定する唯一の要素ではないことに注意してください。他のキャッシュと同様に、ファイルシステムキャッシュは高速ですが、背後にあるソースよりも小さくなります。新しいアイテムのためのスペースを作るためにアイテムをいつ立ち退かせるかを管理する キャッシュ置換戦略 が必要です。頻繁にアクセスされるアイテムが削除されると、メリットが失われます。たとえば、ユーザーのホームディレクトリを別の場所に日中同期している場合（つまり、ユーザーがファイルをアクティブに使用している場合）、バッファI/Oは、キャッシュに常駐しているファイルから恩恵を受けますが、古いファイルで一時的にキャッシュを汚染する可能性があります;一方、バッファリングされていない場合は、すでにキャッシュされているファイルの利点が失われます。そのような場合、明確な勝者はありません。
注：これはxcopy /Jにも適用されます
詳細については、Microsoftの パフォーマンスチームのブログに質問する を参照してください。
私は以下を試しました：
高速デバイス（ギガビットイーサネット経由のNAS）から別の高速デバイス（USB3-Disk）にコピーする場合
- / Jなし：データはバッファーに読み込まれ、その後書き込まれるため、ネットワークまたはハードドライブのいずれかがアイドル状態です
- / Jを使用：データは待機せずに読み書きされるため、ネットワークとハードドライブが同時に使用されます
このオプションを使用することをお勧めします。
WANを介してコピーする場合、平均コピー時間が大幅に増加するため、大きなファイルに対して/ Jオプションを有効にしないことをお勧めします。私がコピーしたファイルは500MBから23GBの範囲でした。
50Mbpsの回線では、平均43.5Mbps（他のトラフィックとオーバーヘッド）でしたが、/ Jなしで32Mbpsを下回ることはありませんでした。/Jを使用すると、平均は約25Mbpsでした... perfmonを見ると、下部に大きな山と谷が見られました。
これが誰かを助けることを願っています。