web-dev-qa-db-ja.com

ddへのbsパラメータの最適値を決定する方法はありますか？

オンラインで「デフォルト値には時間がかかりすぎるので、必ず「bs =」を設定してください」というコメントや、私自身の非常に非科学的な経験を見てきました。先週の時間」はそれを我慢するようです。そのため、「dd」を使用するときは常に（通常は1〜2 GBの範囲）、必ずbytesパラメータを指定します。約半分の時間で、コピー元のオンラインガイドで指定された値を使用しています。残りの時間は、「fdisk -l」のリストから意味のある数字を選び、遅いメディア（たとえば、書き込み先のSDカード）であると想定します。

特定の状況（メディアタイプ、バスサイズ、またはその他の問題）について、「最良の」値を決定する方法はありますか？判断は簡単ですか？そうでない場合、そこにある方法の90-95％を取得する簡単な方法はありますか？または、正解でも「512より大きいものを選ぶ」だけですか？

私は自分で実験を試すことを考えましたが、（多くの作業であることに加えて）どの要素が答えに影響を与えるのかわからないため、良い実験を設計する方法がわかりません。

performanceddfile-copy
74
user4443

ddは、古いIBMメインフレームテープを変換する必要があったときからの日付であり、ブロックサイズは、テープの書き込みに使用されたものと一致する必要がありました。または、データブロックがスキップまたは切り捨てられました。 （9トラックのテープは気の利いたものだった。長い間死んでもよかった。）最近、ブロックサイズはデバイスのセクターサイズの倍数になるはずです（通常は4KBですが、ごく最近のディスクでは非常に大きく、非常に小さい場合もあります）。ドライブは小さくてもかまいませんが、4KBは妥当な中間点です）、大きいほどパフォーマンスが向上します。私はハードドライブで1MBのブロックサイズをよく使用します。 （私達はこれらの日を振り回すためにより多くの記憶を持っています。）

29
geekosaur

最適なブロックサイズを決定する方法は1つしかありませんが、それはベンチマークです。簡単なベンチマークを作成しました。テストマシンは、Debian GNU/Linuxを実行するPCで、カーネル2.6.32とcoreutils 8.5が搭載されています。関連する両方のファイルシステムは、ハードディスクパーティション上のLVMボリューム上のext3です。ソースファイルは2GB（正確には2040000kB）です。キャッシングとバッファリングが有効になっています。各実行の前に、sync; echo 1 >|/proc/sys/vm/drop_cachesを使用してキャッシュを空にしました。ランタイムには、バッファーをフラッシュするための最後のsyncが含まれていません。最後のsyncは、およそ1秒かかります。

sameの実行は同じファイルシステム上のコピーでした。 diffの実行は、別のハードディスク上のファイルシステムへのコピーでした。一貫性を保つために、報告される時間は、timeユーティリティで取得された実時間（秒単位）です。私は各コマンドを1回だけ実行したので、タイミングにどの程度のばらつきがあるのか​​わかりません。

             same   diff
             t (s)  t (s)
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

結論：大きなブロックサイズ（数メガバイト）は役立ちますが、劇的ではありません（同じドライブのコピーで予想していたよりもはるかに小さい）。 catとcpはそれほどパフォーマンスが良くありません。これらの数字では、私はddを気にする価値はありません。 cat！

61
Gilles 'SO- stop being evil'

サイズはブロックサイズの倍数である必要があるというオタクに同意します。多くの場合4Kです。

ブロックサイズを確認する場合は、_stat -c "%o" filename_がおそらく最も簡単なオプションです。

しかし、_dd bs=4K_を実行するとします。つまり、read(4096); write(4096); read(4096); write(4096)...を実行します。

各システムコールにはコンテキストスイッチが含まれ、オーバーヘッドが発生します。I/ Oスケジューラーによっては、書き込みが散在している読み取りで、ディスクが大量のシークを実行する可能性があります。 （おそらくLinuxスケジューラーの大きな問題ではありませんが、それでも考えるべきことです。）

したがって、_bs=8K_を実行すると、書き込みを行う（または別のプロセスのI/Oを処理する）ために他の場所を探す前に、ディスクが一度に2つのブロックを読み取ることを許可します。 。

そのロジックにより、_bs=16K_はさらに優れています。

だから私が知りたいのは、パフォーマンスが低下し始める上限があるかどうか、またはそれがメモリによってのみ制限されているかどうかです。

8
Mikel

Gillesが言うように、bsオプションの最適なパラメーターをddベンチマーク。しかし、これは疑問を投げかけます：このパラメーターをどのように便利にベンチマークできますか？

この質問に対する私の暫定的な回答は次のとおりです。 dd-opt を使用してください。この問題を正確に解決するために最近作業を開始したユーティリティです:)

5
sampablokuper

bs=10Mで最適に動作するように見えるSDカードリーダーusb2.0用に最適化しました。私は4Kを16Mまで試しましたが、8-10Mは改善しませんでした。転送速度の測定値がどのように低下​​するかを確認できます。おそらくデバイスにバッファをロードしてから、デバイスが実際のメディアに転送されるのを待っているためです。

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s
0
wwright