dd：如何计算最佳块大小？[关闭]

运行a时如何计算最佳块大小dd？我已经研究了一下，但没有发现任何暗示如何实现的建议。

我的印象是更大的块大小会导致更快的速度dd...是真的吗？

我要准备dd两个相同的500gb Hitachi HDD，它们在运行带有4GB DDR3 1333mhz RAM的Intel Core i3的盒子上以7200rpm运行，因此，我试图找出要使用的块大小。（我将要从闪存驱动器启动Ubuntu 10.10 x86，并从中运行它。）

最佳块大小取决于各种因素，包括操作系统（及其版本）以及所涉及的各种硬件总线和磁盘。几个类似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选择大小。）

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

在现代硬件上非常可靠的一件事是，默认的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/您可以找到更多详细信息在我在那里进行的测试中。

我发现我的最佳块大小为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

这完全取决于系统。您应该尝试找到最佳解决方案。尝试从开始bs=8388608。（由于日立硬盘似乎具有8MB缓存。）

• 为了获得更好的性能，请使用RAM可以容纳的最大块大小（将更少的I / O调用发送到OS）
• 为了获得更好的准确性和数据恢复，请将块大小设置为输入的本机扇区大小

当dd使用conv = noerror，sync选项复制数据时，遇到的任何错误将导致该块的其余部分被零字节替换。较大的块大小将更快地复制，但是每次遇到错误时，块的其余部分都会被忽略。

资源