[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Useless use of "dd"



On 7/1/21 10:40 PM, Teemu Likonen wrote:
* 2021-07-01 20:43:09-0700, David Christensen wrote:

To "take an image", the script invokes dd(1) and pipes the output to
gzip(1), copying raw device octets to a file. To "restore an image",
the process is reversed.

Sounds like the classic "useless use of dd". For general educational
purposes I remind (not necessarily you) that "dd" is just a file copying
(and conversion) tool, almost like "cat". By default "dd" is a slow
version of "cat" because it uses smaller buffers. "dd" can be made
faster by increasing its buffer size but that will not make it more than
just "cat".

So "dd" is not a special tool for accessing device files. Device files
don't need special tools. They are files. The following command:

     dd if=/dev/sdX | gzip >image.gz

is slower but functionally the same as either of these:

     gzip </dev/sdX >image.gz
     gzip --to-stdout /dev/sdX >image.gz

Usually we don't need "dd" for anything but there are some options which
are useful sometimes. For example, "dd" can report progress to standard
error stream and it can seek and limit read to some blocks or bytes.


My description was a high-level overview. As always, "the devil is in the details". dd(1) has features that would require extra work with cat(1) or gzip(1). The script provides all of the options to dd(1) that you mention, and more. 'bs=1048576' gives good performance, makes math easy, and dovetails with 'parted ... u MiB'. I also omitted functionality like MD5 and SHA256 checksum files, byte-for-byte verification, Bash code generation from Perl, and opportunities for concurrency (yet to be implemented). It's all good stuff that you encounter when you've been doing imaging by hand and decide to "up your game" with scripting.


David


Reply to: