主页 / unix / 问题 / 787360
Accepted
QF0
Asked: 2024-11-29 00:35:07 +0800 CST

dd 是将图像写入驱动器的最佳方式吗？

  • 772

我正在使用此管道将图像文件写入驱动器$drive：

wget -o logfile -O - https://route/to/image.gz | \
         gunzip -c | \
         dd of="$drive" bs=4M conv=fdatasync 2>/dev/null

logfile是为了跟踪进度而创建的。

我对此有一种不祥的预感，无法说服自己这是万无一失的。图像本身总是 4MB 的倍数，所以这不是问题，但dd可能会造成问题（例如，请参阅此U&L 答案）。

是我太偏执了吗，或者有更好的方法可以做到这一点？

编辑

根据评论（感谢），我对head -c和dd bs=1将图像写入驱动器进行了基准测试。TL;DR：dd在这个应用程序中基本上毫无意义。远程服务器上的图像通过 gzip 压缩到大约 46M，因此dd与一起使用bs=1，所以这对来说可能有点不公平dd。使用检索图像wget，动态压缩，然后使用head -c或写入驱动器dd bs=1：

选项 1：

# time wget -o logfile -O - https://path/to/foo.img.gz | \
       gunzip -c | \
       dd of=/dev/sda bs=1 conv=fdatasync 2>/dev/null
    real    1m55.665s
    user    0m32.323s
    sys     2m20.841s

选项 2：

# time wget -o logfile -O - https://path/to/foo.img.gz | \
       gunzip -c | \
       cat > /dev/sda 2>/dev/null
    real    0m7.419s
    user    0m0.646s
    sys     0m0.507s

通过获取驱动器的前 48159047 个字节md5sum对这两个选项进行了测试sha256sum，并且都给出了正确的预压缩md5sum，并sha256sum在服务器上找到了：

# time head -c 48159047 /dev/sda | md5sum
b3df12b61df3121ad112f825cc6fe8b7  -

real    0m0.222s
user    0m0.075s
sys     0m0.049s

# time dd status=none if=/dev/sda bs=1 count=48159047 | md5sum
b3df12b61df3121ad112f825cc6fe8b7  -

real    1m31.627s
user    0m49.218s
sys     1m45.406s

结果sha256sum大致相同： 的实际时间约为 0.25 秒head -c， 的实际时间约为 1 分 32 秒dd。

hard-disk

1 个回答

  1. Best Answer

    ddread()是和系统调用的简单原始接口write()。

    在：

    dd of="$drive" bs=4M conv=fdatasync`

    你告诉dd要做n = read(0, buf, 4*1024*1024)，然后是write(outfd, buf, n)。

    但是read()管道通常会返回管道缓冲区中当前有多少字节，如果字节数较少则返回请求的大小，但 Linux 上的管道缓冲区默认为 64KiB，因此这里dd读取和写入的块大小会有所不同，这取决于如何gunzip将其输出写入管道，以及dd清空管道的速度。

    使用strace，我发现我的gunzip输出以 32KiB 的块为单位写入，这是管道大小的除数。最初从管道读取的速度可能比写入的速度dd快得多，因此很可能读取和写入的速度都是 32KiB。gunzip

    当内核缓冲区$drive快要满了（假设$drive写入速度比gunzip解压数据的速度慢，这是有可能的）几百兆字节之后，dd速度会变慢，并且gunzip能够填充管道（结果速度也会变慢）。然后你会看到dd64KiB 的写入块（管道缓冲区的大小）。

    除非您扩大管道缓冲区大小，否则写入永远不会达到 4MiB。为此，您需要iflag=fullblock执行dd尽可能多的 read() 来填满 4MiB 块，然后再写入。

    无论如何，该命令中唯一有用的是在最后conv=fdatasync执行fdatasync(outfd)以确保dd退出时所有数据都已刷新到磁盘并解释时间差异（在这种cat情况下，系统将在返回后很长时间继续写入磁盘），但该（或）执行的cat读+写循环完全是不必要的开销。ddcat

    在这里，你可以这样做：

    {
  wget -o logfile -O - https://route/to/image.gz | gunzip
  </dev/null dd conv=fdatasync status=none
} > "$drive

    gunzip直接写入块设备（以 32KiB 块为单位，与我的没有gunzip区别stdbuf -o4M），并dd最后执行刷新。

    请注意，该语法的另一个优点是，如果$drive无法打开进行写入，wget则不会启动，并且文件（至少是文件的开头）不会白白下载。

    对于在退出状态中报告的错误（由wget、gunzip和dd打开输出文件引起），当且仅当数据已成功下载、解压缩并写入磁盘时，您才会获得成功代码：

    (
  set -o pipefail
  ret=0
  wget -o logfile -O - https://route/to/image.gz | gunzip || ret=$?
  </dev/null dd conv=fdatasync status=none || ret=$?
  exit "$ret"
) > "$drive

    上面仍然调用fdatasync()ifwget或gunzipfailed，但您也可以将其简化为：

    (
  set -o pipefail
  wget -o logfile -O - https://route/to/image.gz | gunzip &&
    </dev/null dd conv=fdatasync status=none
) > "$drive

    跳过fdatasync()ifwget或gunzip失败。

    • 3

相关问题