dd：如何计算最佳块大小？

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

我的印象是，更大的块大小会导致更快的dd …这是真的吗？

我即将dd两个相同的500GB的日立硬盘驱动器运行在7200转每分钟运行英特尔酷睿i3 4GB DDR3 1333mhz内存，所以我想弄清楚什么是块大小使用。 （我将从闪存驱动器引导Ubuntu 10.10 x86，并从中运行。）

最佳块大小取决于各种因素，包括操作系统（及其版本）以及所涉及的各种硬件总线和磁盘。 几个类Unix系统（包括Linux和至less一些BSD）在struct stat中定义了st_blksize成员，它给出了内核认为是最佳块大小的内容： 

 #include <sys/stat.h> #include <stdio.h> int main(void) { struct stat stats; if (!stat("/", &stats)) { printf("%u\n", stats.st_blksize); } }

最好的方法可能是试验：复制一个千兆字节的块大小和时间。 （请记住在每次运行之前清除内核缓冲区高速caching： echo 3 > /proc/sys/vm/drop_caches ）。

然而，作为一个经验法则，我发现一个足够大的块大小可以让dd做得很好，比如64 KiB和1 MiB之间的差别很小，而4 KiB与64 KiB之间的差别很小。 （虽然，虽然已经有一段时间了，但是现在我默认使用mebibyte，或者让ddselect大小）。

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

在现代硬件上相当可靠的一件事是，512字节的默认块大小几乎比一个更优化的替代scheme慢一个数量级。 如果有疑问，我发现64K是一个非常坚实的现代默认。 虽然64K通常不是最佳的块大小，但根据我的经验，它往往比默认的更有效率。 64K也有一个非常可靠的性能可靠的历史：您可以从Eug-Lug邮件列表中find一条消息，大约在2002年，推荐64K的块大小： http ： //www.mail-archive.com/e- lug@efn.org/msg12073.html

为了确定最佳的输出块大小，我写了下面的脚本，testing用dd在不同块大小的范围内写入一个128M的testing文件，从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上testing过这个脚本，因此可能需要一些调整才能在其他Unix版本上工作。

默认情况下，该命令将在当前目录中创build一个名为dd_obs_testfile的testing文件。 或者，您可以通过在脚本名称后面提供path来提供自定义testing文件的path： 

 $ ./dd_obs_test.sh /path/to/disk/test_file

脚本的输出是一个testing块大小和它们各自的传输速率的列表，如下所示： 

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

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

为了testing最佳的读取块大小，你可以使用或多或less的相同的进程，但是从/ 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上查看

这种情况下的一个重要区别是testing文件是由脚本编写的文件。 不要将此命令指向现有文件，否则现有文件将被零覆盖！

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

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

我发现我的最佳块大小为8 MB（等同于磁盘caching？）我需要在创build压缩映像之前擦除（某些说：清洗）磁盘上的空白空间。 我用了： 

 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显示input/输出速率（在这种情况下为19.1MB / s），所以很容易看出您select的值是否比前一个更好或更差。

我的分数： 

 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

你可以尝试使用dd-opt ，这是我写的一个小工具。

（改进/完善欢迎！）

这完全取决于系统。 你应该尝试find最佳的解决scheme。 尝试从bs=8388608 。 （由于日立硬盘似乎有8MBcaching。）

  • 为了更好的执行，使用RAM可容纳的最大块（将发送较less的I / O调用到操作系统）
  • 为了更好的准确性和数据恢复，将块大小设置为input的本地扇区大小

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

资源

Interesting Posts