为什么dd命令的结果没有立即反映？

Question

您好，我目前对使用 dd 命令后的结果有疑问。

[root@localhost sdb2]# df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 898M     0  898M   0% /dev
tmpfs                    910M     0  910M   0% /dev/shm
tmpfs                    910M  9.6M  901M   2% /run
tmpfs                    910M     0  910M   0% /sys/fs/cgroup
/dev/mapper/centos-root   17G  1.3G   16G   8% /
/dev/sda1               1014M  151M  864M  15% /boot
tmpfs                    182M     0  182M   0% /run/user/0
/dev/sdb1                4.8G   20M  4.6G   1% /root/sdb1
/dev/sdb2                4.8G   20M  4.6G   1% /root/sdb2

正如你所看到的，我将 /dev/sdb 磁盘分为 2 个分区，并将它们分别挂载在 /root/sdb1 和 /root/sdb2 上。

我输入 /root/sdb1 并echo hello, world > test.txt使用 键入并克隆分区dd if=/dev/sdb1 of=/dev/sdb2。

然后我进入/root/sdb2查看test.txt文件是否存在，但没有找到。

你为什么做这个？我有什么遗漏的吗？

我不知道为什么我没有立即看到 test.txt 的内容。让我知道！

Answer 1

写入会/root/sdb1/test.txt修改挂载在 上的文件系统/root/sdb1。操作系统可能会缓存此修改并延迟写入底层块设备/dev/sdb1。实际上test.txt，当您从文件系统读取时，它的内容可能存在，也可能不存在/dev/sdb1。

您dd读取包含安装用于写入的文件系统的设备。不仅可能因为缓存而丢失一些数据；它在不同时刻读取文件系统的不同部分，如果文件系统同时被修改，则不能保证所有部分形成一个一致的文件系统。

检查全景失败是什么。现实在任何特定时刻都是连贯的，但通过在不同时刻拍摄部分图像并将它们连接在一起，您可能会得到错误的图像。文件系统也可能发生这种情况。

但这不是您没有看到test.txtin的原因/root/sdb2。

您dd不仅可以从包含安装用于写入的文件系统的设备中读取数据，还可以从该设备中读取数据。它写入包含已安装文件系统的设备。操作系统很可能知道/root/sdb2之前的内容，该信息已被缓存。写入/dev/sdb2破坏了设备上的旧文件系统，但由于它不涉及/root/sdb2在文件系统级别上写入，因此操作系统不会将此视为对已安装文件系统本身的更改，并愉快地向您显示旧的（缓存的）内容而不/root/sdb2读取任何新的东西/dev/sdb2。

如果继续使用/root/sdb2，操作系统最终将写入或读取/dev/sdb2。进而：

• 写入对于 的旧文件系统的修改是有意义的，但它们在现在存在于sdb2的副本的上下文中没有意义；因此，即使我们假设幸运地成功复制了处于某种一致状态的文件系统，但使用无论如何都会破坏它；/dev/sdb1/dev/sdb2ddsdb1/root/sdb2

• 读取将为操作系统提供来自 的（可能是“全景失败”）副本的数据sdb1，同时它期望数据与仍安装在 上的文件系统一致/root/sdb2；文件系统驱动程序可能会发现不一致并重新挂载为只读，或者您可能会得到一些垃圾；一般来说，奇怪的事情会发生。

这就是为什么当块设备的文件系统被挂载用于写入时，您不应该复制块设备的内容；以及为什么在安装文件系统时不应该直接写入块设备。

上的文件系统/dev/sdb1应该仍然没问题，但当前的内容/dev/sdb2很可能是一团糟（即使它类似于文件系统）。

正确的方法是 和umount /root/sdb1，umount /root/sdb2然后复制（不一定是 withdd）。最后，您可以mount再次使用这两个设备*。

^{* 文件系统为 btrfs 时除外。克隆 btrfs 并在另一个也已连接的情况下尝试挂载原始文件或副本可能会导致数据丢失。请参阅此答案和那里的链接。}