使用“dd”写入块设备时，是否证明需要“同步”？

Question

每次我将文件写入空的原始块设备时，例如

# dd if=image.iso of=/dev/sdb status=progress

我从未使用过任何类型的sync（即sync; conv=fsync; conv=fdatasync; oflag=sync; oflag=dsync）。

我注意到，dd没有永远退出，直到所有的写作完成。

我总是使用 Conky 的 I/O 工具和grep Dirty /proc/meminfo. 此外，设备的校验和始终与写入它的文件的校验和相匹配。所以我总是 100% 确定整个文件已写入设备。

我已将文件写入 ext4 卷进行比较。例如使用：

$ dd if=/dev/urandom of=~/file bs=1M count=50 iflag=fullblock

写入 ext4 卷时，dd退出后在数据实际写入磁盘之前总是有大约 20 秒的延迟。

许多人提倡在sync命令后使用dd命令，或者在写入块设备时sync在dd命令中包含几个选项之一。例如这里和这里。但是，我不知道有人真正证明这是必要的。

此页面上的评论之一是：

sync在这里毫无意义[即直接写入/dev/sdX]。它只影响文件系统操作。

有五个人对这条评论投了赞成票，这与我的经验一致。

那么在写入块设备时，有没有dd在所有写入完成之前退出的情况？这真的发生在任何人身上吗？

其他书写选项如何，例如cp和cat？他们可以在写入块设备完成之前退出吗？

Answer 1

是时候回答这个问题了。

\n

这么长时间以来，我一直认为只缓存对文件系统的写入，而不缓存块设备，结果发现我错了\xc2\xa0: writes to block devices are cached。

\n

严格来说，我没有这方面的官方消息来源，并且会在收到消息后更新我的答案，但是你可以在这里找到一些信息\xc2\xa0：linux - 块设备缓存与文件系统。抱歉，我刚刚注意到你也看到了这个问题\xc2\xa0！

\n

事实上，我在将映像添加到 USB 记忆棒时遇到了问题，完成后将其弹出，然后发现它已损坏。它不应该有这样的行为，因为似乎完全同步是在close()设备上的最后一个完成的，因此我想我的设备上的数据损坏了，或者我错过了仍然打开块设备的进程，但是无论如何，我不会再冒险了。

\n

所以，是的，dd在写入块设备时添加同步选项似乎并不是一个都市传说。我认为conv=fdatasync应该足够并且性能最佳（毕竟没有添加文件元数据，并且只需要在过程结束时同步），但我们中间的极端主义者可能更喜欢oflag=sync（每次写入后完整数据+元数据同步）。检查man 2 open并man 2 fdatasync获取更多见解。

\n

根据我读到的内容（不幸的是，目前还没有正式的消息），如果其他进程仍然打开块设备，cp则cat块设备确实可以在同步之前退出，除非在设备时使用某些 SYNC 标志明确请求是open()ed 或使用同步系统调用，例如fdatasync()，fsync()或者更夸张的是sync()，这些命令都没有......

\n