ハードドライブのクローンを作成するために、最も簡単な形でddを使用しています
dd if=INPUT of=OUTPUT
しかし、ddはblockizeパラメータを知っているとマニュアルに書いてありました。クローニング手順を高速化するブロックサイズパラメータに最適な値はありますか？
53 Phi 2011-01-17
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-heavy converter-programを高速化するための読み書きバッファリングに関する私自身の知見と一致しています
33 akira 2011-01-17
ddはあなたが望むものは何でもBSを使って喜んでコピーし、部分的なブロック（最後に）をコピーします
基本的に、ブロックサイズ(bs)パラメータは、その塊を他のディスクに書き込もうとする前に、一方のディスクから塊を読み取るために使用されるメモリの量を設定するようです
RAMがたくさんある場合、BSを大きくする（ただし完全にRAMに含まれている）ということは、I/Oサブシステムを可能な限り利用して、大量の読み書きを行うことで、RAMを利用することを意味します。BSを小さくするということは、総アクティビティに占めるI/Oオーバーヘッドの割合が高くなることを意味します
もちろん、これにはリターン逓減の法則があります。私の大まかな概算では、約128Kから32Mの範囲内のブロックサイズは、おそらくプレーンI/Oと比較してオーバーヘッドが小さいようなパフォーマンスを与えようとしており、より大きくなっても大きな違いはないだろうということです。下限が128Kから32Mになる理由は、OSやハードウェアなどに依存するからです
もし私だったら、128KのBSを使ってコピー/クローンのタイミングをとったり、16Mを使ってタイミングをとったりと、いくつかの実験をしてみます。どちらかがかなり速い場合は、それを使います。そうでない場合は、2つのうち小さい方のBSを使います
26 quickly_now 2011-01-17
Google経由でここにたどり着いた人のために、この議論が多少古くても
ddが馬鹿なのには理由があることを覚えておいてください：それがシンプルであればあるほど、それが台無しにする方法は少なくなります
複雑なパーティショニングスキーム(LinuxシステムにLVMを追加で使用しているデュアルブートハードドライブを考えてみてください)は、Clonezillaのようなプログラムでバグが発生し始めます。マウントされていないファイルシステムは、ntfsclone を空高く爆破する可能性があります
破損したファイルシステムをセクタごとにクローンしても、元のファイルシステムより悪くはありません。スマートコピー」に失敗した後の破損したファイルシステムは、本当に残念な状態になっているかもしれません
迷ったら、ddを使ってフォレンジックに行きましょう。フォレンジックイメージングでは、セクタごとのコピーが必要になります（実際には、ddを使った場合よりも多くのセクタが必要になることもありますが、それは長い話になります）。この方法は時間がかかり、面倒ですが、仕事を正確にこなすことができます
また、”conv=noerror,sync “オプションを知ることで、故障し始めたドライブのクローンを作成したり、傷のついた(咳)CDからISOを作成したりすることができるようになります
12 Matt Heck 2012-11-01
他の人が言っているように、普遍的に正しいブロックサイズというものはありません。ある状況やあるハードウェアに最適なものは、別の状況では非常に非効率的なものになるかもしれません。また、ディスクの状態によっては、「最適」なブロックサイズとは異なるブロックサイズを使用することが望ましいかもしれません
最近のハードウェアでかなり信頼性が高いのは、デフォルトのブロックサイズ512バイトは、より最適な代替品よりもほぼ桁違いに遅くなる傾向があるということです。疑問がある場合は、64Kが最新のデフォルトであることがわかりました。64Kは通常最適なブロックサイズではありませんが、私の経験ではデフォルトよりもはるかに効率的になる傾向があります。また、64K は信頼性の高いパフォーマンスを実現してきた歴史を持っています: 2002 年頃の Eug-Lug メーリングリストのメッセージでは、64K のブロックサイズを推奨しています。_COPY7@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 でしかテストしたことがありません
既定では、このコマンドはカレントディレクトリに 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
この場合の重要な違いは、テストファイルがスクリプトによって書き込まれたファイルであることです。このコマンドを既存のファイルに向けないようにしてください
私の特定のハードウェアでは、HDDの入力ブロックサイズは128Kが最も最適で、SSDの入力ブロックサイズは32Kが最も最適であることがわかりました
この答えは私の発見のほとんどをカバーしていますが、私はそれについてのブログ記事を書いたほど、この状況に遭遇してきました。http://blog.tdg5.com/tuning-dd-block-size/ あなたは私がそこで行ったテストの詳細を見つけることができます
このStackOverflowの投稿も参考になるかもしれません。dd: 最適なブロックサイズを計算するには？
12 tdg5 2015-01-05
はい、しかし、あなたは多くのテストなしでそれを見つけることはできません。でも、32Mを使うのがお得だということがわかりました
3 Ignacio Vazquez-Abrams 2011-01-17
古いブートドライブを外付けの sata で新しい ssd にクローンする (ssd から ssd へ)
- linux Ubuntu 18.04.2 LTS 64bitを使用しています
- hp xw4600 ( 8GB RAM、intel Core 2 Quad Q6700 @2.66GHz 4c/4t no-HT)
using Disks (tool) > format > ATA Secure Erase (2min)
$ lsblk -l /dev/sd?
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119,2G 0 disk
sda1 8:1 0 119,2G 0 part /
sdb 8:16 0 2,7T 0 disk
sdc 8:32 0 2,7T 0 disk
sdd 8:48 0 12,8T 0 disk
sde 8:64 0 2,7T 0 disk
sdf 8:80 1 465,8G 0 disk
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ sudo fdisk -l /dev/sdf
Disk /dev/sdf: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
- sda: Kingston SSD (古い; Disks の平均 rd レートは 263 MB/s で、ピークは 270 MB/s に近い — システムディスクによる書き込みテストは行われていません)
- SDFを搭載しています。Crucial MX500、500GB、CT500MX500SSD1（ディスクレポート：平均rd/wrレート284/262MB/s、アクセス時間0.05ms、ピークは約290/270MB/s）
Test runs:
$ sudo dd if=/dev/sda of=/dev/sdf
250069680+0 records in
250069680+0 records out
128035676160 bytes (128 GB, 119 GiB) copied, 3391,72 s, 37,7 MB/s
# --vvvvv-- *********
$ sudo dd bs=1M if=/dev/sda of=/dev/sdf
122104+1 records in
122104+1 records out
128035676160 bytes (128 GB, 119 GiB) copied, 473,186 s, 271 MB/s
# ********* ********
安全な消去の後、同じ結果で2回目を試してみてください
128035676160 bytes (128 GB, 119 GiB) copied, 472,797 s, 271 MB/s
1 kgSW.de 2019-04-02
