如何在运行dd时计算最佳块大小？我已经进行了一些研究，但没有找到任何建议如何完成此操作的内容。
我的理解是，较大的块大小会导致更快的dd...这是真的吗？
我将使用一个运行Intel Core i3处理器，4GB DDR3 1333MHz内存和两个相同的500GB Hitachi HDD（转速为7200rpm）的设备进行dd。因此，我正在尝试弄清楚要使用什么块大小。（我将从闪存驱动器启动Ubuntu 10.10 x86，并从其中运行它。）
5个回答
117
最佳块大小取决于各种因素，包括操作系统（及其版本）以及涉及的各种硬件总线和磁盘。几个类Unix系统（包括Linux和至少一些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);
}
}
可能最好的方法是进行实验：使用不同的块大小复制1GB的数据并计时。（记得在每次运行前清除内核缓存： echo 3 > /proc/sys/vm/drop_caches）。
然而，作为经验法则，我发现足够大的块大小可以让dd做得很好，相比于4 KiB与64 KiB之间的区别，64 KiB和1 MiB之间的区别微不足道。（尽管，诚然，我已经有一段时间没这样做了。我现在默认使用mebibyte，或者让dd自己选择大小。）
- user25148
3
15非常抱歉我从未接受这个答案……谢谢！ - eckza
1关于记得清除缓存的建议非常好。这使我的测量结果出现了问题！（虽然有个小问题：它应该是“drop_caches”，带下划线。显然，编辑需要至少6个字符... :(） - Tom
1“或者就让 dd 选择大小” 我认为由于历史原因，它将始终为512字节。 - Vladimir Panteleev
96
正如其他人所说，没有普适的正确块大小；对于一个情境或一个硬件而言最优的块大小可能会对另一个情境或硬件非常低效。此外，根据磁盘的健康状况，使用不同于“最优”的块大小可能更好。
在现代硬件上，相当可靠的一点是，默认的512字节块大小往往比更优秀的替代方案慢了近一个数量级。当有疑问时，我发现64K是一个相当可靠的现代默认值。尽管64K通常不是“最优”的块大小，但在我的经验中，它往往比默认值更有效率。64K还有一个相当可靠的历史表现：你可以在这里找到Eug-Lug邮件列表的一条消息，大约是2002年，推荐使用64K的块大小：http://www.mail-archive.com/eug-lug@efn.org/msg12073.html
为了确定“最优”的输出块大小，我编写了以下脚本，测试以各种不同的块大小（从默认的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
我只在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
这种情况的一个重要区别是，测试文件是由脚本编写的。不要将此命令指向现有文件，否则现有文件将被覆盖为零!
对于我的特定硬件，我发现128K是HDD上最优输入块大小，而32K是SSD上最优的。
虽然这个答案涵盖了我大部分的发现，但我遇到过这种情况足够多次，以至于我写了一篇博客文章: http://blog.tdg5.com/tuning-dd-block-size/您可以在那里找到我执行的更多测试的具体信息。
- tdg5
8
1我已经在一台2015年的rMBP上运行了第二个脚本，测试读取性能，使用的是512G SSD。最佳块大小为8388608：3.582 GB字节/秒。 - Quinn Comendant
1更正：我在一台2015年的rMBP笔记本电脑上运行了第二个脚本，测试读取性能，该电脑配备了512GB SSD。最佳块大小为524288（5.754 GB/sec）。次佳块大小为131072（5.133 GB/sec）。（我在生成上一个评论中的值时错误地排序了结果。） - Quinn Comendant
对于
dd_obs_test.sh，在 macOS 上 conv=fsync 不起作用，可以将其删除。 - rynop4哥们儿！真是个惊人的答案。这就像找到了一个金矿，挖了一堆泥土然后加工出我想要的黄金块：64K。非常感谢。 - SDsolar
1我在Amazon EC2实例上运行了这个测试（在t3.micro实例上运行Amazon Linux 2），结果并不是我预期的，但可能是我应该预期的。512和1024都超过了250+ MB/s，而其他几乎一致为137MB/s。我反转了块大小列表的顺序，得到了相反的结果。我认为结果显示出了突发流量，几乎所有东西都受到网络限制，以获得磁盘性能。 - Brad Moore
显示剩余3条评论
17
我发现我的最佳块大小为8 MB（等同于磁盘缓存？）在创建压缩镜像之前，我需要擦除（有人说：清洗）磁盘上的空白空间。
cd /media/DiskToWash/
dd if=/dev/zero of=zero bs=8M; rm zero
我尝试了从4K到100M的值。
让dd运行一段时间后，我中断了它（Ctrl+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
- unfa
4
4你是否只运行了每个测试一次？我认为，当缓冲区已经满时，从≥64K看到的差异仅是随机方差。 - Mads Y
我曾经听说过大值可能会成为系统的瓶颈。当时那个人正在处理一个大文件。如果有更多相关信息就太好了。 - Todd Partridge
1我的经验也表明，“8M”很难被超越。 - Sridhar Sarnobat
有趣。你认为这是否与L3缓存大小有关？我在想，块大小大于L3缓存是否会变慢。 - SurpriseDog
5
这完全取决于系统。你应该进行实验以找到最佳解决方案。
尝试从bs=8388608开始。(因为日立硬盘似乎有8MB缓存)
- ssapkota
2
7很多版本的dd命令都支持缩写，例如在GNU/Linux中使用
bs=8M，在BSD中使用bs=8m。 - pascal6哈哈，我以为你会说：“尝试从
bs=8388608开始，每次递减一步”。 - lindhe1
- 为了获得更好的性能，请使用RAM可以容纳的最大块大小（将向操作系统发送较少的I/O调用）
- 为了获得更好的准确性和数据恢复，请将块大小设置为输入的本机扇区大小
由于dd使用conv = noerror，sync选项复制数据，因此遇到任何错误都会导致该块的其余部分被替换为零字节。较大的块大小将更快地复制，但每次遇到错误时都会忽略该块的其余部分。
- eadmaster
1
2我认为，如果有任何写入错误，你应该更换介质，而不是改变块大小... - unfa
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
dd贡献一个功能，以在传输文件时找到最佳块大小。 - user3064538