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

Phi*_*Phi 57 linux backup hard-drive clone

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

dd if=INPUT of=OUTPUT
Run Code Online (Sandbox Code Playgroud)

但是,我在联机帮助页中读到 dd 知道一个 blocksize 参数。是否有可以加快克隆过程的 blocksize 参数的最佳值?

aki*_*ira 33

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
Run Code Online (Sandbox Code Playgroud)

(取自这里)。

这与我自己关于读/写缓冲的发现相匹配,以加速我曾经拉皮条@work 的 io-heavy 转换器程序。

  • -1 这几乎完全取决于您的硬盘。而是描述用于获取这些值的过程,以便 OP 可以重复这些步骤以获得他自己的硬盘驱动器的最佳块大小。此外,您还没有在结果列表中列出 64k,并且所有超过 1k 的结果或多或少都相同。 (11认同)

qui*_*now 26

dd 将很乐意使用您想要的任何 BS 进行复制,并将复制部分块(在最后)。

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

如果您有大量 RAM,那么使 BS 变大(但完全包含在 RAM 中)意味着通过执行大量读取和写入(利用 RAM)来尽可能多地利用 I/O 子系统。使 BS 变小意味着 I/O 开销占总活动的比例上升。

当然,这里面有收益递减规律。我的粗略估计是,大约 128K 到 32M 范围内的块大小可能会提供性能,因此与普通 I/O 相比,开销很小,并且变大不会产生很大差异。下限为 128K 到 32M 的原因是 - 这取决于您的操作系统、硬件等。

如果是我,我会做一些实验,使用 128K 的 BS 和(比如)16M 对复制/克隆进行计时。如果一个明显更快,请使用它。如果不是,则使用两者中较小的 BS。

  • 较大的“bs”的改进停滞不前:https://unix.stackexchange.com/a/144177/318461(这也可以在接受的答案中看到:https://superuser.com/a/234204/910769)存在开销,对于越来越大的块,相关性变为零 (2认同)
  • 同意,曾几何时,当我们的服务器运行 UNIX 或 Solaris 并具有大量 64 MB RAM 时,dd 上的 BS 调整非常重要。如今,内存容量很大,只需选择一个大容量即可。 (2认同)

小智 14

对于那些最终通过谷歌来到这里的人,即使这个讨论有点老......

请记住,这dd很愚蠢是有原因的:它越简单,搞砸的方式就越少。

复杂的分区方案(考虑一个额外使用 LVM 用于其 Linux 系统的双引导硬盘驱动器)将开始在Clonezilla 之类的程序中从木制品中提取错误。错误卸载的文件系统可能会爆炸ntfsclone

逐个扇区克隆的损坏文件系统并不比原始文件系统差。“智能复制”失败后损坏的文件系统可能处于非常糟糕的状态。

如有疑问,请使用dd并进行取证。取证成像需要逐个扇区的副本(实际上,它可能需要比使用dd. 它缓慢而乏味,但可以正确完成工作。

此外,了解这些conv=noerror,sync选项,以便您可以克隆开始出现故障的驱动器 - 或者从划伤()CD制作 ISO,而无需花费数月时间。

  • 尝试添加一些格式。对 `conv=noerror,sync` 的解释基本上是错误安全的,但您应该确保您还输入了 `iflag=fullblock`。遗憾的是,`iflag` 不是 POSIX 必需的,但至少[在文档中提到](https://www.gnu.org/software/coreutils/manual/html_node/dd-inspiration.html)。在使用这些“约定”时要求“iflag”的原因是,否则您可能会[损坏您的数据,以防您使用错误的 bs/ibs](https://superuser.com/a/1075837/910769) 。 [进一步阅读此处](https://superuser.com/a/1097391/910769)。 (3认同)
  • 如果有任何读取错误,@sherrellbc sync 用零填充输入块,因此数据偏移量保持同步。 (2认同)

tdg*_*dg5 14

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

在现代硬件上非常可靠的一件事是,512 字节的默认块大小往往比更优化的替代方案慢几乎一个数量级。如有疑问,我发现 64K 是一个非常可靠的现代默认值。虽然 64K 通常不是最佳的块大小,但根据我的经验,它往往比默认值高效得多。64K 在性能可靠方面也有着相当稳固的历史:您可以在大约 2002 年的 Eug-Lug 邮件列表中找到一条消息,建议在此处使用 64K 的块大小:http : //www.mail-archive.com/eug- lug@efn.org/msg12073.html

为了确定最佳输出块大小,我编写了以下脚本来测试使用 dd 在一系列不同块大小(从默认值 512 字节到最大 64M)编写 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
Run Code Online (Sandbox Code Playgroud)

在 GitHub 上查看

我只在 Debian (Ubuntu) 系统和 OSX Yosemite 上测试了这个脚本,所以它可能需要一些调整才能在其他 Unix 风格上工作。

默认情况下,该命令将在当前目录中创建一个名为dd_obs_testfile的测试文件。或者,您可以通过在脚本名称后提供路径来提供自定义测试文件的路径:

$ ./dd_obs_test.sh /path/to/disk/test_file
Run Code Online (Sandbox Code Playgroud)

脚本的输出是测试块大小及其各自传输速率的列表,如下所示:

$ ./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
Run Code Online (Sandbox Code Playgroud)

(注:传输速率的单位会因操作系统而异)

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

dd_ibs_test.sh:

$ ./dd_obs_test.sh /path/to/disk/test_file
Run Code Online (Sandbox Code Playgroud)

在 GitHub 上查看

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

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

虽然这个答案涵盖了我的大部分发现,但我已经多次遇到这种情况,所以我写了一篇关于它的博客文章:http : //blog.tdg5.com/tuning-dd-block-size/你可以找到更多细节我在那里进行的测试。

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