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

Answers:

32

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转换器程序的速度。

— 阿基拉
source
请注意，对于旋转驱动器和ssds，此基准可能看起来有所不同。
— 吉里（Jiri）2015年
3
-1这几乎完全取决于您的硬盘驱动器。而是描述用于获取这些值的过程，以便OP可以重复这些步骤以获得自己硬盘的最佳块大小。另外，您还没有在结果列表中列出64k，并且超过1k的所有结果或多或少都相同。
— 米歇尔·约翰逊
@MichealJohnson可以随时编辑此帖子，并通过提供的链接对表的生成方式进行描述，并将其粘贴到此处。64k是似乎在速度方面没有进一步改善的第一个值，并且自然对齐。是的，很明显，测得的速度完全取决于所使用的硬件。这是5年前的事实，现在是事实。
— akira 2016年
1
为什么是64k？对我来说2k不会产生任何进一步的改善，因此1k是最好的值，并且与64k一样自然对齐。
— 米歇尔·约翰逊
块大小是否会更改SD卡的性能，还是仅使用dd到sdcard缩小移动文件的大小？
— Trismegistos
22

dd会使用所需的BS来愉快地进行复制，并将复制部分块（最后）。

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

如果您有大量的RAM，则使BS大（但完全包含在RAM中）意味着通过进行大量的读写操作（利用RAM）来尽可能多地利用I / O子系统。使BS变小意味着I / O开销占总活动的比例增加。

当然，这有一条收益递减的法则。我的粗略估计是，块大小在128K到32M之间可能会带来性能，与普通I / O相比，开销较小，而增大I / O并不会带来太大的区别。下限为128K到32M的原因是-它取决于您的操作系统，硬件等。

如果是我，我将做一些实验，使用128K的BS并再次使用（例如）16M的定时来进行复制/克隆。如果明显快一些，请使用它。如果不是，则使用两者中较小的BS。

— quick_now
source
10

对于那些通过Google最终落到这里的人，即使这个讨论有点旧...

请记住，dd愚蠢是有原因的：它越简单，其固定方式就越少。

复杂的分区方案（考虑一个双引导硬盘，在Linux系统上另外使用LVM）将开始从诸如Clonezilla之类的程序中抽出错误。严重卸载的文件系统可能会使ntfsclone变得空前高涨。

逐个扇区克隆的损坏文件系统并不比原始文件系统差。失败的“智能副本”后损坏的文件系统可能真的很抱歉。

如有疑问，请使用dd进行取证。法医成像需要逐个扇区地进行复制（实际上，它可能需要比使用dd能够实现的更多的扇区，但这是一个很长的故事）。这是缓慢而乏味的，但可以正确完成工作。

此外，了解“ conv = noerror，sync”选项，以便您可以克隆开始出现故障的驱动器-或从临时CD （咳嗽的 CD）制作ISO-无需花费数月的时间。

— 马特·赫克
source
该sync选项有什么作用？手册页只说："use synchronized I/O for data and metadata"。我们要与什么同步？那可能是很多不同的事情。
— sherrellbc
1
如果有任何读取错误，@ sherrellbc sync将用零填充输入块，因此数据偏移保持同步。
— goetzc
9

正如其他人所说，没有普遍正确的块大小。对于一种情况或一种硬件而言，最佳选择对于另一种情况可能效率极低。同样，根据磁盘的运行状况，可能最好使用与“最佳”大小不同的块大小。

在现代硬件上非常可靠的一件事是，默认的512字节块大小往往比最佳的替代方法慢了近一个数量级。如有疑问，我发现64K是相当可靠的现代默认设置。尽管64K通常不是最佳的块大小，但根据我的经验，它往往比默认的要有效得多。64K也具有可靠的执行历史：您可以在2002年左右的Eug-Lug邮件列表中找到一条消息，建议在此处建议使用64K的块大小：http : //www.mail-archive.com/eug- lug@efn.org/msg12073.html

为了确定最佳输出块大小，我编写了以下脚本，该脚本在不同的块大小范围内测试写入dd的128M测试文件，从默认的512字节到最大的64M。请注意，此脚本在内部使用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

（注意：传输速率的单位将因操作系统而异）

为了测试最佳的读取块大小，您可以使用或多或少的相同过程，但不是从/ 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上查看

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

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

尽管此答案涵盖了我的大部分发现，但我已经多次遇到这种情况，以至于我写了一篇有关它的博客文章：http : //blog.tdg5.com/tuning-dd-block-size/您可以找到更多详细信息在我在那里进行的测试中。

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

— tdg5
source
1

在外部sata上将旧的引导驱动器克隆到新的ssd（从ssd到ssd）

  • 使用Linux Ubuntu 18.04.2 LTS 64bit
  • hp xw4600（8GB RAM，Intel Core 2 Quad Q6700 @ 2.66GHz 4c / 4t无HT）

使用磁盘（工具）>格式> ATA安全擦除（2分钟）

$ 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（旧；磁盘报告平均rd速率263 MB / s，峰值接近270 MB / s-系统磁盘未进行写测试）
  • sdf：Crucial MX500、500GB，CT500MX500SSD1（磁盘报告：平均rd / wr速率为284/262 MB / s，访问时间为0.05ms，峰值约为290/270 MB / s）

测试运行：

$ 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
#                                            *********  ********

安全擦除后第二次尝试，结果相同：

128035676160 bytes (128 GB, 119 GiB) copied, 472,797 s, 271 MB/s
— kgSW.de
source
欢迎来到超级用户！感谢您的回答，但我建议您对其进行编辑以包括摘要。在所有引用的输出中，我很难找到您的实际答案！干杯
— bertieb
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.