☰

使用 diskdump (dd) 进行磁盘克隆的良好块大小

tag-icon • tag-icon linux hard-drive backup clone
使用 diskdump (dd) 进行磁盘克隆的良好块大小

我使用最简单的 dd 形式来克隆硬盘：

dd if=INPUT of=OUTPUT

但是，我在手册页中看到 dd 知道一个块大小参数。块大小参数是否有一个最佳值可以加快克隆过程？

答案1

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 密集型转换程序的发现相符。

答案2

dd 会很乐意使用您想要的任何 BS 进行复制，并且会复制部分块（在最后）。

基本上，块大小（bs）参数似乎设置在尝试将该块写入另一个磁盘之前用于从一个磁盘读取该块的内存量。

如果您有大量 RAM，那么将 BS 设为大（但完全包含在 RAM 中）意味着通过执行大量读取和写入（利用 RAM），尽可能多地利用 I/O 子系统。将 BS 设为小意味着 I/O 开销占总活动的比例会增加。

当然，这其中存在着收益递减规律。我的粗略估计是，大约 128K 到 32M 范围内的块大小可能会提供这样的性能，即与普通 I/O 相比，开销很小，而增大块大小不会产生太大差异。下限为 128K 到 32M 的原因是 - 这取决于您的操作系统、硬件等。

如果是我，我会做一些实验，使用 128K 的 BS 和（比如说）16M 的 BS 来计时复制/克隆。如果其中一个明显更快，就使用它。如果不是，那么使用两者中较小的 BS。

答案3

正如其他人所说，没有普遍正确的块大小；对于一种情况或一种硬件而言最佳的块大小对于另一种情况或硬件而言可能非常低效。此外，根据磁盘的健康状况，使用与“最佳”块大小不同的块大小可能更好。

在现代硬件上，有一件事是相当可靠的，那就是 512 字节的默认块大小往往比更优化的替代方案慢几乎一个数量级。当有疑问时，我发现 64K 是一个非常可靠的现代默认值。虽然 64K 通常不是最佳块大小，但根据我的经验，它往往比默认值高效得多。64K 也具有相当可靠的性能历史：您可以在此处找到来自 Eug-Lug 邮件列表（大约 2002 年）的消息，建议使用 64K 的块大小：http://www.mail-archive.com/[电子邮件保护]/msg12073.html

为了确定最佳输出块大小，我编写了以下脚本，测试使用 dd 以一系列不同的块大小（从默认的 512 字节到最大 64M）写入 128M 的测试文件。请注意，此脚本在内部使用 dd，因此请谨慎使用。

dd_obs_测试.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_测试文件在当前目录中。或者，您可以通过在脚本名称后提供路径来提供自定义测试文件的路径：

$ ./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

（注：传输速率的单位因操作系统不同而不同）

要测试最佳读取块大小，您可以使用大致相同的过程，但不是从 /dev/zero 读取并写入磁盘，而是从磁盘读取并写入 /dev/null。执行此操作的脚本可能如下所示：

dd_ibs_测试.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 上查看

在这种情况下，一个重要的区别是测试文件是脚本写入的文件。不要将此命令指向现有文件，否则现有文件将被随机数据覆盖！

对于我的特定硬件，我发现 128K 是 HDD 上最优的输入块大小，而 32K 是 SSD 上最优的。

虽然这个答案涵盖了我的大部分发现，但我已经遇到过很多次这种情况，因此我写了一篇博客文章：http://blog.tdg5.com/tuning-dd-block-size/您可以在那里找到我所执行的测试的更多详细信息。

这个 StackOverflow 帖子可能也有帮助：dd：如何计算最佳块大小？

答案4

是的，但是如果不进行大量测试，您将找不到它。不过我发现 32M 是一个不错的值。

相关内容