最適な「ブロックサイズ」についての同じ考えがddにも当てはまりますか?
そう思います。4kbのバッファーを考えてみましょう。ファイルシステムにも4kブロックがある場合は、単純なmmap操作で埋めることができます(新しいフラッシュディスクでは一般的です)。1つのストリームがバッファーを満たし、次にバッファーを書き込む必要がある場合、バッファーがフラッシュされるまで入力ストリームはブロックされます。これが、複数のバッファーを使用する理由です。一方、出力に書き込まれる前に、最初に単一のバッファーを埋める必要があると思います。したがって、すでに使用可能なデータがある場合でも、バッファはメモリに保持されている必要があります。1Gigバッファー(またはブロックサイズ)を使用する場合、これも最適ではありません。
gpartedのバッファサイズを調べたところ、128kbと256kb(もっと複雑かもしれません)が切り替わったようで、ほとんどのシステムにあるキャッシュのほとんどを作りたいようです。2MBのディスクキャッシュがある場合、そのサイズのブロックでデータを転送することは理にかなっている可能性があり、mmapped ioが使用されていない場合、それらのブロックはCPUキャッシュに収まる可能性もあります。
もしそうなら、それが最も強く適用される特定の状況はありますか?
データがブロック単位で読み書きできる場合、多くのデータを転送するすべての操作。
ブロックサイズを有利に使用するにはどうすればよいですか?
どちらがあなたのために断食されているかをテストすることによってそれを計算します。その単純で上記の説明を考えると、ブロックサイズとして約256kから始めるのが良いかもしれません。または、autobufsizeオプションをddに追加します:)。