☰

为什么‘dd’会对同一个 USB 驱动器生成不同的文件？

tag-icon • tag-icon linux usb mount dd
为什么‘dd’会对同一个 USB 驱动器生成不同的文件？

我刚刚保存了恢复Windows 8.1到 USB 上；现在，我一直在创建低级通过执行以下命令将其复制到我的硬盘上：

sudo dd if=/dev/sdf of=/disk2/Archive/windows8.1-restore.img bs=4M oflag=direct

我想再次检查我的“dd”命令是否正确，因此我重新运行了两次，同时指定了bs=8M和bs=16M；我检查了大小并且它完全相同，但是md5sum对这三个文件给出不同的输出：

c38a2b07b3d473d3f1876331edc2647b windows8.1-恢复.img.4M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-恢复.img.8M
568e382844431eef63d4ba6dc4c2c5ac windows8.1-恢复.img.16M

我相信我有卸载第二次和第三次。

我应该担心什么吗？

编辑

在所有情况下，文件总大小都是31024349184字节，我的理解bs=xxx是，只是为了控制速度倾倒整个 USB 驱动器。

答案1

将少量数据写入驱动器的速度很慢，因此系统会缓冲写入，以便稍后一次性提交所有数据。当缓冲区包含足够的数据以进行高效的写入操作时，或者当某个进程使用sync系统调用，缓冲区被刷新到设备。

dd执行低级复制，即读取设备上实际存在的数据。它不考虑缓冲区。

如果运行 时驱动器已安装dd bs=4M，则可能某些写入已缓冲但未提交。您已转储驱动器而无缓冲更改。

umount内部调用sync以确保数据完整性。除非您明确要求某个进程执行此操作，否则通常不会访问已卸载的设备，因此卸载后驱动器不太可能发生变化。

然后您dd在驱动器上运行了两次，中间没有安装它。这就是为什么bs=8M和bs=16M调用产生相同结果的原因。

bs=4M但是，驱动器在和调用之间被修改了bs=8M，因此第一次转储是不同的。bs=没关系，调用umount才重要。

您应该始终在使用设备之前卸载dd它，否则其他进程可能会在dd执行其工作时修改其内容并破坏文件完整性。

相关内容