最適なブロックサイズは、オペレーティングシステム（およびそのバージョン）、関連するさまざまなハードウェアバスおよびディスクなど、さまざまな要因によって異なります。いくつかのUnixライクなシステム（Linuxおよび少なくともいくつかのBSDのフレーバーを含む）は、カーネルが最適なブロックサイズであると考えるものを与えるst_blksizeメンバーを定義します。struct stat
#include <sys/stat.h>
#include <stdio.h>
int main(void)
{
struct stat stats;
if (!stat("/", &stats))
{
printf("%u\n", stats.st_blksize);
}
}
最善の方法は、実験することです。さまざまなブロックサイズと時間でギガバイトをコピーします。（各実行の前にカーネルバッファキャッシュをクリアすることを忘れないでください:) echo 3 > /proc/sys/vm/drop_caches。
ただし、経験則として、ブロックサイズが十分に大きいと適切に機能することがわかりましたdd。たとえば、64KiBと1MiBの違いは、4KiBと64KiBの違いはわずかです。（確かに、それを行ってからしばらく経ちました。現在、デフォルトでメビバイトを使用するかdd、サイズを選択します。）
他の人が言っているように、普遍的に正しいブロックサイズはありません。ある状況またはあるハードウェアに最適なものは、別の状況ではひどく非効率的である可能性があります。また、ディスクの状態によっては、「最適」なブロックサイズとは異なるブロックサイズを使用することが望ましい場合があります。
最新のハードウェアでかなり信頼できることの1つは、デフォルトのブロックサイズである512バイトは、より最適な代替手段よりもほぼ1桁遅くなる傾向があることです。疑わしいときは、64Kがかなり堅実な最新のデフォルトであることがわかりました。通常、64Kは最適なブロックサイズではありませんが、私の経験では、デフォルトよりもはるかに効率的である傾向があります。64Kには、確実にパフォーマンスを発揮するというかなり確かな歴史もあります。2002年頃のEug-Lugメーリングリストから、64Kのブロックサイズを推奨するメッセージをここで見つけることができます：http：//www.mail-archive.com/eug- lug@efn.org/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
私はこのスクリプトを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
この場合の重要な違いは、テストファイルがスクリプトによって書き込まれるファイルであるということです。このコマンドを既存のファイルに向けないでください。ポイントすると、既存のファイルがゼロで上書きされます。
私の特定のハードウェアでは、128KがHDDで最適な入力ブロックサイズであり、32KがSSDで最適であることがわかりました。
この回答は私の発見のほとんどをカバーしていますが、私はそれについてブログ投稿を書いたのに十分な回数この状況に遭遇しました：http: //blog.tdg5.com/tuning-dd-block-size/あなたはより詳細を見つけることができます私がそこで行ったテストについて。
最適なブロックサイズは8MB（ディスクキャッシュに等しい？）であることがわかりました。ディスクの圧縮イメージを作成する前に、ディスクの空き領域を消去する（たとえば、洗浄する）必要がありました。私が使用した：
cd /media/DiskToWash/
dd if=/dev/zero of=zero bs=8M; rm zero
私は4Kから100Mまでの値で実験しました。
ddをしばらく実行させた後、それを強制終了し（Ctlr + C）、出力を読み取ります。
36+0 records in
36+0 records out
301989888 bytes (302 MB) copied, 15.8341 s, 19.1 MB/s
ddは入出力レート（この場合は19.1MB / s）を表示するため、選択した値のパフォーマンスが前の値よりも優れているか、または劣っているかを簡単に確認できます。
私のスコア：
bs= I/O rate
---------------
4K 13.5 MB/s
64K 18.3 MB/s
8M 19.1 MB/s <--- winner!
10M 19.0 MB/s
20M 18.6 MB/s
100M 18.6 MB/s
注：ディスクキャッシュ/バッファサイズを確認するには、次を使用できます。sudo hdparm -i /dev/sda
これは完全にシステムに依存します。最適な解決策を見つけるために実験する必要があります。から始めてみてくださいbs=8388608。（Hitachi HDDには8MBのキャッシュがあるようです。）
ddはconv=noerror、syncオプションを使用してデータをコピーするため、エラーが発生すると、ブロックの残りの部分がゼロバイトに置き換えられます。ブロックサイズが大きいほどコピーは速くなりますが、エラーが発生するたびに、ブロックの残りの部分は無視されます。