问如何防止dd的进程在Linux上变得毫无意义？

EN

从第一行我们可以看出，dd在一秒内读写了1.5GB。即使是SSD也不能写得那么快。

所发生的情况是/dev/sdc块设备接受了它(写回)，但没有将它发送到磁盘，而是以磁盘能够接受的速率缓冲它并开始写入磁盘。有点像3 3MiB/s。

系统不能像这样无限期地缓冲数据，在未提交的脏状态下，只有那么多的数据才能被接受。因此，过了一段时间(在您的例子中，写了超过1.5GB，但已经过了不到2秒(因为每秒钟写入进度行)之后，dd的S write()系统调用将被阻塞，直到数据被刷新到磁盘(在此期间它不能写入进度消息)。当它通过时，dd可以发送少数丢失的兆字节，这发生在不到一秒钟的时间内，所以您只能得到一条额外的进度行。

要查看不同的行为，可以强制写入是同步的，除非数据已提交到磁盘，否则不会返回。例如，通过使用oflag=sync、oflag=dsync或oflag=direct (但我不建议这样做)。

当您将文件写入块设备时，请使用dd和oflag=direct。这使用了O_DIRECT写操作，这避免了将RAM用作写回缓存。注意，为了获得良好的性能，oflag=direct通常需要很大的块大小。

这将避免看到不可能的快速进展，除非您有一个奇怪的设备本身有一个非常大的内存缓存。

很多设备都有少量的缓存。在这种情况下，oflag=direct将显示出实际的进展速度。这是更有意义的，但它并没有告诉你你想知道的一切:-)。当dd说它完成时，它不能保证最后一次写入完成。通过使用conv=fsync选项，您可以确保所有写入都完成了--并检查是否有任何写入错误。这将在末尾调用fsync()，以确保缓存被刷新。下面是一个示例：

dd if=my.iso of=/dev/sdc oflag=direct bs=4M status=progress conv=fsync

有些人在运行sync命令之后会运行，这是可以理解的，而且不必费心记住conv=fsync。这不太好。sync不会报告其中一个写入是否失败。

如果设备具有非常大的RAM缓存，则必须使用oflag=direct,sync。但通常我认为oflag=sync是影响性能的潜在障碍。您可能希望进一步增加块大小，以减少缓存刷新的频率。在这样做非常同步的IO和读取多个硬件块时，您可能希望使用双缓冲来保持良好的性能，如下面的链接所示，使用第二个dd命令。

有时，您还可能希望从另一个程序(如gunzip )中传输磁盘映像。在这种情况下，良好的性能还取决于iflag=fullblock和通过另一个dd命令的管道。答案中有一个完整的例子：为什么一条通往dd管道的拉链在最后会减速呢？

你在使用什么Linux？如果是基于Debian的(Ubuntu，Mint，Debian等等)我会用一个叫做磁盘的程序。它是一个内置的基于GUI磁盘的管理器，可以执行与DD相同的操作，并提供一致的状态。