最近遇到一个DD系统很奇怪的问题

[geziliu]

echo 1 > /proc/sys/kernel/sysrq
echo u > /proc/sysrq-trigger

curl -Lo- "https://drive.google.com/uc?export=down ... e3HAmqj64Z" | zcat | dd of=/dev/vda bs=1M


这其实就是一个openwrt系统
只要在任何vps上(不管国内国外的vps,不管debian ubuntu centos我全试过了), 的确能正常DD上, DD完100%能进openwrt系统


但是,把上面的bs=1M去掉, 或者换bs=512, DD完100%进不了系统, 进入grub rescure, 提示unknow filesystem


我就研究了很多, 也没弄明白, 为什么改变bs的大小, 会出现DD不成功...bs大小也是指定一次性写入的块大小, 应该和完全写入没影响啊, 小弟实在想弄清楚这个问题,所以请大佬指点下为什么 先谢了

[astolia]

大概是跟虚拟磁盘/dev/vda的后端实现方式有关。

因为你那个镜像文件有128M，按bs=1M的话就会分成128组写入，而按bs=512的话会分成262144组。后端实现不一定是有一个写入请求就立即写入实际的物理设备，很可能采取某种队列缓冲区的方式来处理。而在vps里执行完dd后进行重启，因为原来的文件系统已经被破坏，我估计你是用vps商提供的硬重启方式，这种方式下还未实际写入的请求一般就直接被抛弃了，导致镜像文件并没有被完整写入。

如果vps商提供了某种恢复模式，比如可以挂载恢复磁盘/光盘，你可以进恢复系统里，对/dev/vda进行逐块检查hash值，和OpenWrt镜像文件的进行对比，就可以知道具体写入到了哪一段了
在vps上

代码： 全选

dd if=/dev/vda of=d1 bs=1M count=1
dd if=/dev/vda of=d2 bs=1M count=1 skip=1
dd if=/dev/vda of=d3 bs=1M count=1 skip=2
...
sha1sum d1 d2 d3 ...

在电脑上下载完镜像文件并解压出来

代码： 全选

dd if=OpenWrt of=f1 bs=1M count=1
dd if=OpenWrt of=f2 bs=1M count=1 skip=1
dd if=OpenWrt of=f3 bs=1M count=1 skip=2
...
sha1sum f1 f2 f3 ...

[geziliu]

大概是跟虚拟磁盘/dev/vda的后端实现方式有关。

因为你那个镜像文件有128M，按bs=1M的话就会分成128组写入，而按bs=512的话会分成262144组。后端实现不一定是有一个写入请求就立即写入实际的物理设备，很可能采取某种队列缓冲区的方式来处理。而在vps里执行完dd后进行重启，因为原来的文件系统已经被破坏，我估计你是用vps商提供的硬重启方式，这种方式下还未实际写入的请求一般就直接被抛弃了，导致镜像文件并没有被完整写入。

如果vps商提供了某种恢复模式，比如可以挂载恢复磁盘/光盘，你可以进恢复系统里，对/dev/vda进行逐块检查hash值，和OpenWrt镜像文件的进行对比，就可以知道具体写入到了哪一段了
在vps上

代码： 全选

dd if=/dev/vda of=d1 bs=1M count=1
dd if=/dev/vda of=d2 bs=1M count=1 skip=1
dd if=/dev/vda of=d3 bs=1M count=1 skip=2
...
sha1sum d1 d2 d3 ...

在电脑上下载完镜像文件并解压出来

代码： 全选

dd if=OpenWrt of=f1 bs=1M count=1
dd if=OpenWrt of=f2 bs=1M count=1 skip=1
dd if=OpenWrt of=f3 bs=1M count=1 skip=2
...
sha1sum f1 f2 f3 ...

果然还是版大厉害，这两天忙没上论坛，的确在昨天我也证明了你的猜想
某几家VPS商就是这样，怎么写也不写不了。但有些就写得了。
我全部用不同方式DD写入后，用dd再从/dev/vda再写出， 再用diff比较，发现的确有不同的地方。应该就如你所说，对写入虚拟硬盘写入有缓冲机制不同导致。 （虽然我也试过sync，一样写入不完全）

非常感谢版本，几次遇到问题都在这论坛提问都是你帮解决的，非常回复的非常精准有效。真是非常非常感谢！