为什么在复制有限大小的设备时指定块大小？

Question

在在线教程中，通常建议使用以下命令将 CDROM 复制到 ISO 映像：

$ dd if=/dev/dvd of=foobar.iso bs=2048

为什么必须指定字节大小？我注意到实际上 2048 是CDROM 映像的标准字节大小，但似乎dd没有指定bs=或也count=可以工作。

在什么情况下不指定bs=或count=从有限大小的设备复制会出现问题？

Answer 1

dd什么时候适合拷贝数据？（或者，when are read() and write() partial）指出使用时的一个重要警告count：dd可以复制部分块，所以当给定count它会在给定数量的块后停止，即使某些块是不完整的。因此bs * count，除非您指定iflag=fullblock.

dd的默认块大小为512 字节。count是一个限制；正如您的问题所暗示的那样，复制有限大小的设备时不需要它，并且实际上仅打算复制设备的一部分。

我认为这里有两个方面需要考虑：性能和数据恢复。

就性能而言，理想情况下，您希望块大小至少等于底层物理块大小的倍数（因此读取 CD-ROM 时为 2048 字节）。事实上，现在你也可以指定更大的块大小，让底层缓存系统有机会为你缓冲。但是增加块大小意味着dd必须使用更多的内存，如果由于数据包碎片而通过网络进行复制，这可能会适得其反。

就数据恢复而言，如果使用较小的块大小，则可以从故障硬盘中检索更多数据；这就是诸如此类的程序dd-rescue自动执行的操作：它们最初读取大块，但是如果块失败，它们会以较小的块大小重新读取它。dd不会这样做，它只会使整个块失败。

Answer 2

周围有一些货物崇拜dd。最初，有两个错误cp导致了问题：当报告的块大小不是 512（Linux 使用的块大小为 1024）时，它会将文件误检测为稀疏，并且从目标文件复制时没有清除目标中的空块。稀疏文件到块设备。

您可以在早期的 Linux 邮件列表档案中找到对此的一些参考。

所以人们习惯了 dd 是处理磁盘映像的正确方法，而 cp 则被搁置了。而且由于 dd 使用默认的块大小 512，所以它很慢（在现代系统上比 cp 慢）。但是您应该使用什么块大小并不明显。可能在您的情况下，有人已经读到 2048 是 CD-ROM 的“自然”块大小（也就是说，CD-ROM 被分成 2,352 个字节的扇区，其中包含 2,048 字节的数据以及纠错信息）并决定这是与 dd 一起使用的“正确”大小，而实际上，如果您使用（适度）较大的块大小，您可能会获得更快的结果。事实上，出于这个原因，GNU cp 使用默认的块大小 64k。

tl;dr： cp /dev/dvd foobar.iso应该可以正常工作。的默认块大小dd是 512。在大多数现代环境中，保留它的唯一影响可能是使复制过程变慢。

Answer 3

更改块大小是更改一次缓冲或读取/写入的数量的好方法。

与它是真正的块设备还是无限/虚拟设备并没有真正的关系。这是关于在dd写出之前你想在内存中存储多少。bs=设置ibs=（一次读入多少数据）和obs=（一次写出多少数据）。在较高obs=的迭代次数越多ibs=，你有足够的数据之前将需要dd开始写入目的地。

count=除了您想做的事情之外，也不依赖于任何其他事情。它控制需要多少“块”（由 衡量ibs=）才能将dd其视为完成工作。