Why are the results of the dd command not reflected immediately?

Question

hi i currently have a question about the result after using dd command.

[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

As you can see I split the /dev/sdb disk into 2 partitions and mounted them on /root/sdb1 and /root/sdb2 respectively.

I entered /root/sdb1 and typed echo hello, world > test.txt and cloned the partition using dd if=/dev/sdb1 of=/dev/sdb2.

Then I went into /root/sdb2 to see if the test.txt file exists, but I couldn't find it.

Why are you doing this? is there something i'm missing?

I don't know why I don't see the contents of test.txt straight away. let me know!

Answer 1

Writing to /root/sdb1/test.txt modifies the filesystem mounted on /root/sdb1. The OS may cache this modification and delay writing to the underlying block device /dev/sdb1. In effect test.txt is present when you read from the filesystem, but its content may or may not be there when you read /dev/sdb1.

Your dd read a device containing a filesystem mounted for writing. Not only it might miss some data due to caching; it read different parts of the filesystem at different moments and if the filesystem was modified in the meantime then there is no guarantee all the parts form a coherent filesystem.

Check what panorama fail is. The reality is coherent at any given moment, but by taking partial images at different moments and joining them together you may get an image that is wrong. It can happen to a filesystem as well.

But this is not why you didn't see test.txt in /root/sdb2.

Your dd not only read from a device containing a filesystem mounted for writing; it wrote to a device containing a mounted filesystem. Most likely the OS knew the content of /root/sdb2 from before, this information was cached. Writing to /dev/sdb2 destroyed the old filesystem on the device, but since it did not involve writing to /root/sdb2 on the filesystem level, the OS did not treat this as a change to the mounted filesystem itself and happily showed you the old (cached) content of /root/sdb2 without reading anything anew from /dev/sdb2.

If you keep using /root/sdb2, the OS will eventually write to or read from /dev/sdb2. And then:

• writes would make sense as modifications of the old filesystem of sdb2, but they will not make sense in the context of the copy of /dev/sdb1 now present in /dev/sdb2; so even if we assume that dd luckily managed to copy the filesystem of sdb1 in some coherent state, using /root/sdb2 will break it anyway;

• reads will give the OS data from the (possibly "panorama-failed") copy of sdb1, while it expects data consistent with the filesystem still mounted on /root/sdb2; the filesystem driver may discover inconsistencies and re-mount read-only, or you can get some garbage; in general weird things will happen.

This is why you shouldn't copy the content of a block device when its filesystem is mounted for writing; and why you shouldn't write directly to a block device when its filesystem is mounted at all.

The filesystem on /dev/sdb1 should still be fine, but the current content of /dev/sdb2 is most likely a mess (even if it resembles a filesystem).

The right way was to umount /root/sdb1 and umount /root/sdb2, then to copy (not necessarily with dd). Finally you could mount both devices again*.

---

^{* Except when the filesystem is btrfs. Cloning btrfs and trying to mount the original or the copy when the other is also connected may cause data loss. See this answer and the links there.}