为何dd工具刷写SD卡比balenaEtcher慢？如何优化dd的刷写速度？

嗨，我来帮你拆解下为啥dd比Etcher慢，还有怎么调dd的速度～

首先说清楚两者速度差这么大的核心原因：

• 块大小没踩中最优值：你当前用的bs=4M可能不是你的SD卡的最佳块大小，balenaEtcher会自动检测并适配存储设备的最优块大小，而手动指定的4M没摸到效率最高点，导致I/O操作的冗余开销变多。
• 同步策略拖了后腿：你加的oflag=sync是个大“限速器”——这个参数会让dd每写完一块就立刻强制同步到SD卡，相当于每写一小段就等磁盘确认一次，反复的等待直接拉低了整体速度。而balenaEtcher用的是批量同步的缓存策略，攒够一定量的数据再一次性同步，减少了大量等待次数。
• 空块处理逻辑不同：balenaEtcher会智能识别镜像里的空白区块（比如全0的部分），直接跳过不写入SD卡；但dd是“一根筋”，不管区块里有没有有效数据，都会老老实实把所有块都写一遍，要是镜像里空块占比高，差距就特别明显。
• 底层优化差距：Etcher在底层用了更高效的I/O处理逻辑，比如调整了磁盘队列深度、用了更适配的系统调用，而默认的dd参数没做这些针对性优化。

接下来是亲测有效的dd优化技巧，照着改速度能提一大截：

• 调整块大小（bs参数）：试试更大的块大小，比如16M、32M甚至64M，不同SD卡的最优值不一样。你可以拿空SD卡先测试：分别跑dd if=/dev/zero of=/dev/mmcblk0 bs=16M count=100 status=progress和bs=32M的版本，看哪个速度更快，就固定用那个值。
• 换同步方式，去掉oflag=sync：把逐块同步换成写入完成后一次性同步的conv=fsync，这样整个镜像写完后再做一次同步，能省超多等待时间。优化后的基础命令是：

  dd if=sdimage.wic of=/dev/mmcblk0 bs=32M status=progress conv=fsync
  

• 尝试直接I/O模式：如果你的系统支持，可以加上oflag=direct，绕过操作系统的缓存直接写磁盘，避免缓存带来的额外开销。命令改成：

  dd if=sdimage.wic of=/dev/mmcblk0 bs=32M status=progress oflag=direct conv=fsync
  

  注意：direct模式要求块大小是SD卡扇区大小的整数倍（大部分是512B或4K），16M、32M这种都满足，放心用。
• 小补充：纯dd做不到像Etcher那样智能跳过空块，但前面的优化已经能让dd的速度接近Etcher，足够满足日常使用需求了。

最后再啰嗦两句注意事项：

• 测试块大小时，一定要确认SD卡是空的，别覆盖了有用的数据！
• 写之前务必核对of=/dev/mmcblk0是正确的SD卡设备，写错了把系统盘覆盖就麻烦了！

备注：内容来源于stack exchange，提问作者Guillaume D