64k が適切な選択のようです:
Results:
no bs= 78s 144584+0 records
bs=512 78s 144584+0 records
bs=1k 38s 72292+0 records
bs=2k 38s 36146+0 records
bs=4k 38s 18073+0 records
bs=5k 39s 14458+1 records
bs=50k 38s 1445+1 records
bs=500k 39s 144+1 records
bs=512k 39s 144+1 records
bs=1M 39s 72+1 records
bs=5M 39s 14+1 records
bs=10M 39s 7+1 records
（ここから取得）
これは、私がかつて @work を売り込んでいた io 負荷の高いコンバーター プログラムを高速化するための読み取り/書き込みバッファリングに関する私自身の調査結果と一致します。
dd は、好きなように BS を使用して喜んでコピーし、(最後に) 部分ブロックをコピーします。
基本的に、ブロック サイズ (bs) パラメーターは、1 つのディスクからその塊を別のディスクに書き込む前に、その塊を読み取るために使用されるメモリの量を設定するようです。
大量の RAM がある場合、BS を大きくする (ただし、完全に RAM に含まれる) ということは、大量の読み取りと書き込みを行うことによって I/O サブシステムが可能な限り利用されることを意味し、RAM を活用します。 BS を小さくすると、アクティビティ全体の割合としての I/O オーバーヘッドが増加します。
もちろん、これには収穫逓減の法則があります。私のおおまかな概算は、約 128K から 32M の範囲のブロック サイズが、通常の I/O と比較してオーバーヘッドが小さいようなパフォーマンスを提供し、大きくなっても大きな違いは生じないということです。下限が 128K から 32M である理由は、OS、ハードウェアなどによって異なります。
私だったら、128K の BS を使用してコピー/クローンのタイミングを計り、(たとえば) 16M を使用して、いくつかの実験を行います。どちらかがかなり速い場合は、それを使用してください。そうでない場合は、2 つのうち小さい方の BS を使用してください。
他の人が言ったように、普遍的に正しいブロックサイズはありません。ある状況やあるハードウェアにとって何が最適であっても、別の状況では非常に非効率的である可能性があります。また、ディスクの健全性によっては、「最適」とは異なるブロック サイズを使用することが望ましい場合があります。
最新のハードウェアでかなり信頼できることの 1 つは、512 バイトのデフォルトのブロック サイズが、より最適な代替手段よりもほぼ 1 桁遅くなる傾向があることです。疑問がある場合は、64K がかなり堅実な最新のデフォルトであることがわかりました。通常、64K は最適なブロック サイズではありませんが、私の経験では、デフォルトよりもはるかに効率的です。 64K には、信頼性の高いパフォーマンスを実現してきた確かな歴史もあります。2002 年頃の Eug-Lug メーリング リストから、64K のブロック サイズを推奨するメッセージを見つけることができます:http://www.mail-archive.com/example@ unixlinux.online/msg12073.html
最適な出力ブロック サイズを決定するために、デフォルトの 512 バイトから最大 64M までのさまざまなブロック サイズで、dd を使用して 128M のテスト ファイルの書き込みをテストする次のスクリプトを作成しました。このスクリプトは内部で dd を使用するため、注意して使用してください。
dd_obs_test.sh:
#!/bin/bash
# Since we're dealing with dd, abort if any errors occur
set -e
TEST_FILE=${1:-dd_obs_testfile}
TEST_FILE_EXISTS=0
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=1; fi
TEST_FILE_SIZE=134217728
if [ $EUID -ne 0 ]; then
echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi
# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'
# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
# Calculate number of segments required to copy
COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))
if [ $COUNT -le 0 ]; then
echo "Block size of $BLOCK_SIZE estimated to require $COUNT blocks, aborting further tests."
break
fi
# Clear kernel cache to ensure more accurate test
[ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches
# Create a test file with the specified block size
DD_RESULT=$(dd if=/dev/zero of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync 2>&1 1>/dev/null)
# Extract the transfer rate from dd's STDERR output
TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')
# Clean up the test file if we created one
if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi
# Output the result
printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done
GitHub で表示
私はこのスクリプトを Debian (Ubuntu) システムと OSX Yosemite でしかテストしていないので、他の Unix フレーバーで動作させるにはおそらく多少の調整が必要になるでしょう.
デフォルトでは、コマンドは dd_obs_testfile という名前のテスト ファイルを作成します。 現在のディレクトリに。または、スクリプト名の後にパスを指定して、カスタム テスト ファイルへのパスを指定することもできます:
$ ./dd_obs_test.sh /path/to/disk/test_file
スクリプトの出力は、テストされたブロック サイズとそれぞれの転送速度のリストです。
$ ./dd_obs_test.sh
block size : transfer rate
512 : 11.3 MB/s
1024 : 22.1 MB/s
2048 : 42.3 MB/s
4096 : 75.2 MB/s
8192 : 90.7 MB/s
16384 : 101 MB/s
32768 : 104 MB/s
65536 : 108 MB/s
131072 : 113 MB/s
262144 : 112 MB/s
524288 : 133 MB/s
1048576 : 125 MB/s
2097152 : 113 MB/s
4194304 : 106 MB/s
8388608 : 107 MB/s
16777216 : 110 MB/s
33554432 : 119 MB/s
67108864 : 134 MB/s
(注:転送速度の単位は OS によって異なります)
最適な読み取りブロック サイズをテストするには、多かれ少なかれ同じプロセスを使用できますが、/dev/zero から読み取ってディスクに書き込む代わりに、ディスクから読み取って /dev/null に書き込みます。これを行うスクリプトは次のようになります:
dd_ibs_test.sh:
#!/bin/bash
# Since we're dealing with dd, abort if any errors occur
set -e
TEST_FILE=${1:-dd_ibs_testfile}
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=$?; fi
TEST_FILE_SIZE=134217728
# Exit if file exists
if [ -e $TEST_FILE ]; then
echo "Test file $TEST_FILE exists, aborting."
exit 1
fi
TEST_FILE_EXISTS=1
if [ $EUID -ne 0 ]; then
echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi
# Create test file
echo 'Generating test file...'
BLOCK_SIZE=65536
COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))
dd if=/dev/urandom of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync > /dev/null 2>&1
# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'
# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
# Clear kernel cache to ensure more accurate test
[ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches
# Read test file out to /dev/null with specified block size
DD_RESULT=$(dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE 2>&1 1>/dev/null)
# Extract transfer rate
TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')
printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done
# Clean up the test file if we created one
if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi
GitHub で表示
この場合の重要な違いは、テスト ファイルがスクリプトによって書き込まれるファイルであることです。このコマンドを既存のファイルに指定しないでください。指定すると、既存のファイルがランダム データで上書きされます!
私の特定のハードウェアでは、HDD では 128K が最適な入力ブロック サイズであり、SSD では 32K が最適であることがわかりました。
この回答は私の調査結果のほとんどをカバーしていますが、私はこの状況に何度も遭遇し、それについてブログ投稿を書きました:http://blog.tdg5.com/tuning-dd-block-size/ 詳細を見つけることができますそこで行ったテストについて。
この StackOverflow の投稿も役立つ場合があります:dd:最適なブロックサイズを計算する方法