it-swarm.cn

有没有办法确定dd的bs参数的最优值?

有时我会在网上看到一些评论,例如“请确保设置'bs =',因为默认值会花费很长时间,”以及我自己极其不科学的经验,“似乎花费的时间比其他时间长。上周的时间”似乎证明了这一点。因此,每当我使用“ dd”(通常在1-2GB范围内)时,请确保指定bytes参数。大约有一半的时间我使用了要复制的任何在线指南中指定的值;剩下的时间我会从'fdisk -l'列表中选择一些有意义的数字,因为我认为是较慢的媒体(例如,我正在写入的SD卡)。

对于给定的情况(媒体类型,总线大小或其他重要因素),是否可以确定“最佳”值?容易确定吗?如果没有,是否有一种简单的方法来获得90-95%的方法?还是“只是选择大于512的东西”甚至是正确的答案?

我已经考虑过自己尝试该实验,但是(除了进行大量工作之外)我不确定会影响答案的因素是什么,所以我不知道如何设计一个好的实验。

74
user4443

dd可以追溯到需要翻译旧IBM大型机磁带的时间,并且块大小必须与用于写入磁带的块大小匹配,否则数据块将被跳过或截断。 (9轨磁带是挑剔的。很高兴它们已经死了。)这些天,块大小应该是设备扇区大小的倍数(通常为4KB,但是在最近的磁盘上可能更大并且在很小的拇指上)驱动器可能更小,但是4KB是一个合理的中间选择),并且越大性能越好。我经常在硬盘驱动器上使用1MB的块大小。 (这些天,我们还有很多记忆。)

29
geekosaur

确定最佳块大小的方法只有一种,这就是基准。我刚刚做了一个快速基准测试。测试机器是一台运行Debian GNU/Linux的PC,其内核为2.6.32和coreutils 8.5。涉及的两个文件系统都是硬盘分区上LVM卷上的ext3。源文件为2GB(精确到2040000kB)。启用了缓存和缓冲。在每次运行之前,我都用sync; echo 1 >|/proc/sys/vm/drop_caches清空了缓存。运行时间不包含最后一个sync来刷新缓冲区;最后的sync耗时1秒。

same运行是同一文件系统上的副本; diff运行被复制到另一个硬盘上的文件系统。为了保持一致性,报告的时间是使用time实用程序获得的挂钟时间,以秒为单位。我只运行一次每个命令,所以我不知道时间上有多少差异。

             same   diff
             t (s)  t (s)
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

结论:大的块大小(几兆字节)会有所帮助,但效果并不明显(比我对同驱动器副本的预期要小得多)。 catcp的表现并不那么差。有了这些数字,我觉得不值得_dd打扰。和cat一起去!

61

我同意geekosaur的观点,其大小应为块大小的倍数,通常为4K。

如果要查找块大小,_stat -c "%o" filename_可能是最简单的选择。

但是说你做_dd bs=4K_,这意味着它做了read(4096); write(4096); read(4096); write(4096)...

每个系统调用都涉及一个上下文切换,这涉及一些开销,并且根据I/O调度程序的不同,读和散布的写入可能导致磁盘执行大量查找。 (Linux调度程序可能不是主要问题,但仍然需要考虑。)

因此,如果执行_bs=8K_,则允许磁盘一次读取两个块,这些块可能在磁盘上靠近在一起,然后再寻找其他位置进行写操作(或为其他进程提供I/O服务)。 。

按照这种逻辑,_bs=16K_会更好,等等。

所以我想知道的是,是否存在性能开始变差的上限,或者仅受内存限制。

8
Mikel

如Gilles所说,您可以为ddbs选项确定最佳参数-)通过基准测试。但是,这引出了一个问题:如何方便地对该参数进行基准测试?

我对该问题的初步答案是:使用 dd-opt ,我最近开始致力于解决这个问题的实用工具:)

5
sampablokuper

我针对sdcard阅读器usb2.0进行了优化,它似乎在bs=10M上运行效果最佳。我尝试了4k,最高可达1600万,而8-10M之后没有任何改善。您可以看到传输速率测量如何降低...最有可能是由于在设备上加载了缓冲区,然后等待设备传输到实际介质。

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s
0
wwright