为什么 dd 暂停 5 秒，然后继续 20 秒，然后再次暂停？

Question

我正在创建丢失数据的硬盘驱动器的副本，以便我可以尝试从磁盘副本恢复数据并保证原始数据的安全。我在 Mac 上使用 dd，它非常适合其他驱动器和存储介质，可以创建整个驱动器的精确副本。

我让 dd 运行了 45 个小时，期间只复制了 410GB。我注意到磁盘指示灯 LED 停止定期闪烁 5 秒，并且在活动监视器中显示仅写入了 360GB，但读取了 410GB。我使用 pv 来查看管道，这样我就可以知道它的进度，并且还报告了 410GB，所以我认为活动监视器在测量写入数据量方面是不准确的。此外，在显示读取和写入操作的图表中的活动监视器中，它仅显示读取操作的变化，但写入图表只是平坦的，没有显示任何发生的事情。我认为负责写入输出文件的第二个 dd 进程可能已被锁定。

第一次尝试花了这么长时间，只写了几秒钟，然后立即暂停了更长的时间，并且随着操作接近结束，情况变得越来越糟。当计算机重新启动时，我发现输出文件实际上是 410GB，就像活动监视器中建议的读取操作一样，因此写入操作的估计非常错误。我注意到活动监视器总是给出不正确的写入字节数，因此我不再相信活动监视器所说的内容，为什么它如此不一致？

我不想磨损需要恢复数据的旧硬盘。它随时可能会崩溃，特别是如果我必须连续几天运行它并进行大量的读取操作。

为什么 dd 会不断暂停并且随着时间的推移它会变得越来越糟？它开始时非常快，但随着大量数据的出现，它开始变得越来越慢，并且花费更多的时间看似什么也不做或等待某些事情。它在做什么？有没有更好的方法将磁盘复制到文件并使其成为驱动器上每个字节的精确副本？

以下是 IO 活动图的一些图像：

启动后立即：

4小时后：

11小时后：

26小时后：

---

我使用提供的不同方法进行了一些复制旧 USB 记忆棒的测试。所有文件都有相同的校验和，所有这些方法都在单个线程上运行。结果不是我所期望的：

• 日: 42:07
• 地址救援：47:22
• 猫：42:36
• PV：42:38

Answer 1

您问：“为什么 dd 会不断暂停，并且随着时间的推移情况会变得越来越糟？ ”

没有数据就不可能给出明确的答案，但也有可能，

• 您的内存中目标磁盘缓存已满，暂停是为了让缓存完成对物理磁盘的写入。对于 USB 连接设备尤其如此（但不限于此）
• 您的源磁盘存在硬件错误，导致无法轻松读取某些磁盘块。在这种情况下，您可以使用ddrescue尽可能多的恢复（见下文）。

鉴于您随时间变化的 IO 图表，我会说您的磁盘有故障。

然后您问：“是否有更好的方法将磁盘复制到文件并使其成为驱动器上每个字节的精确副本？ ”。就在这里。

dd if=/dev/source_disk of=/dev/target_disk如果您有诸如（用适当的值替换source_diskand ）之类的命令target_disk，那么您的使用dd效率很低，并且运行速度会非常慢^*。这里有两个解决方案

1. 如果源磁盘良好，则使用catorpv代替dd：

   cat /dev/source_disk >/dev/target_disk
   pv /dev/source_disk >/dev/target_disk     # If you have pv installed
   

2. 如果源磁盘可能根本有故障，则使用ddrescue代替dd。您需要通过 Homebrew ( brew install ddrescue) 或其他一些第三方工具存储库来安装它：

   ddrescue /dev/source_disk /dev/target_disk /some/temporary/logspace
   

   确保该logspace文件既不是/dev/source_disk也不是/dev/target_disk。

在这两种情况下/dev/source_disk，都/dev/target_disk必须卸载并且不使用。

^{*这里有很多很好的答案，特别是在Unix 和 Linux上，解释了为什么dd在如此多的用例中使用错误和无效。这里的问题是 (a)dd使用 512 字节的默认块大小，因此需要对硬盘上的每个数据块进行多次读取（SSD 上每个数据块读取 8 次），以及 (b) 任何硬件读取错误都会导致被底层磁盘子系统重新读取多次，并且 (c) 无法从此类永久读取错误中进行有用的恢复。cat不比默认设置慢dd，并且在简单直接的情况下使用时可以明显更快}