web-dev-qa-db-ja.com

dd：最適なブロックサイズの計算方法は？

ddを実行するときに、最適なブロックサイズをどのように計算しますか？私はそれを少し調査しましたが、これがどのように達成されるかを示唆するものは見つかりませんでした。

ブロックサイズを大きくするとdd...が速くなるという印象を受けていますが、これは本当ですか？

4GB DDR3 1333mhz RAMを搭載したIntel Core i3を実行しているボックスで7200rpmで動作する2つの同一の500gb日立製HDDをddにしようとしています。 （フラッシュドライブからUbuntu 10.10 x86を起動し、そこから実行します。）

linuxdd
100
eckza

最適なブロックサイズは、オペレーティングシステム（およびそのバージョン）、関連するさまざまなハードウェアバスおよびディスクなど、さまざまな要因によって異なります。いくつかの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が適切に機能し、64 KiBと1 MiBの違いは、4 KiBと64の比較に比べて小さいことがわかりました。 KiB。 （確かに、そうしてからしばらく経ちました。デフォルトでメビバイトを使用するか、ddにサイズを選択させます。）

82
user25148

他の人が言ったように、普遍的に正しいブロックサイズはありません。ある状況またはあるハードウェアに最適なものは、別の状況にはひどく非効率かもしれません。また、ディスクの状態によっては、「最適な」ブロックサイズとは異なるブロックサイズを使用することをお勧めします。

最新のハードウェアで非常に信頼性の高いことの1つは、512バイトのデフォルトブロックサイズが、最適な選択肢よりもほぼ1桁遅い傾向があることです。疑わしいときは、64Kが非常に堅実な現代のデフォルトであることがわかりました。通常、64Kは最適なブロックサイズではありませんが、私の経験では、デフォルトよりもはるかに効率的である傾向があります。 64Kには、確実にパフォーマンスを発揮するという堅実な歴史もあります。2002年頃のEug-Lugメーリングリストから、64Kのブロックサイズを推奨するメッセージを見つけることができます。 http：//www.mail-archive。 com/[email protected]/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/ そこで実行したテストの詳細を確認できます。

63
tdg5

最適なブロックサイズは8 MB（ディスクキャッシュと同じですか？）であることがわかりました。ディスクの圧縮イメージを作成する前に、ディスク上の空き領域を消去する必要があります。私が使用した：

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を使用できます

10
unfa

dd-opt 、私が書いた小さなユーティリティを使用してみてください。

（改善/改善を歓迎します！）

4
sampablokuper

これは完全にシステムに依存しています。最適なソリューションを見つけるために実験する必要があります。 bs=8388608から始めてみてください。 （日立のHDDには8MBのキャッシュがあるようです。）

3
ssapkota
  • パフォーマンスを向上させるには、RAMが収容できる最大のブロックサイズを使用します（OSへのI/O呼び出しが少なくなります）
  • 精度とデータ回復を向上させるために、ブロックサイズを入力のネイティブセクターサイズに設定します

Ddはconv = noerror、syncオプションを使用してデータをコピーするため、エラーが発生すると、ブロックの残りがゼロバイトに置き換えられます。ブロックサイズを大きくすると、より速くコピーされますが、エラーが発生するたびに、ブロックの残りの部分は無視されます。

ソース

1
eadmaster